先这样答
多 Agent 的失败模式我按协作链路的位置从头讲到尾。
第一类：交接损耗。上游 Agent 的产出传到下游时关键信息丢了：下游只收到一句「去处理下用户反馈」，不知道用户的原始诉求和上游已确认的事实。每个交接点都是一次有损压缩，链路越长，起点和终点之间的信息差越大。对策：交接消息结构化，字段化地写清背景、已确认事实、期望产出、验收标准，禁止「你看着办」式交接。
第二类：目标漂移。子 Agent 跑着跑着偏了：被自己的工具结果带偏，或者把子任务做成了相邻的任务，最后交回来的东西「相关但不对」。漂移的单 Agent 内部纠偏手段（反思、计划对照）在子 Agent 里同样要有，外加主 Agent 的进度检查点：每个子任务完成后对照验收标准核一遍再继续。
第三类：循环与僵局。两个 Agent 互相踢皮球：修改者改完，评审者打回，再改再打回，无限循环；或者互相等待，集体僵住。对策和单 Agent 死循环一致但更必要：冲突轮数上限、到线引入仲裁（主 Agent 裁决或人工介入）、等待关系上杜绝环。
第四类：错误传播放大。上游一个小错（检索错了一个数），中游基于它推理出一串结论，下游写成报告交出去，错误每过一环放大一次，最后没人知道源头在哪。对策有两层：每个环节的产出带出处和置信度，下游能识别「这是上游断言还是已验证事实」；关键结论设独立校验点，不允许一条链从头错到尾。
排查这些问题的前提是全程留痕：每个 Agent 的输入、输出、决策理由都落轨迹存储，能按任务 ID 回放整条协作链。多 Agent 系统没有轨迹，出了问题无从查起。
面试官会怎么追问
- 怎么监控多 Agent 系统的健康度？ 按链路拆指标：每个交接点的返工率、子任务一次通过率、冲突仲裁触发次数、端到端完成率和轮数分布；哪段指标坏了修哪段。
- 失败模式里哪个最危险？ 错误传播。因为它不报错，系统看起来在正常运转，输出却是错的。所以校验点要设在「成本高的下游动作」之前，比如发出对外消息前。
- 人工应该在哪里介入？ 设计好升级点：仲裁失败、验收不过、高危操作三类场景强制升级人工，其余自动跑。
回答的坑
- 只答「会死循环」。四类模式里交接损耗和错误传播更能看出实战深度，至少要各点到一句。
- 没有留痕和回放。排查能力是多 Agent 工程的底座，主动提出来。
—— 本题完 ——