本文为工程实践复盘，客户信息已脱敏，文中数据均为项目复盘口径的脱敏示意值。

一、项目背景

我们上了多智能体协作，编排体负责拆解任务、执行体调工具、校验体做复核，各司其职，本以为能省掉不少人工。跑了一阵子，老板问协作得好不好，我们只能说看着还行。出错时翻日志像看天书，几十行调用记录里归不到具体是哪个体掉链子。说白了，我们缺一套量化的协作评测体系，全靠感觉在运营一个复杂系统。

这件事的隐患在于，多智能体一旦上线，故障面从单模型变成多角色联动，任何一环弱化都会被放大。没有度量，我们连要不要加一个体都说不清，更别提回归验证了，每次改动都像在黑暗里调参。

最刺痛我们的是一次线上回退。某次给校验体加了一条新规则，本意是提升准确率，结果一小撮边界任务被误判失败，整体成功率掉了几个点，但我们三天后才从用户反馈里反向发现。如果当时有按角色拆开的实时成功率看板，半小时内就能定位到校验体。那次事件让我们下定决心：多智能体不是上了就完事，它必须像微服务一样有可观测性和质量门，否则就是个美丽的黑盒。

二、落地场景

我们给每个任务埋了端到端成功率，同时对编排、执行、校验三类角色分别记耗时、失败数和重试次数。协作链路可回放，哪一步卡住一目了然。建了一组评测集做基线，每次模型或流程改动都跑回归，看成功率有没有掉。

落地时我们把评测接进 CI，任何涉及智能体的改动必须过评测集才能合并，等于给协作系统装了一道质量门。运营每天看一张看板，哪类任务成功率低、卡在哪个体，一眼可见，不用再去翻原始日志。

为了让研发真的用起来，我们把评测结果做成了每次提交的必看项，和单元测试报告放一起，谁的代码把成功率拉低了，合并请求里直接标红，负责人自己就会去修。这比开质量会议管用得多，因为问题被钉在了具体的人和具体的改动上，没法含糊带过。

三、关键技术挑战与解决思路

成功率口径定义就吵了一周。有人主张按最终交付物对不对算，有人主张按流程走完没走完算，我们最后折中：以最终交付正确为根本，但把中途可恢复的失败和致命失败分开计，因为可恢复的失败其实体感还好，不该和致命失败一视同仁。失败环节归因靠链路埋点，每个体进出都留结构化日志，回放时按时间线拼出卡点。

评测集构建是慢活，我们从历史任务里抽典型场景，标注期望结果，覆盖正常、异常、边界三类。这里我有个主观判断：评测集宁小勿滥，覆盖三类典型比堆几千条同质样例有用，因为同质样例跑得快但发现不了边界问题，而边界恰恰是最容易翻车的地方。

评测集上线后还踩过一次维护的坑。团队图省事，把线上真实失败案例直接批量灌进评测集，结果评测集慢慢偏向某些特定失败模式，对其他能力的覆盖反而下降，评测分数虚高。后来我们定了规则：评测集按能力维度配额采样，不让某类样本无限膨胀，分数的代表性才回来。评测集本身也需要被看护，它不是一个建完就不动的资产。

案例片段（已脱敏）：协作埋点与归因的配置。

yaml trace:  roles: [planner, executor, validator]  emit: [enter, exit, fail, retry]  eval_set: [normal, anomaly, edge]

一段回放记录很说明问题：某次整体成功率掉到八成，顺着埋点看，是校验体新加的一条规则把一小撮边界任务误判为失败，定位从三天缩到半小时。

四、效果数据

端到端任务成功率从约 76% 提升到 91%，单环节失败率最高的是执行体，约 11%。平均协作轮次从 4.2 降到 3.1，说明任务拆得更准、返工少了。评测集通过率稳定在九成以上。这些数字为示意口径。

五、可复用经验总结

成功率不是看整体一个值就完事。我们早期只算端到端，某次整体掉到八成，盯着大盘三天没找到原因，后来按角色拆开埋点，才发现是校验体某条规则改坏了一小撮任务。协作系统的可观测性得从建设最初期就做，别等出事再补，那时日志早就淹没了关键线索。

评测集别贪大，覆盖三类典型场景比堆量有用，跑得快团队才愿意每次都跑。把评测接进 CI 是值得的，我们之前靠人工偶尔跑，经常漏，接进门禁后智能体相关的回退明显少了，质量从被动救火变成主动拦截。

结语

协作评测这件事，我们一开始觉得是锦上添花，后来发现它是多智能体能不能上生产的命门。没有度量，再聪明的编排也是黑盒，出问题只能靠运气。我们把评测接进 CI 后，智能体相关的回退基本归零，团队也敢放心迭代了。要是早一点建评测集，前面那几次线上抖动能少踩不少。评测集不用大，覆盖正常、异常、边界三类就够，关键是每次改动都跑，跑得动才跑得勤，而且评测集本身也要被看护，别让它慢慢偏成某个单一能力的练习册。