Multi-Agent 怎么评估？不能只关注最终结果

上一篇介绍 Observability，解决的是一个基础问题：系统运行过程中发生了什么？

Trace 能告诉我们哪个 Agent 调用了什么工具、任务经过了哪些节点、哪里发生了重试。

有了这些信息，还要进一步判断：这次运行到底好不好？

这就是 Evaluation，也就是评估。

对于普通问答，检查最终答案是否正确，往往已经能覆盖大部分需求。

Multi-Agent 更复杂。同一个任务运行两次，可能使用不同资料、不同工具，甚至由不同 Agent 完成某个步骤，但最后都得到正确结果。

因此，评估 Multi-Agent，不能只盯着最终答案，也不能要求它每次走完全相同的路径。

更有效的做法，是同时检查结果、交付物、组件、执行轨迹以及执行成本。

假设有一个 Research Agent：

01User
02  ↓
03Planner
04  ↓
05Research Agents
06  ↓
07Search / Browser
08  ↓
09Writer
10  ↓
11Final Report

用户要求：

01分析 AI Coding Agent 市场，
02比较主要产品并给出趋势判断。

新版本测试结果如下：

01Answer Score: 0.91
02Cost:         $1.31
03Latency:      97s

旧版本：

01Answer Score: 0.88
02Cost:         $0.42
03Latency:      40s

单看答案质量，新版本有所提升。

但它的成本接近原来的三倍，延迟也明显增加。如果产品每天需要运行几万次，这个提升可能并不划算。

生产环境里的 Agent，通常需要同时考虑：

01质量
02成本
03延迟
04稳定性
05安全性

因此，Evaluation 要回答的并不是一个单纯的“对或错”，而是：

系统完成任务的质量如何，为此付出了什么代价。

Multi-Agent 的评估可以分成四层：

01Outcome
02   ↓
03Artifact
04   ↓
05Component
06   ↓
07Trajectory

四层关注的问题不同。

Outcome 指最终任务结果。

例如订票 Agent 回复：

01机票已经预订成功。

这句话只能说明 Agent 认为自己完成了任务。

真正的 Outcome 应该检查：

01订单是否已经创建
02付款状态是否正确
03航班日期是否正确
04乘客信息是否正确

如果 Agent 操作了外部系统，环境中的最终状态通常比回复文本更可靠。

不同 Agent 对应的 Outcome 也不同：

01Coding Agent
02→ 测试是否通过
03
04Browser Agent
05→ 页面状态是否符合预期
06
07Customer Service Agent
08→ 工单是否正确更新
09
10Data Agent
11→ 数据是否正确写入

有明确业务状态时，应优先检查这些结果。

Artifact 指 Agent 产生的交付物，例如：

01报告
02代码
03SQL
04表格
05邮件
06JSON
07Pull Request

Research Agent 的报告可以检查：

01事实是否准确
02问题是否回答完整
03引用是否正确
04来源是否可靠
05结构是否符合要求

这里已经比简单的“任务成功”更细。

任务可能完成了，但交付物质量仍然不够。

例如报告成功生成，却引用了错误来源；代码成功提交，却没有覆盖关键边界条件。

一个 Multi-Agent 系统往往包含多个组件：

01Router
02Planner
03Research Agent
04Writer
05Reviewer
06Tool
07Memory

最终结果失败时，原因可能只出现在其中一个环节。

例如：

01Planner       PASS
02Research      PASS
03Writer        FAIL
04Reviewer      PASS

如果只记录最终失败，很难判断应该修改哪里。

Component Eval 会把问题定位到具体 Agent、Tool 或步骤，这也是 Evaluation 与 Observability 配合使用的地方。

Trace 提供运行记录，Eval 对这些记录进行判断。

Trajectory 指一次任务从开始到结束经历的完整执行路径。

例如：

01User
02  ↓
03Planner
04  ↓
05Search
06  ↓
07Research Agent
08  ↓
09Tool
10  ↓
11Retry
12  ↓
13Writer
14  ↓
15Reviewer
16  ↓
17Final

对 Trajectory 的评估，通常关注这些问题：

01是否调用错误工具
02是否发生重复搜索
03是否存在无意义重试
04是否进入循环
05handoff 是否合理
06是否进行了危险操作
07是否访问了不该访问的数据

OpenAI 的 Trace Grading 就属于这一类方法：直接对 Agent 的模型调用、工具调用和执行轨迹进行评分。

这样，系统失败后得到的信息就不再只是：

01任务失败

而可能变成：

01Planner 选择了错误策略
02→ Research Agent 重复搜索
03→ Writer 使用了旧结果
04→ 最终报告出现错误

这类信息更适合工程调试和版本回归。

Trajectory Eval 有一个容易出现的问题：把某条执行路径当成唯一标准。

例如规定：

01必须先搜索 A
02然后搜索 B
03最后调用 C

只要 Agent 改变顺序，就判定失败。

这种方式并不适合多数 Agent。

相同任务往往存在多条有效路径。一个 Research Agent 可能搜索三个高质量来源，另一个搜索五个来源；只要结果可靠、过程合理，两种路径都可以接受。

因此，更适合定义 Invariant。

Invariant 可以翻译成“必须始终满足的约束”。

例如：

01至少使用两个独立来源
02不能伪造引用
03不能访问禁止域名
04关键结论必须有证据
05不能执行未授权操作

至于 Agent 调用了几次搜索、先访问哪个来源，可以保留一定自由度。

评估需要约束关键行为，同时允许合理的路径变化。

有了评估维度，还需要建立 Dataset，也就是一组固定测试任务。

如果测试集里全是正常请求：

01查询公司信息
02比较两个产品
03总结一篇文章
04分析一个行业

测试结果通常会比较乐观。

真实环境还包含很多异常情况：

01工具超时
02数据缺失
03来源冲突
04上下文过长
05权限不足
06用户要求含糊
07恶意输入

例如两个来源给出不同数据：

01Source A: Revenue = $12.8B
02Source B: Revenue = $15.2B

Research Agent 应该继续查证、判断数据口径，或者在报告中说明冲突。

如果系统直接随机选择一个数字，正常测试可能永远发现不了这个问题。

因此，一个可靠的测试集至少要覆盖正常任务、边界任务和已知失败模式。

Grader 指负责给测试结果打分的规则或评估器。

通常可以组合三类。

确定性结果优先交给程序判断：

01Exact Match
02JSON Schema
03Regex
04Unit Test
05Environment State

例如要求 Agent 返回固定 JSON，字段类型和必填项直接使用 Schema 验证即可。

这种任务没有必要额外调用模型评分。

自然语言内容往往没有唯一答案，例如：

01报告是否完整
02分析是否有逻辑
03来源质量是否足够
04是否遗漏关键风险

这类问题可以交给 LLM Grader。

为了让评分更稳定，通常需要提供明确 Rubric，也就是评分规则。

例如：

01Completeness
02
035 分：
04完整覆盖所有核心问题
05
063 分：
07覆盖主要问题，但存在明显遗漏
08
091 分：
10只回答少量问题

相比直接询问“这篇报告好吗”，这种方式更容易得到一致结果。

人工评估仍然比较重要。

尤其适合：

01新的 Failure Mode
02复杂质量问题
03安全风险
04主观性较强的输出
05LLM Grader 校准

实践中可以形成一个循环：

01自动评估
02   ↓
03筛出异常样本
04   ↓
05人工检查
06   ↓
07发现新的失败模式
08   ↓
09加入回归测试集

这样测试集会随着系统运行不断积累。

Agent 的运行存在一定随机性。

即使输入、Prompt、模型和工具完全相同，两次运行仍可能采用不同搜索路径。

因此，一个重要任务可以重复执行多次。

一次执行通常称为一个 Trial。

例如同一个任务运行五次：

01Trial 1
02Trial 2
03Trial 3
04Trial 4
05Trial 5

两个版本可能出现这种结果：

01Version A
02
030.91
040.90
050.92
060.91
070.90

01Version B
02
030.97
040.95
050.55
060.96
070.52

Version B 偶尔表现很好，但波动明显。

如果生产环境要求稳定输出，Version A 反而更可靠。

所以除了平均得分，还可以记录：

01Success Rate
02Average Score
03Variance
04Failure Rate

评估 Agent 时，稳定性和最高能力同样重要。

假设准备了一套 50-query Research Agent Regression Set。

Regression Set 就是一组固定回归测试，每次修改 Prompt、模型、Tool 或 Agent 流程后都重新运行。

评估可以分成三部分：

01Final Answer
02├── factuality
03├── completeness
04├── citation correctness
05└── source quality
06
07Trajectory
08├── invalid tool calls
09├── unnecessary retries
10├── duplicate searches
11└── unsafe actions
12
13System
14├── latency
15├── tokens
16├── cost
17└── success rate

某次修改 Planner 后得到：

01Success Rate
0292% → 96%
03
04Completeness
050.89 → 0.93
06
07Duplicate Search
084.8% → 12.7%
09
10Average Cost
11$0.47 → $0.82

结果很清楚。

新的 Planner 提高了任务成功率和报告完整度，但重复搜索明显增加，成本也接近翻倍。

接下来的优化方向因此能够进一步缩小：

01保留新的规划能力
02减少重复搜索
03限制无效工具调用

这比单独比较最终答案，更接近真实的工程决策。

Evaluation 最有价值的地方，在于形成持续回归。

完整流程可以是：

01线上发现问题
02      ↓
03查看 Trace
04      ↓
05确认失败原因
06      ↓
07新增测试样本
08      ↓
09补充 Grader
10      ↓
11修改 Agent
12      ↓
13运行 Regression
14      ↓
15比较质量、成本和延迟

例如线上发现 Research Agent 经常引用同一篇新闻的多个转载页面，并把它们当成多个独立来源。

修复 Prompt 只是第一步。

更重要的是把这个问题加入 Regression Set：

01检查来源是否真正独立

以后每个版本都重新验证。

随着系统运行，测试集可能从：

0150
02↓
03100
04↓
05200

不断增长。

这些样本记录了系统真正失败过的地方，也形成了这个 Agent 最有价值的工程资产之一。

Observability 解决：

系统发生了什么？

Evaluation 继续回答：

这次运行质量如何？

Multi-Agent 的评估可以从四层建立：

01Outcome
02Artifact
03Component
04Trajectory

同时记录：

01Cost
02Latency
03Reliability
04Safety

测试集不能只有正常任务，还要加入边界情况、工具失败、数据冲突和真实线上问题。

Grader 也不必全部交给模型。确定性结果交给程序，自由文本使用 LLM Rubric，复杂问题保留人工检查。

最终，一套成熟的 Evaluation 应该能够回答几个具体问题：

01任务成功率提高了吗？
02失败主要发生在哪一层？
03执行过程是否合理？
04系统是否更加稳定？
05成本和延迟增加了多少？

当这些问题都有稳定的数据回答之后，Multi-Agent 的迭代才真正从“感觉变好了”，并支持可持续验证。