多Agent系统评测：为什么你的成功率指标一直在骗你

做 Agent 的团队都有一个数字：任务成功率。

但如果你只有这一个数字，你其实什么都不知道。

一个 65% 成功率的系统，可能有两种完全不同的情况：一是每个环节都 90% 可靠，串起来就是 65%；二是一个环节彻底不可靠，其他环节都在给它的失败做补丁。改进方向完全相反。

一、端到端指标的盲区

端到端成功率有三个固有缺陷：

缺陷一：掩盖方差 100 个任务里，50 个轻松完成（5 步），50 个艰难完成（30 步）。平均成功率好看，但一半用户经历的是挣扎。

缺陷二：无法归因 失败了，是检索没找到资料？是工具调用参数错？是模型理解偏差？还是任务本身超出范围？混在一起，没法修。

缺陷三：延迟反馈 跑完 500 条才看到分数。但失败发生在第 3 步时，后面 20 步都在浪费钱。

二、三层指标体系

层一：节点级（每个 Agent / 每个工具调用）

• 输入是否符合预期 schema
• 输出是否符合 schema（结构化交接的最大价值就在这）
• 重试次数分布
• 单节点平均耗时与 token 消耗

节点级指标能回答：“哪个环节在拖后腿”。

层二：交接级（Agent 之间）

• A 的输出有多少字段被 B 实际使用
• B 是否向 A 请求了补充信息（说明 A 输出不完整）
• 交接后是否需要重新规划（说明上游决策质量差）

交接级指标是多 Agent 系统独有的，也是最容易被忽略的。一个常见的隐性浪费是：上游 Agent 精心生成了 10 个字段，下游只用 1 个。这时候应该砍字段，甚至砍掉整个上游环节。

层三：轨迹级（整个任务）

• 总步数分布
• 是否出现循环（相同动作重复 3 次以上）
• 是否触发了步数上限
• 失败发生在第几步（失败点分布图极有价值）

如果 80% 的失败都在第 2–3 步，说明问题在任务理解阶段，不在执行阶段。

三、轨迹回放怎么做

核心是完整记录每一步：

{
  "step": 3,
  "agent": "search_agent",
  "input": {"query": "2026 Q3 竞品定价"},
  "tool_calls": [{"name": "web_search", "params": {...}, "result_summary": "..."}],
  "output": {"findings": [...], "confidence": 0.6},
  "tokens": {"in": 3200, "out": 480},
  "latency_ms": 2400
}

有了这份记录，你可以：

• 重放：把某一步的输入单独喂给该 Agent，看输出是否一致
• 对比：改了 Prompt 之后，同一任务的轨迹在哪些步骤变化了
• 聚类：把失败轨迹自动分组，找出高频失败模式

一个实用技巧：每周抽 20 条失败轨迹，人工读一遍。你会发现的问题，通常比指标告诉你的更具体。

四、别把”能跑通”当成”跑得对”

另一个危险的指标是”任务完成”——Agent 说完成了，但结果是错的。

所以必须加结果校验层：对最终产物做独立验证（数字对不对、格式合不合规、来源是否存在）。这一层最好用规则和工具，而不是再让模型判断。

对于无法自动验证的输出（比如”写一份分析报告”），至少要做结构化检查：是否包含要求的章节、是否引用了来源、数字是否自洽。

五、一个最小可用的评测清单

上线前必须能回答：

1. 在 100 条真实任务上，端到端成功率是多少？
2. 失败任务里，第几步失败最多？
3. 哪个节点的重试率最高？
4. 平均步数和 P95 步数分别是多少？
5. 每次任务的平均成本是多少？最贵的一次花了多少？
6. 有没有任务触发过步数上限？

六个问题答不上来，就先别扩量。

写在最后

Agent 系统会随着复杂度提升而”变黑”。可观测性和分层评测，是你唯一能看见里面的方式。

成功率是一个结论，不是一张地图。你要的是地图。