一、引言：多 Agent 系统上线后，谁为"整体质量"负责？
上一期我们解决了多 Agent 的成本问题：上下文瘦身、消息传结论、模型分级、缓存命中，账单从 900 元/天砍到 200 元/天。但成本降下来之后，一个更尖锐的问题浮出水面------省下来的钱，买到的还是原来那个质量吗？
单 Agent 的评测已经很难了：没有标准答案、输出概率性、同一问题两次回答不一样。多 Agent 系统把难度又抬了一个量级：
- 单个 Agent 评测全过，组合起来却答错了------意图识别 Agent 把"退货运费谁出"分给了订单 Agent，订单 Agent 只查订单状态不回退货运费，用户问题被"踢皮球"；
- 单个 Agent 都正常，但链路延迟爆炸------编排者把完整对话复制给三个子 Agent，每个子 Agent 又各自检索知识库，一次请求烧了 8 万 token，P95 响应 12 秒；
- 更隐蔽的是错误传播------子 Agent 返回的结论有个小错（比如把订单号识别错一位），编排者不校验直接采用，错误顺着链路一路放大，最后用户收到一个"查无此单"的回复，你还不知道错在哪一环。
单 Agent 评测回答的是"这个模型答得好不好"；多 Agent 评测要回答的是"这套系统在真实协作下，任务完成得对不对、快不快、省不省、稳不稳"。本文基于华为云 Flexus 云服务器 + Dify + DeepSeek 系列实战环境，讲清楚多 Agent 评测的四个层次、两个必须建的基准集、以及一套可落地的评测流水线，是《华为云Flexus+DeepSeek征文》系列的第十九篇。
二、多 Agent 评测难在哪：三个根本挑战
先正视困难，才能设计出有效的评测体系。多 Agent 评测比单 Agent 难，难在三个根上。
2.1 挑战一：结果不唯一，过程不可复现
单 Agent 至少还有"输出文本"可以比较。多 Agent 系统里，同一个任务可以被不同 Agent 组合、不同顺序、不同工具调用方式完成，最终答案可能完全不同但都正确。评测如果只看最终答案，会漏掉大量"过程性问题"------比如某条链路虽然答对了，但调了 5 次工具才答对，成本是别人的 3 倍。而过程本身又不可复现：LLM 有随机性，同一任务跑两次，Agent 走的路径就不一样。"不可复现"直接摧毁了传统回归测试的根基------没法"跑一遍对比基线"。
2.2 挑战二：错误会传播，责任难定位
多 Agent 的错误是"传染病"。子 Agent 输出一个小错，编排者不校验就放大；两个子 Agent 的结论互相矛盾，编排者随机采信一个。出了问题，你面对的是整条链路上的十几个环节：是意图识别错了？是路由分错了？是子 Agent 工具参数传错了？还是编排者汇总时漏了字段？没有全链路 trace，定位一个多 Agent 错误的时间成本是单 Agent 的 5-10 倍。
2.3 挑战三：评测对象是"组合"，不是"个体"
单 Agent 评测可以逐个测：这个 Agent 的意图识别准确率、那个 Agent 的答案相关性。多 Agent 系统的质量不是各 Agent 质量的简单加和------1+1 可能小于 2（协作低效、互相干扰），也可能大于 2（分工明确、各展所长）。评测必须覆盖"组合行为"：任务级完成率、跨 Agent 信息传递正确率、编排决策合理性。只测单个 Agent，等于只检查零件不检查整机。
记住一个原则：多 Agent 评测要"自顶向下"------先定任务级指标，再拆到 Agent 级定位，最后落到单次调用分析。 顺序反了，你会淹没在单个调用的细节里，永远看不到系统整体的问题。
三、评测四层次：从任务到调用，逐层下钻
多 Agent 评测体系分四层，每层回答不同的问题。建体系时从上层往下建，排查问题时从下层往上查。
3.1 第一层：任务级（Task Level）
回答"用户的任务到底完成没有、完成得好不好"。这是最重要的层，直接对业务价值负责。每个任务定义一组指标：
- 任务完成率：任务成功结束（有最终答案且满足约束）的比例；
- 端到端正确率：最终答案与标准答案一致/等价的比例（需要基准集，见第四节）；
- 目标达成度：部分成功怎么算------比如用户要"查订单+算运费+给退款方案"，只给了订单信息算 33% 还是算失败？需要按业务定义分级评分。
3.2 第二层：Agent 级（Agent Level）
回答"每个 Agent 干好自己的活没有"。把任务链路拆开，逐个 Agent 单独评估：
- 子任务准确率：意图识别 Agent 的分类准确率、订单 Agent 的信息提取准确率；
- 输入质量：子 Agent 收到的上下文是否够用------信息缺失是"编排者没传"还是"子 Agent 没要"，要能区分；
- 输出质量：子 Agent 返回的结构化结果是否符合约定 schema、关键字段是否齐全。
3.3 第三层：链路级（Chain Level）
回答"Agent 之间的协作效率与正确性如何"。这是多 Agent 独有的层，也是问题高发区：
- 传递正确率：A Agent 的输出字段传给 B Agent 后，B 正确理解并使用的比例；
- 信息冗余率：同一份上下文被复制了多少份（对应上一期的成本话题）；
- 死循环/踢皮球检测：任务是否在 Agent 之间反复流转却不产出------意图识别→订单→售后→订单→售后......这种"循环空转"是协作层最典型的失败模式；
- 编排决策正确率：编排者"分给谁、按什么顺序、汇总什么"的决策是否合理，需要专门构造"编排决策评测集"（见 4.3）。
3.4 第四层：调用级（Call Level）
回答"单次模型调用和工具调用的质量如何"。这是最细的层，用于定位具体问题：
- 单次 LLM 调用的输出质量（相关、准确、格式合规）；
- 工具调用的参数正确性（是否传错参数、拉错数据）；
- 单次调用的 token 消耗、延迟（和上一期成本治理衔接）。
四层的关系：任务级指标下降 → 用链路级 trace 定位是哪个环节 → 用 Agent 级评测确认具体是哪个 Agent 的问题 → 用调用级分析找到根因（prompt 缺陷、工具 schema 问题、上下文缺失）。评测体系建成后，这套下钻路径要"自动化"------每次任务级失败都能自动附带下钻信息，而不是靠人肉翻日志。
四、评测基准集：多 Agent 评测的"地基"
没有基准，评测就是自说自话。多 Agent 评测需要三种基准集，缺一不可。
4.1 任务基准集（Task Benchmark）
覆盖业务典型任务的输入-期望输出对。构建要点：
- 覆盖高频场景：业务里 80% 的任务类型都要有样本（客服系统的"查订单/退换货/开发票/投诉升级"各一批）；
- 包含边界与异常：缺字段的请求、语义模糊的请求、多意图混合的请求（"我要退昨天买的那个蓝色外套，顺便问下运费"）；
- 标注分级答案：每条标注"完美答案/可接受答案/失败"三级，而不是只有对错二元------多 Agent 场景下"部分完成"太常见，二元标注会丢掉大量信息。
4.2 协作基准集（Collaboration Benchmark）
专门测 Agent 之间的协作质量。构造手法：
- 信息传递用例：A Agent 的输出需要 B Agent 精确使用（订单号、用户 ID 等关键字段），验证传递不失真；
- 依赖顺序用例：任务有严格顺序依赖（先查库存再下单），验证编排者不调乱顺序；
- 矛盾输入用例：两个数据源给冲突信息（订单状态显示"已发货"，物流接口显示"未揽收"），验证系统能否识别矛盾而不是随机采信。
4.3 编排决策基准集（Orchestration Benchmark）
单独测编排者的"决策智慧"：给定场景快照（用户请求 + 可用 Agent 列表 + 上下文），期望输出"正确的 Agent 分配 + 调用顺序 + 汇总策略"。这是把"编排者的路由决策"当成一个独立评测对象，类似给 LLM 出选择题：场景描述 → 期望的决策路径 → 实际决策路径 → 对比打分。这套基准集的价值在于：它能提前发现"编排规则缺陷"，而不是等业务出问题才暴露。
4.4 基准集维护纪律
- 先建 50-100 条种子集，随业务演进持续扩充；
- 每次系统升级（prompt 改动、Agent 增减、模型更换）必须全量回归；
- 基准集本身要版本化：标注标准、期望答案会随业务变化，基准集也要纳入版本管理（上一期插件治理的版本管理经验直接用上）。
五、评测方法：LLM-as-Judge 怎么当好多 Agent 裁判
多 Agent 的最终答案没有标准文本可比，最实用的评测方法是 LLM-as-Judge（大模型当裁判）。但多 Agent 场景下裁判的活更复杂，三个关键设计：
5.1 裁判视角设计：给裁判看什么
单 Agent 评测给裁判看"问题 + 答案"；多 Agent 评测要给裁判看完整任务轨迹：
用户请求：我要退昨天买的蓝色外套，顺便问下运费谁出
轨迹：
1. 意图识别 Agent → 分类：退款+运费咨询（置信度 0.92）
2. 编排者 → 分派：订单 Agent（查单）+ 售后 Agent（退换政策）
3. 订单 Agent → 查询订单 SO20260811001，状态：已签收
4. 售后 Agent → 政策：7 天无理由退货，运费买家承担
5. 编排者 → 汇总回复：支持退货，运费需自理
裁判任务：最终答案是否完整解决用户问题？链路是否有冗余/遗漏？裁判要同时评估"结果正确性"和"过程合理性"。设计裁判 prompt 时，明确列出评分维度：完整性（有没有漏答）、正确性（有没有答错）、协作合理性（路由是否合理、有没有冗余调用）、效率（token 与延迟）。
5.2 裁判一致性：多裁判 + 仲裁
LLM 裁判有随机性和偏差（比如偏爱长答案、偏爱自己熟悉的格式）。多 Agent 场景偏差影响更大，因为评分维度多。缓解手段：
- 双裁判制：两个不同模型（比如 R1 + 一个中等模型）独立评分，分差超过阈值时用更强模型仲裁；
- 评分锚点：每个分值给具体示例锚定，减少"这个算 4 分还是 5 分"的漂移；
- 定期校准：人工抽检 10% 的裁判评分，发现系统性偏差就调整裁判 prompt。
5.3 规则优先，Judge 兜底
能用确定性规则判的，不要交给 LLM：任务完成率（有没有最终输出）、schema 合规（字段齐全）、延迟阈值（P95 < 5s）、token 上限（单任务 < 3 万）。这些用代码断言，快、稳、零成本。LLM-Judge 只负责"质量"这类无法规则化的判断。规则管"硬指标"，Judge 管"软质量"，各司其职。
六、实战：在 Dify 上搭多 Agent 评测流水线
理论讲完，落到 Dify 实战。评测流水线五个组件：
6.1 评测集管理
把三类基准集（任务/协作/编排决策）以数据集形式管理。Dify 知识库支持结构化数据管理，也可以用评测专用的外部存储（数据库表 + 版本字段）。每条样本带：task_id、类型、输入、期望输出（分级）、期望链路（可选）。
6.2 评测驱动（Runner）
写一个评测驱动脚本，流程：
1. 读取基准集样本
2. 对每条样本调用被测多 Agent 系统（Dify API）
3. 收集完整轨迹（请求、各 Agent 中间输出、工具调用、最终答案、token、延迟）
4. 规则断言（完成率、schema、延迟、token 上限）
5. LLM-Judge 评分（完整性/正确性/协作合理性/效率）
6. 汇总报告：按层级（任务/Agent/链路/调用）聚合指标
7. 失败样本自动下钻：定位是哪个 Agent 哪个环节出问题核心代码骨架：
import requests, json
def run_eval(sample, api_url, judge_fn):
# 1. 调被测系统
resp = requests.post(api_url, json={"query": sample["input"]}, timeout=60)
trace = resp.json() # 含各 Agent 中间输出与 token 明细
# 2. 规则断言
checks = {
"has_answer": bool(trace.get("final_answer")),
"schema_ok": check_schema(trace.get("agent_outputs", {})),
"latency_ok": trace.get("latency_ms", 99999) < 5000,
"token_ok": trace.get("total_tokens", 999999) < 30000,
}
# 3. LLM-Judge 软质量
quality = judge_fn(sample["input"], trace, sample.get("expected"))
return {"task_id": sample["task_id"], "checks": checks, "quality": quality}
def check_schema(outputs):
required = ["intent", "order_info", "policy"]
return all(k in outputs for k in required)6.3 评测报告
报告按四层聚合：
| 层级 | 指标 | 当前值 | 目标 |
|---|---|---|---|
| 任务级 | 端到端正确率 | 78% | > 90% |
| 任务级 | 任务完成率 | 92% | > 95% |
| Agent 级 | 意图识别准确率 | 95% | > 96% |
| 链路级 | 信息传递正确率 | 88% | > 95% |
| 链路级 | 死循环发生率 | 1.2% | < 0.5% |
| 调用级 | 平均 token/任务 | 5800 | < 5000 |
报告要能"下钻"：点击任务级失败样本，能一路看到 Agent 级、调用级的具体记录。这是评测体系是否可用的分水岭------不能下钻的评测报告，只是另一种形式的日志。
6.4 回归触发
评测流水线接入 CI：每次 prompt 改动、Agent 配置变更、模型切换，自动跑全量回归。上一期的插件治理经验正好衔接------插件有版本，评测也有版本；插件升级必须过评测，Agent 变更同样必须过评测。把"评测通过"设为发布前置条件，形成"变更 → 评测 → 通过才上线"的闭环。
6.5 线上影子评测
基准集只能覆盖已知场景，线上永远有新问题。加一层影子评测 ：线上真实请求复制一份流量（shadow traffic）到评测环境，只观测不干预，用同一套 Judge 持续打分。影子评测能发现"基准集没覆盖的长尾问题"，是新场景进入基准集的入口------发现值得复现的问题，人工确认后沉淀为新的基准集样本。基准集不是静态的，它靠影子评测持续生长。
七、常见失败模式与针对性用例
多 Agent 系统的问题集中在几个典型模式上，评测时要专门构造用例去"打"：
7.1 踢皮球（Task Bouncing）
用户问题在 Agent 之间流转，每个 Agent 都觉得自己"不是干这个的"。典型：客户问"退款到账时间"，订单 Agent 说"问财务"，财务 Agent 说"问订单"，来回三趟没结果。针对性用例：跨职责边界的问题，验证系统能否在合理步数内给出最终答复或明确升级路径。
7.2 信息丢失（Information Loss）
子 Agent 的中间结论在传递中被截断/简化，关键字段丢失。典型：售后 Agent 返回"可退货"，但运费承担方这个关键信息在编排者汇总时丢了。针对性用例：期望输出包含多个必答字段，验证最终答案字段完整性。
7.3 自相矛盾（Contradiction）
两个子 Agent 的结论冲突，系统不识别直接输出。典型：订单 Agent 说"已发货"，物流 Agent 说"未揽收"，最终回复两个都说。针对性用例：构造矛盾数据源，验证系统是否有冲突检测（要么追问、要么给出置信度、要么明确告知异常）。
7.4 过度调用（Over-Orchestration）
简单问题被拆给一堆 Agent，杀鸡用牛刀。典型："现在几点"这种问题走了意图识别→编排→知识检索→生成四步。针对性用例：简单任务，验证链路深度是否合理、是否过早调用多 Agent 路径。
7.5 链路空转（Busy Loop）
Agent 反复调用同一个失败的工具不放弃。典型：订单接口挂了，订单 Agent 连续重试 5 次，token 烧了 2 万还没结果。针对性用例：故障注入（模拟工具失败），验证系统重试策略与降级路径。
这些模式用例写进协作基准集后，多 Agent 系统的"常见病"就能在每次回归里被持续监控。
八、踩坑实录：六条血泪教训
- 只测最终答案：多 Agent 最忌只看结果不看过程------答对了但链路冗余 3 倍成本，评测完全没发现。轨迹必须进评测。
- 基准集样本太少：20 条样本的"通过率 95%"没有统计意义。先建 50-100 条，覆盖高频 + 边界 + 异常。
- 裁判只看最终输出：LLM-Judge 只给最终答案打分，过程性问题（踢皮球、矛盾）全漏。裁判必须看完整轨迹。
- 二元标注：多 Agent 任务"部分完成"是常态，只用对/错标注会丢失大量信息。用分级标注（完美/可接受/失败）。
- 评测与变更脱节：评测体系建好却只在"想起来时"跑。必须接 CI 自动化，变更必回归。
- 不沉淀新样本：线上出的问题复现后不写进基准集，同类问题下次再踩。影子评测发现的问题要持续沉淀。
九、FAQ
Q1：多 Agent 评测必须用 LLM 当裁判吗？
不是必须，但最终答案质量很难规则化，LLM-Judge 是性价比最高的方案。原则：能规则判的用规则（完成率、schema、延迟、token），判不了的用 Judge。
Q2：裁判模型选哪个？
DeepSeek-R1 等强推理模型适合当裁判------评分需要推理多维度（完整性/正确性/协作合理性），推理模型更稳。成本不是问题：裁判调用远少于业务调用，且可以批量离线评分。
Q3：评测跑一次要多久？
100 条样本 × 每条 5-20 秒 = 10-30 分钟，可以接受。更快的做法：规则断言先行，Judge 评分只跑"规则通过"的样本，或者抽样评分（每批抽 20%）。
Q4：影子评测会不会影响线上？
不会，影子流量只观测不干预，评测环境独立。注意：影子评测的请求要脱敏，不能把用户真实数据带进评测环境。
Q5：多 Agent 评测和单 Agent 评测冲突吗？
不冲突，是嵌套关系：多 Agent 评测出问题 → 下钻到具体 Agent → 用单 Agent 评测细化定位。单 Agent 评测集是多 Agent 评测的"零件检测"，两者都要建。
Q6：评测集和上一期的成本治理怎么配合？
评测保障质量，成本治理控制开销，两者配合才有意义：成本优化必须过评测（省了钱质量不掉才算数），评测发现的冗余链路又反过来指导成本优化。质量与成本，是一枚硬币的两面。
十、总结
这一期把"多 Agent 系统怎么保证质量"拆成了完整的评测体系：
- 认清挑战：结果不唯一、错误会传播、评测对象是组合------所以不能照搬单 Agent 评测；
- 四层下钻：任务级定成败、Agent 级定位、链路级查协作、调用级找根因；
- 三类基准：任务基准集、协作基准集、编排决策基准集，缺一不可；
- 裁判设计：规则管硬指标、Judge 管软质量，裁判看完整轨迹、双裁判加仲裁；
- 流水线落地：评测驱动 + 四层报告 + CI 回归 + 影子评测，形成"变更必过评测"的闭环。
如果只能带走一句话：多 Agent 系统的质量不是各 Agent 质量之和，必须用"任务级指标 + 链路级追踪"来评测整体，用"下钻式报告"来定位问题。 评测不是上线前的仪式，而是持续运行的质量雷达------每一次变更、每一次优化，都该有评测数据说话。
至此，本系列完成了从模型接入、知识库、Agent 构建、工具扩展、策略升级、可观测性、评测守护、插件治理、成本治理，到多 Agent 评测的完整闭环。下一期我们聊聊多 Agent 的灰度发布与渐进式上线------当系统越来越复杂，怎么让每一次变更都"小步快跑、随时可回滚"。
DeepSeek 实战指南系列：
Dify 实战系列：