Laminar 发布 RL 训练模型 flow-1：检测 agent trace 错误成本降低 23 倍

大家好 HN，我们是 Laminar（https://laminar.sh）的 Robert 和 Din。自 2024 年以来，我们一直在为 AI 智能体构建开源可观测性方案。最近，我们发布了 flow-1，一个通过 RL 训练、用于在智能体 trace 中查找错误的模型。在我们的基准测试（https://laminar.sh/blog/flow-1）中，它的检测质量与 GPT-6-sol 相当，而成本却低 23 倍。这让分析每一条生产环境的智能体 trace 变得负担得起，无需采样。

这里是一分钟的演示：https://youtu.be/KJa3h6ZJNLQ

我们还整理了一篇文章，包含 flow-1 和其他模型的示例 trace 与分析：https://laminar.sh/blog/flow-1-in-action

智能体可观测性领域已经很拥挤，所以我们不打算列出 Laminar 与 X 有何不同的要点清单，而是解释我们如何从第一性原理出发解决智能体可观测性问题。

智能体现在会运行很多步骤，且失败是隐性的。智能体可能点错按钮或引用错误的文档，而每一次调用都成功完成。这些错误是最值得捕捉和理解的。要找到它们，你需要理解智能体试图做什么，并检查它的 LLM 调用和工具结果。仅仅看智能体的最终输出是不够的。

仅靠收集 trace 并不能解决这个问题。许多智能体可观测性平台在本质上仍是数据收集器。最终你可能在为那些没人有时间阅读、也无法从中提取价值的 trace 付费存储。

用另一个 LLM 来检查 trace 是终极解决方案，但能力强的模型在大规模使用时成本高昂，而更便宜的模型往往会漏掉错误或标记无关内容。

所以我们构建了自己的模型来精确解决这个问题。我们微调了一个小型开源模型，然后在数千个针对软件、法律、客服等真实智能体工作流的合成调查上用 RL 对其进行后训练。我们得到了一个既擅长智能体 trace 分析、运行成本又非常低的模型。

flow-1 运行在我们称为 Signals 的框架内。它充当一个编码智能体，将智能体 trace 视为一个代码仓库，把每个 span（一次 LLM 调用、工具调用等）当作一个文件。它从完整智能体 trace 的压缩字符串表示和用户提示开始，然后在各个 span 中进行 grep 并完整读取相关的那些。

Signals 的妙处在于它可以响应通用提示。你可以让它识别用户挫败感、检查你的浏览器智能体是否完成了结账，等等。它不限于原始的错误检测。它以 JSON 格式返回发现结果，schema 可由用户自由定义。我们称之为信号事件。

一旦你开始分析每一条 trace，你也会有太多单独的事件读不过来。这就是为什么我们会自动将相似的信号事件分组为聚类。你可以看到反复出现的问题及其发生频率，然后深入查看单个事件及其背后的 trace。

你可以使用某个聚类中的 trace 来为这类故障构建一个评测数据集。然后你可以用你最喜欢的编码智能体在这些评测上进行爬山优化，并在发布到生产环境之前验证修复在这些场景中有效。

trace → 分析 → 捕捉错误并形成聚类 → 修复 → 发布。让这个循环变得简单，正是我们构建 Laminar 的原因。

我们将同样的思考投入到了 Laminar 的其他部分。我们的博客（https://laminar.sh/blog）解释了仔细研究智能体的实际工作方式如何促使我们构建 20 倍 trace 压缩、自定义 SQL 查询引擎和自动任务提取。

Laminar 遵循 Apache 2.0 协议，可自行托管（https://github.com/lmnr-ai/lmnr）。我们通过托管云服务盈利。

我们很想了解您目前是如何追踪智能体性能的。您从用户反馈和自身监控中分别能学到多少？另外，当您修复某个问题时，如何确认它没有引入其他不同的故障？