Laminar 用强化学习训练的错误检测器：不靠人工标注，如何发现 Agent 调用链中的 Bug

Dev.to ML 2026-10-23T08:07:39+08:00

Agent 可观测性面临一个标注难题。当智能体（agent）点错按钮或引用错文档时，每次 API 调用都返回 200，调用链看起来干干净净。错误出在语义层面，而不是语法层面。必须有人类通读整份执行日志，才能判断 agent 到底有没有做对它该做的事。

Laminar 构建了 flow-1——一个小型开源模型，用强化学习训练，专门找出 agent 调用链里这类隐式失败。它在一个名为 Signals 的测试框架里扮演编码 agent，把每个 span（LLM 调用、工具调用、检索步骤）当作代码仓库里的一个文件。模型从整条调用链的压缩字符串表示出发，像开发者排查失败的 CI 运行那样展开调查。

有意思的地方不在于他们用 LLM 分析调用链，而在于他们怎么训练出一个便宜的模型来完成这件事，并且不需要真实标签。

隐式失败问题

传统可观测性假定失败是显式的：HTTP 500、超时、异常。你设定阈值、写告警规则、汇总错误率。

Agent 的失败方式不一样：

Agent 成功完成了任务，但订错了航班。
Agent 检索到三份文档，却漏掉了最相关的那一份。
Agent 把一次工具调用重试了五次，第六次成功，但重试循环烧掉了 30 秒和三美元。
Agent 凭空编造了一个函数参数，恰好能解析成合法的 JSON。

这些都不是传统意义上的错误。它们是人类读完整执行上下文后才会判定为“不对劲”的调用链模式。难点在于：怎么在不手动标注几千条调用链的前提下，教会模型识别这些模式。

没有标准答案，强化学习怎么训练

Laminar 的做法是围绕真实的 agent 工作流生成合成调查数据。他们让 agent 在软件工程、法律研究、客服等领域跑任务，生成调用链；然后用强化学习训练模型，看它的分析结论是否与预期结果一致。

训练循环大致如下：

生成一条合成的 agent 调用链，其成功或失败状态是已知的。
把 trace 交给 flow-1，让它找出其中的错误。
模型正确识别出失败模式、或确认任务成功时，给予奖励。
模型误报、或漏掉真实错误时，给予惩罚。

关键思路在于：合成 trace 的正确答案可以自己生成，因为任务定义由你掌控。如果 agent 本该订一张飞往 SFO 的机票，却订成了 OAK，你一眼就知道这是错的，不需要人工标注。

在数千条这样的合成调查上训练之后，模型学到的模式可以迁移到真实生产环境的 trace 上。

架构：Signals 运行框架与「把 trace 当仓库」

flow-1 运行在 Signals 里。Signals 是一套运行框架（harness），把整个分析过程组织成一个编码任务：trace 中的每个 span 变成一个文件，模型像开发者浏览代码库那样浏览整条 trace。

trace 的表示形式：

trace/
  span_001_llm_call.json
  span_002_tool_call.json
  span_003_retrieval.json
  span_004_llm_call.json
  ...

模型收到的输入是整条 trace 的压缩字符串表示，外加一句用户提示，例如「找出这条客服 agent trace 中的错误」。它可以读取单个 span、比对工具调用的输入与输出、检查检索结果到底有没有被真正用上、标记可疑的重试模式。

这和「把整条 trace 塞进上下文窗口，让模型写个摘要」是两回事：模型在主动调查，自己决定查哪些 span、按什么顺序查、怎么把它们关联起来。

部署方式：

通过 Laminar 的开源 SDK（兼容 OpenTelemetry）采集 trace。
trace 存放在后端（Laminar Cloud 或自托管）。
flow-1 以批处理任务或按需分析的方式运行，不在 agent 执行过程中同步调用。
模型输出结构化报告，标出有问题的 span 并给出错误描述。

也就是说，flow-1 不会给 agent 执行增加延迟。它在事后分析 trace，而这没什么问题：大部分隐性失败并不要求实时发现。你当然想知道 agent 订错了航班，但不必实时知道。

成本与性能的取舍

Laminar 表示，flow-1 在检测质量上能追平 GPT-6-sol，成本却只有后者的 1/23。这意味着你可以把每一条线上轨迹都拿去分析，不必做抽样。

模型	每条轨迹成本	检测质量	部署方式
GPT-6-sol	约 $0.23	高（基线）	API 调用
flow-1	约 $0.01	与 GPT-6-sol 相当	自托管或云端
GPT-4o-mini	约 $0.05	较低（漏掉细微错误）	API 调用
基于规则的告警	约 $0.00	很低（只能抓显式错误）	自托管

规模一上来，成本差距就很明显。假设每天有 1 万次 agent 执行、你想把每条轨迹都分析一遍：用 GPT-6-sol 每天要花 2300 美元，flow-1 只要 100 美元。基于规则的告警不花钱，但基本抓不到东西。

质量上的说法来自 Laminar 自己的基准测试，测的是模型在合成轨迹里识别隐式失败的能力。基准是公开的，但它并不是行业标准。在相信这些数字之前，最好先拿你自己的轨迹验证一下。

flow-1 到底能检出什么

这个模型被训练来标记以下几类问题：

工具调用错误：agent 调用了函数，但参数不对，或者调用时机不对。
漏掉检索：agent 跳过了本可以给出正确答案的检索步骤。
引用幻觉：agent 引用了检索结果里根本不存在的文档。
低效重试：第一次失败本来就是确定性错误，agent 却反复重试同一个工具调用。
上下文漂移：agent 跑着跑着丢掉了原任务，转去解另一个问题。

这些模式人只要读一遍轨迹就能发现，但传统可观测性工具抓不到，因为它没有显式的错误信号。

版本管理与评估的难题

训练一个错误检测模型是一回事，在生产里评估它则是另一回事。这里的“标准答案”是“这条轨迹看起来不对劲”，既主观，又会随时间变化。

Laminar 的做法是：

维护一套由合成轨迹构成的基准，其中包含已知的失败模式。
给模型做版本管理，并跟踪它在基准上的检出率。
收集用户对误报和漏报的反馈。
定期用新的合成轨迹和用户反馈重新训练。

这不是完美的解决方案。合成轨迹未必能覆盖所有真实故障模式，用户反馈也很稀疏，而且往往只集中在显而易见的错误上。但总比完全没有评估强。

更大的风险是模型漂移。用 2024 年的合成轨迹训练、2026 年才部署，模型可能识别不出新 agent 架构或新工具带来的新故障模式。你需要一个持续训练的闭环。

安全与隐私边界

用 LLM 分析生产轨迹，显然会引出几个问题：

数据泄露：轨迹里可能含个人信息、API 密钥或专有业务逻辑。
模型访问：谁能查询 flow-1、谁能看到分析结果？
轨迹保留：轨迹存多久、存在哪里？

Laminar 同时提供云端和自托管两种部署方式。自托管时，轨迹不会离开你的基础设施。用 Laminar Cloud 时，轨迹在传输和存储过程中都加密，但这意味着你把数据托付给了 Laminar。

模型本身不会从你的轨迹中学习——它是一个冻结的检查点。但分析结果可能暴露敏感信息，所以你需要对 Signals 界面和 API 做访问控制。

什么时候该用

flow-1 适合这些情况：

你在生产环境跑 agent，并且关心那些隐式故障。
轨迹量大到人工检查不现实。
你已经在用 OpenTelemetry 或类似框架收集轨迹。
你想抓住基于规则的告警漏掉的错误。

flow-1 不适合这些情况：

agent 足够简单，每条轨迹你都能手工看完。
你的故障模式很明确（超时、异常、HTTP 错误）。
你不愿意让 ML 模型在无人复核的情况下标记错误。
你需要 agent 执行过程中的实时错误检测。

这个模型也不能替代单元测试、集成测试或评估。它是调试工具，不是正确性证明。

技术结论

Laminar 这个用强化学习训练的报错检测器，在 agent 可观测性上提供了一块有用的基础组件。它解决的是个真问题（隐式失败很难被抓到），用的办法也很务实（拿合成轨迹训一个便宜的小模型）。跟 GPT-6-sol 比，省下的成本相当可观；部署方式是对存下来的轨迹做批量分析，不会给 agent 执行增加延迟。

主要风险有三块：模型漂移、评测难、以及得信任一个 ML 模型来判断有没有错。如果你已经在收集 agent 轨迹、却苦于看不懂，flow-1 值得试一试。如果规模还没大到人工翻查很痛苦，那就先用简单点的工具。

更大的启示是：agent 的可观测性需要靠学习出来的异常检测，光靠日志聚合不够。基于规则的告警对显式失败管用；隐式失败则得有个能理解 agent 当初想干什么的模型。