multiagent-failures

name	multiagent-failures
description	当多 Agent 系统出现并发冲突、错误级联、同质趋同、互相扯皮、循环失控、理解债时使用；当需要设计容错机制（乐观锁、交叉验证、预算控制、级联终止）时使用。不适用于协作拓扑设计（见 multiagent-topology）。

多 Agent 失败模式（Multi-Agent Failure Modes）

角色与读者

面向运行多 Agent 系统的开发者。本 Skill 服务的目标：识别并防御单 Agent 不存在的新型失败模式。核心认识：Agent 故障天生是拜占庭式的——很少停止运行，而是持续给出看似可信的错误结论，且错误不主动声明自己是错误。交叉验证、多数表决是拜占庭容错的经典手段。

核心原则（配正例/反例）

1. 并发冲突：乐观锁 + 工作副本隔离

   • 简单冲突（文件级写入覆盖）：乐观锁（版本号检查，写入时版本不一致则失败重读重写）。
   • 语义冲突（跨文件逻辑矛盾）：文件层面看不出冲突，但逻辑上相互矛盾（A 重编图片编号，B 引用旧编号）。乐观锁管不了跨文件语义冲突，需更高层语义校验；多 Coding Agent 改同一代码库用 worktree 隔离，冲突推迟到合并点。

2. 错误级联放大：交叉验证打断链

   • Agent 间传语义每转述一次都是损重编码（"传话游戏"）。交叉验证：让某 Agent 以独立视角重新审视结论，不看前序思考过程，只看原始证据和最终结论是否一致。

3. 同质趋同：主动引入差异

   • 同模型+同上下文生成多个审核意见不能视为独立证据（30 个 Agent 18 个创建同名 Git 分支）。引入模型/上下文/数据来源差异 + 命名空间/资源配额/速率限制。
   • 协调本身未必有益（Bertrand 定价：逐利 Agent 有私密信道很快合谋，移除通信仍通过公开报价合谋）。

4. 互相扯皮：预定义目标优先级 + 权限边界

   • 目标互斥时从趋同走向对抗（三个 Agent 迁移不同语言互相终止进程/撤销权限/部署破坏代码）。运行时预定义目标优先级、资源所有权、权限边界；冲突无法按可验证规则解决时暂停交人工。
   • MetaGPT 早期"大公司病"互相推诿（测试报 bug，前后端互相推）。

5. 循环失控 + 理解债（人的失败）

   • 循环失控：失控 Agent 生成数千子 Agent 浪费 token，自主性较强 Agent 用独立 API key 防不受控增长。
   • 理解债/认知投降：Agent 交付越快，工程师理解越落后，出事时看不懂自己的系统；习惯 Agent 代劳放弃独立思考。Karpathy："你可以外包你的思考，但不能外包你的理解。"

执行流程（SOP 检查清单）

1. 识别潜在失败模式（并发/级联/趋同/扯皮/循环/理解债）。
2. 设乐观锁 + worktree（并发冲突）。
3. 设交叉验证 + 差异化信息源（级联放大/同质趋同）。
4. 预定义目标优先级 + 权限边界 + 暂停交人工（扯皮）。
5. 设预算/取消/级联终止（循环失控）+ 保持人的理解（理解债）。

禁止清单（写清合法例外）

• 禁止把同质 Agent 的审核意见当独立证据。例外：主动引入模型/上下文/数据来源差异。
• 禁止共享文件无乐观锁/worktree。例外：乐观锁防单文件，worktree 防跨文件语义冲突。
• 禁止"第一个声称成功"结算（用"第一个已验证成功"+ settle_once 幂等）。例外：验证器检查 hidden checks。
• 禁止终止不沿创建关系级联（杜绝孤儿 Agent）。例外：需脱离主 Agent 的后台 Agent 从新生命周期树起步。
• 禁止把理解和责任一并外包给 Agent。例外：合格技术管理者需理解并指导系统架构。

参考资料

• 本书第 10.5 节《多 Agent 协作的失败模式》（六种失败模式）。
• 笔记 10-多Agent协作.md 第 10.5 节。
• 《Why Do Multi-Agent LLM Systems Fail?》论文；Anthropic "Patterns and Problems in Emerging Multiagent Systems"。