第 5 课：失败与协调

学习目标：

• 说明为什么子代理自称「完成了」不能直接采信，必须建立独立的验证手段
• 识别多 Agent 协作里常见的两类失败：重复劳动与结果冲突
• 在结果整合阶段，掌握怎么去重、怎么处理相互矛盾的产出

前置要求：完成第 4 课，能区分三种协作模式和 handoff | 上一课 第 4 课 << | 下一课 第 6 课 >>

两个子代理各自调研同一家云服务商的入门套餐，一个交回来说每月 20 美元起，另一个说 25 美元起——两份产出都口气笃定地写着「已核实无误」。前几课讲的都是「怎么把多 Agent 协作搭起来」，这一课讲搭起来之后会在哪里出问题——子代理的自我表态不可信、重复劳动、结果冲突——以及编排者该怎么应对。

子代理说「做完了」，不代表真的做对了

子代理返回结果的时候，通常会附带一句类似「已完成」「已核实无误」的表态。这句表态本身不是证据，只是子代理对自己产出的一句自我总结——而这句总结，可能是错的。官方对 Agent 行为的观察正是如此：模型在工作「看起来完成」的时候就会停下来，如果没有一个它能自己跑的检查，「看起来完成」就是它唯一可用的信号¹；所以官方的建议是让它展示证据，而不是宣称成功¹。

官方文档里把这种情况叫作「先信任、后验证」的落差：「Claude 会产出一份看起来合理的实现，但没有处理边界情况。应对办法：始终提供验证手段（测试、脚本、截图）。如果没法验证，就不要直接采用。」¹ 这条经验原文讲的是写代码的场景，但道理同样适用于任何一次委派：子代理交回来的东西，读起来通顺、格式对、看着像是认真做过——这些都只是「看起来合理」，不等于「真的做对了」。编排者如果只凭子代理自己说「完成了」就直接采信、拼进最终结果，等于把验证这一步彻底跳过了。

怎么验证：给子代理的产出定一份可核查的标准

「不能直接采信」这句话说起来容易，难的是怎么验证。凭感觉读一遍、觉得「看着还行」不算验证——那还是停留在「先信任、后验证」落差的前一半。真正靠谱的做法是先定一套具体、可核查的标准，再拿子代理的产出去对照。

官方系统里用过的一套标准是这样的：「我们用一个 LLM 评审员，依据一份评分标准来评估每一份产出：事实准确性（论断是否与来源一致）、引用准确性（引用的来源是否真的支撑了对应的论断）、完整性（是否覆盖了要求的所有方面）、来源质量（是否用了一手来源而不是质量较低的二手来源）、以及工具使用效率（是否合理次数地用对了工具）。」² 这五条标准的共同点是：每一条都能具体核查，不是靠印象打分。「事实准确性」可以逐条对照子代理引用的原文；「完整性」可以对照任务说明里列出的每一项要求，看看是不是都覆盖到了；「工具使用效率」可以直接看调用记录，判断有没有做了明显多余或者重复的调用。

把这套思路搬到你自己的协作场景里，验证一个子代理产出的第一步，不是问「这看起来对吗」，而是先问「针对这次任务，有哪几条标准是可以具体核查的」，把这些标准列出来，再逐条对照子代理的产出。

重复劳动：几个子代理做了同一件事

第 3 课讲过，任务说明写得不够清楚，会导致子代理曲解任务、跟别的子代理做完全一样的搜索²。这是失败的根源，但失败真正暴露出来，往往是在结果汇总的这一刻——编排者收到几份子代理的产出，发现其中两份高度重叠，讲的其实是同一件事，只是措辞不同。

重复劳动本身不算灾难性错误——内容没错，只是浪费了本该覆盖到别的角度的那部分 token 和调用次数。但它是一个信号：说明某几个子代理的任务边界划得不够清楚，值得回头检查一下派工时的任务说明，而不只是在这一次结果里手动去重就算完事。发现一次重复劳动，比起单纯把重复内容删掉，更值得做的是搞清楚重复的原因——是两份任务说明本身范围重叠，还是子代理各自理解偏了、往同一个最容易想到的方向扎堆。

结果冲突：两个子代理给出了矛盾的结论

比重复劳动更麻烦的情况是结果冲突：就像本课开头那一幕——两个子代理各自调研，交回来的结论互相矛盾，一个说入门套餐每月 20 美元起，另一个说 25 美元起。这种情况不能靠「随便挑一个」或者「取个中间值」来打发，两种做法都可能把一个错误的数字当成最终结论端上去。

遇到结果冲突，合理的处理顺序是：先看两边各自的依据是什么——是不是查的信息源不一样，一个用了官网当前页面、另一个不小心用了缓存的旧页面；如果依据能查清楚，通常能判断出哪一份更可信，替换掉不可信的那一份；如果依据本身也说不清楚谁对谁错，不要在整合阶段自己拍板选一个，应该把这处矛盾原样标注出来，交给人工复核，或者派一个新的子代理专门去核实这一处分歧。结果冲突暴露出的问题，往往比重复劳动更值得警惕——它说明至少有一份子代理产出是错的，如果不处理直接放进最终结果，就是把一个未经核实的错误包装成了「已完成」的结论。

结果整合与去重：编排者收尾要做的事

把几份子代理产出拼成最终结果，不是简单地首尾相连，而是要过一遍前面讲的这几类问题：有没有重复的内容需要合并、有没有互相矛盾的结论需要核实或标注、每一处论断是不是都能找到对应的依据。这最后一点尤其容易被忽略——第 3 课提到过官方系统里专门设了一个 CitationAgent，作用是「处理文档和调研报告，专门找出该在哪些具体位置加引用，确保所有论断都被正确归属到对应的来源」²，这背后的道理放在结果整合阶段同样成立：几份子代理的产出汇总到一起之后，容易出现「张冠李戴」——把子代理 A 查到的数据，写成了子代理 B 负责的那家公司的结论。整合阶段核实每处论断的来源归属，跟核实事实本身是否准确同样重要。

去重、核实冲突、核对来源归属，这三件事合在一起，才是「汇总」这一步真正要做的工作——而不是像第 2 课提醒过的那样，把几份子代理的原始回复直接拼接了事。

小结

• 子代理返回结果时的「已完成」「准确无误」只是自我表态，不是证据。没有它能自己跑的检查时，「看起来完成」就是它唯一的信号¹；官方明确指出会出现「产出看起来合理但没处理边界情况」的落差，没法验证就不该直接采用¹。
• 验证不能停留在「读着还行」，要针对具体任务定出可核查的标准——像官方 LLM 评审员依据的那套评分标准一样，事实准确性、引用准确性、完整性、来源质量、工具使用效率都能逐条对照核查²。
• 重复劳动是任务边界没划清楚的常见后果²，通常在结果汇总时才会暴露出来；发现重复不只是删掉多余内容，更值得回头检查派工时的任务说明。
• 结果冲突——两个子代理给出互相矛盾的结论——不能靠随便选一个或者取中间值处理，应该先核实各自依据的可信度，判断不出高下时要原样标注出来，交给人工复核。
• 结果整合阶段要同时做三件事：去重、核实冲突、核对每处论断的来源归属是否张冠李戴²，这才是「汇总」这一步真正的工作内容，不是简单拼接子代理的原始回复。

>> 第 6 课：实战：搭一个双 Agent 评审流水线