跳到主要内容

Multi-Agent Evaluations

单 Agent 的评估已经不简单，多 Agent 会再多出一层难点：

  • 结果错了，到底是哪个 Agent 出的问题
  • 路由错了，还是执行错了
  • handoff 有问题，还是下游工具失败
  • 最终答案看起来还行，但中间协作链已经在漂

这里专门讨论多 Agent 的评估方法。

参考资料主要来自：

1. 多 Agent 为什么更难评估​

单 Agent 评估时，往往先看：

  • 最终输出对不对
  • 工具调得对不对
  • 轨迹有没有明显偏差

多 Agent 之后，至少会再多出 4 层：

  • 路由是否正确
  • 角色分工是否合理
  • 交接是否清楚
  • 协作开销是否值得

所以多 Agent 的评估，不能只盯着最后答案。

2. 先把评估拆成 5 层​

一套比较稳的拆法是：

  1. Router / Triage 层
  2. Single Agent 执行层
  3. Handoff / Coordination 层
  4. End-to-End 结果层
  5. 成本 / 延迟 / 稳定性层

只有把这几层拆开，评估结果才有地方落。

3. Router / Triage 层怎么评​

如果系统里有：

  • 入口 Agent
  • specialist 分流
  • manager 分派 worker

那第一层先评路由。

常见指标包括：

  • 路由准确率
  • top-2 覆盖率
  • 错误分流率
  • 不必要 handoff 比例

一个最小评估集可以先做成这样：

caseinputexpected_routeactual_routecorrect
1用户要退款billing_agentbilling_agentyes
2用户问合同条款legal_agentsupport_agentno
3用户要查订单状态ops_agentops_agentyes

这层先评清楚，不然下游做得再好也会被错误入口拖垮。

4. Single Agent 执行层怎么评​

路由之后，每个 specialist 仍然要单独评。

也就是把每个 Agent 当成局部系统来评：

  • 任务理解是否正确
  • 工具调用是否正确
  • 结果是否完整
  • 是否遵守本角色边界

这层的重点是：

不要因为系统是多 Agent，就跳过单 Agent 级别的评估。

很多问题最后看起来像协作问题，实际上只是某个子 Agent 自己没跑稳。

5. Handoff / Coordination 层怎么评​

这是多 Agent 特有的一层。

要评的不只是“有没有交出去”，还包括：

  • 是否该交
  • 交给谁
  • 交接信息够不够
  • 交接后是否丢上下文
  • 是否出现重复劳动

可以单独拉一个表：

casehandoff_expectedhandoff_actualpayload_completeduplicate_worknotes
1yesyesyesnook
2noyespartialyesover-delegated
3yeswrong_targetnonoroute mismatch

这一层最好结合 trace 一起看。

6. End-to-End 结果层怎么评​

这一层还是要保留，因为用户最终看到的是整体结果。

可以评：

  • 任务完成率
  • 最终答案正确率
  • 结果完整性
  • groundedness / 引用质量
  • 是否满足格式或业务约束

但这里有一个问题：

最终结果对，不代表协作过程健康。

例如：

  • manager 选错一次 worker，但后来靠第二次修回来了
  • handoff 重复两次，但最后答案还是对
  • 中间多调了很多工具，最后结果表面上没问题

所以 end-to-end 只能是其中一层，不能是全部。

7. 成本 / 延迟 / 稳定性层怎么评​

多 Agent 很容易出现“效果差不多，成本翻倍”的情况。

这层建议至少看：

  • 平均 token 消耗
  • 平均模型调用次数
  • 平均 handoff 次数
  • 平均工具调用次数
  • P50 / P95 延迟
  • 超时率
  • 中断率
  • 重试率

如果多 Agent 版本只带来边际收益，却明显放大：

  • 成本
  • 延迟
  • 不稳定性

那就要重新审视拆分是否值得。

8. trace grading 为什么特别重要​

OpenAI 的 trace grading 对这一类问题很有用，因为它评的不是单点输出，而是整条 trace。

对多 Agent 来说，trace 里通常会包含：

  • 路由决策
  • handoff 链路
  • tool 调用
  • 中间结果
  • 最终输出

这样可以单独给这些环节打标：

  • route_correct
  • handoff_necessary
  • payload_complete
  • tool_success
  • final_answer_correct

这比只看最终答案更容易定位问题。

9. 一套实用的评分框架​

可以把多 Agent 评估拆成下面 6 个评分项：

维度问题
route quality任务是否被送到合适的角色
handoff quality交接是否必要、目标是否正确、信息是否完整
agent execution子 Agent 是否完成了自己的职责
collaboration efficiency是否出现重复劳动、空转、过度协作
final quality最终结果是否正确、完整、可用
runtime quality成本、延迟、稳定性是否在可接受范围

如果需要，可以给每项打 0/1，或者 1-5 分。

10. 多 Agent 评估最常见的误区​

10.1 只看最终答案​

这是最常见的一类问题。

最后结果正确，不代表：

  • 路由对了
  • handoff 合理
  • 协作成本可接受

10.2 把所有问题都归给某个 specialist​

多 Agent 错误很常见的一种情况是：

  • 入口路由错
  • handoff payload 不完整
  • manager 指令模糊

这时候真正出问题的不一定是 specialist 本身。

10.3 没有为每个角色准备独立测试集​

如果只有 end-to-end 数据，而没有：

  • triage 集
  • specialist 集
  • handoff 集

定位问题会很慢。

10.4 不看协作成本​

多 Agent 不是天然更好。

如果一个任务：

  • 单 Agent 2 步完成
  • 多 Agent 6 步完成
  • 结果没有明显改善

那这套设计就需要重新评估。

11. 最小数据集应该怎么建​

第一版不需要很大，但最好分层准备：

11.1 路由集​

专门测：

  • 该给谁处理
  • 哪些输入容易误分流

11.2 specialist 集​

专门测每个 Agent 自己的执行能力。

11.3 handoff 集​

专门测：

  • 什么时候该交
  • 交给谁
  • 交接信息够不够

11.4 end-to-end 集​

专门看整体完成情况。

11.5 regression 集​

把线上失败样本不断沉淀进来。

12. 一套最小表格模板​

| case_id | route_ok | handoff_ok | payload_ok | agent_ok | final_ok | tokens | latency_ms | notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| ma_001 | yes | yes | yes | yes | yes | 1820 | 4200 | |
| ma_002 | no | no | partial | yes | no | 2100 | 5100 | routed to wrong specialist |
| ma_003 | yes | yes | no | no | no | 2600 | 6400 | missing context in handoff |

这个表虽然简单，但已经能把不少问题分层看出来。

13. 和现有专题里的关系​

最适合一起看的文档有：

14. 小结​

多 Agent 评估最怕一件事：

把所有问题都压成“最终答案对不对”。

更稳的做法是把它拆开看：

  • 路由
  • handoff
  • 子 Agent 执行
  • 最终结果
  • 运行质量

这样整理之后，评估结果才更容易帮助系统迭代。