MAST 失效模式与对策
前置：知道多个 Agent 可以分工协作。不需要读过那篇论文，也不需要用过任何多智能体框 架。
你把一个任务拆给三个 Agent：一个查资料，一个写代码，一个负责验收。跑起来之后，你会陆续看到这些画面：
| 你会看到的 | 它有名字，叫 | 实测占比 |
|---|---|---|
| 查资料的那个把同一个关键词搜了四遍，每次都像第一次搜 | 步骤重复 FM-1.3 | 15.7% |
| 写代码的在思考里说「我应该先读一下现有实现」，下一步直接开始改文件 | 推理与行动不一致 FM-2.6 | 13.2% |
| 三个都停了，但没有任何一个宣布任务结束，于是空转到超时 | 不知道何时该停 FM-1.5 | 12.4% |
| 验收的说「已通过测试」，而测试根本没跑起来 | 验证做错了 FM-3.3 | 9.1% |
这些看起来像是模型不够聪明。UC Berkeley 的 MAST 把这件事量化了：实测 7 个主流框架、1,642 条执行轨迹，失败率在 41% 到 86.7% 之间。更关键的是他们的结论 ——
Many MAS failures arise from … organizational design rather than limitations of individual agents.
大部分失败源于组织设计，而不是单个 Agent 的能力限制。
也就是说，换一个更强的模型救不了你，得改的是这几个 Agent 之间怎么分工、怎么传话、谁说了算。
好消息是这些失败不是随机的，它们有固定的形状。MAST 把它们归成了 14 种，每种都给了实测频率。本篇拿这 14 种当骨架，逐条对上五个已经在生产上跑的产品源码里的真实对策 —— 看看它们各自是怎么把这些坑填掉的。
一、MAST 数据基础
| 项 | 值 |
|---|---|
| 论文 | Why Do Multi-Agent LLM Systems Fail?（arXiv 2503.13657） |
| 方法 | Grounded Theory，150 条 trace 建分类法（单条平均 >15,000 行），扩展标注 1,642 条 |
| 覆盖框架 | 7 个开源 MAS 框架 |
| 标注者一致性 | Cohen's κ = 0.88（6 位专家） |
| 评测模型 | GPT-4、Claude 3、Qwen2.5、CodeLlama |
| 失败率区间 | 41% – 86.7%（Figure 5：ChatDev 最低 ~41%，OpenManus 最高 ~86.7%） |
| LLM 自动标注器 | o1 提示 + few-shot，准确率 94%，κ = 0.77 |
二、14 个失效模式（按实测频率排序）
三大类：FC1 系统设计、FC2 智能体间失配、FC3 任务验证。
| 排名 | 编号 | 失效模式 | 频率 | 类别 |
|---|---|---|---|---|
| 1 | FM-1.3 | Step repetition（步骤重复） | 15.7% | 系统设计 |
| 2 | FM-2.6 | Reasoning-action mismatch（推理与行动不一致） | 13.2% | 智能体间失配 |
| 3 | FM-1.5 | Unaware of termination conditions（不知道何时该停） | 12.4% | 系统设计 |
| 4 | FM-1.1 | Disobey task specification（不遵守任务规格） | 11.8% | 系统设计 |
| 5 | FM-3.3 | Incorrect verification（验证做错了） | 9.10% | 任务验证 |
| 6 | FM-3.2 | No or incomplete verification（没验证 / 验证不全） | 8.20% | 任务验证 |
| 7 | FM-2.3 | Task derailment（任务跑偏） | 7.40% | 智能体间失配 |
| 8 | FM-2.2 | Fail to ask for clarification（该问不问） | 6.80% | 智能体间失配 |
| 9 | FM-3.1 | Premature termination（过早终止） | 6.20% | 任务验证 |
| 10 | FM-1.4 | Loss of conversation history（丢失对话历史） | 2.80% | 系统设计 |
| 11 | FM-2.1 | Conversation reset（对话被重置） | 2.20% | 智能体间失配 |
| 12 | FM-2.5 | Ignored other agent's input（无视其他 Agent 的输入） | 1.90% | 智能体间失配 |
| 13 | FM-1.2 | Disobey role specification（不遵守角色规格） | 1.50% | 系统设计 |
| 14 | FM-2.4 | Information withholding（信息不传递） | 0.85% | 智能体间失配 |
三类合计：系统设计 44.2%、智能体间失配 32.35%、任务验证 23.5%。
这三个合计值是按 Figure 1 的各模式频率逐项相加得出，论文本身只给到模式级；引用时应说明是推导值。
头部四个模式占 53.1%，而且这四个全都能用工程手段直接堵住 —— 不需要更强的模型，只需要在对的位置写几行代码。下面逐条看它们各自长什么样、又是被什么代码堵住的。
2.1 三大类的占比分布
三、失效模式 → 生产对策映射
这是全专题的核心索引。左边是 MAST 的失效模式，右边是五个产品源码里实际存在的防护。
3.1 FC1 · 系统设计（44.2%）
| 失效模式 | 频率 | 产品源码里的对策 | 出处 |
|---|---|---|---|
| FM-1.3 步骤重复 | 15.7% | Suna runaway-turn-guard.ts：同一 parent message 连续重复 3 次即中止（含子会话）DeerFlow loop_detection_middleware.py：动作模式识别Kimi CLI max_steps_per_turn=1000：兜底截断 | 06 05 02 |
| FM-1.5 不知何时停 | 12.4% | Manus 把「待机」做成显式工具 idle——用工具调用表达终止，不靠解析文字DeerFlow 限流触发时下发替代方案而非单纯拒绝 | 03 05 |
| FM-1.1 不遵守任务规格 | 11.8% | Manus Planner 模块外置，以「带编号伪代码」下发，要求走完全部编号步骤 Manus todo.md 每完成一项即更新，把目标推回注意力窗口末端 | 03 |
| FM-1.4 丢失对话历史 | 2.80% | Kimi CLI 每实例独立 context.jsonl，resume 时复用存盘的 system promptSuna 温 fork 会话 id 去碰撞（共享 pinned root 导致串台的真实事故） | 02 06 |
| FM-1.2 不遵守角色规格 | 1.50% | Kimi CLI 双保险：提示词声明只读 + exclude_tools 物理剥离写工具DeerFlow 直接剥掉子 Agent 的 ask_clarification / present_files | 02 05 |
FM-1.2 的关键洞察：单靠提示词约束不住模型；单靠剥离工具，模型会用 Shell 的 sed -i 绕过去。必须两层都做。
3.2 FC2 · 智能体间失配（32.35%）
| 失效模式 | 频率 | 产品源码里的对策 | 出处 |
|---|---|---|---|
| FM-2.6 推理行动不一致 | 13.2% | Manus「保留错误」：失败轨迹留在上下文里，模型据此隐式修正 Manus「别被 few-shot」：序列化格式故意引入变化，防模式锁定 | 03 |
| FM-2.3 任务跑偏 | 7.40% | todo.md 复述机制（对抗 lost-in-the-middle）Planner 伪代码为权威， todo.md 冲突时以 Planner 为准 | 03 |
| FM-2.2 该问不问 | 6.80% | 反向设计：Kimi CLI / DeerFlow 明确禁止子 Agent 直接问用户，要求把歧义写进给父 Agent 的总结里 | 02 05 |
| FM-2.1 对话重置 | 2.20% | Kimi CLI 实例状态机 + 并发 resume 拒绝；派发前同步落状态（asyncio.create_task 只排队不执行） | 02 |
| FM-2.5 无视他人输入 | 1.90% | Claude Code SendMessage + 兄弟名册（唯一支持横向通信的）其余四家用星型拓扑直接消除这个模式 | 04 |
| FM-2.4 信息不传递 | 0.85% | Kimi CLI SUMMARY_MIN_LENGTH=200：摘要过短强制重写一次DeerFlow 委派台账确定性截断，防过长撑爆父上下文 | 02 05 |
FM-2.2 值得单独说：MAST 认为「该问不问」是失效模式，但生产产品故意禁止子 Agent 提问。这不矛盾——子 Agent 直接插话会打断主流程的交互契约，正确做法是把歧义上报给父 Agent，由父 Agent 决定要不要问用户。失效模式的对策不一定是「允许它做」，也可能是「换个层级做 」。
3.3 FC3 · 任务验证（23.5%）
| 失效模式 | 频率 | 产品源码里的对策 | 出处 |
|---|---|---|---|
| FM-3.3 验证做错 | 9.10% | OpenHands security/：_shell_ast.py 把命令解析成语法树再判风险（正则拦不住 X=rm; $X -rf /）ensemble.py 多分析器投票 | 07 |
| FM-3.2 没验证 / 不完整 | 8.20% | Kimi CLI run_soul_checked 校验末条消息 role 必须是 assistantDeerFlow read_before_write_middleware.py 强制先读后写 | 02 05 |
| FM-3.1 过早终止 | 6.20% | Kimi CLI 摘要下限 + 重写 Manus 要求「必须走完 Planner 的全部编号步骤」 | 02 03 |
MAST 的案例研究结论要注意：他们在 AG2 MathChat 上做验证增强得到 +15.6%，在 ChatDev 上调工作流得到 +9.4%——有效，但远不够。论文明确说这类战术修补不足以根治，问题在组 织设计层面。
四、拓扑分类法
MDPI 的编排综述（覆盖 2023–2026，文献截止 2026-03）给出三拓扑分类，外加一条动态自适应控制轴：
| 拓扑 | 本专题中的实例 | 特点 |
|---|---|---|
| 中心化 | Manus Wide Research、Kimi CLI、DeerFlow、Anthropic Research | 主 Agent 派活收活；生产主流 |
| 去中心 | Claude Code 的 SendMessage（部分） | 兄弟可直接通信；冲突处理成本高 |
| 分层 | Claude Code 默认 3 层嵌套；ROMA 递归分解 | 深度可控但成本指数增长 |
工业界对同一组拓扑的画法（LangGraph 官方）：
两种最常落地的中心化变体——Supervisor（主管制），由中心节点决定下一个执行者：
Swarm（蜂群制），Agent 之间直接交接控制权，无中心：
图片来源：同上。
实测分布：本专题拆的五个生产产品里，五个都以中心化星型为主干，只有 Claude Code 额外开放了去中心（SendMessage）和分层（3 层嵌套）选项。Swarm 在生产产品中未见采用——交接语义带来的状态一致性成本，在真实任务里回报为负。
生产采用数据（该综述引用）：
| 指标 | 值 |
|---|---|
| 组织中已有 Agent 上生产 | 57.3%（LangChain 2025 State of AI Agents） |
| 主要场景 | 客服 26.5%、研究与数据分析 24.4% |
| Gartner 多智能体咨询量增长 | +1,445%（2024 Q1 → 2025 Q2） |
| 研究型编排的 token 开销 | 约为对话式的 15 倍（与 Anthropic 官方数字一致） |
五、协议层
协议互操作综述（arXiv 2505.02279） 对比四个协议：
| 协议 | 传输 / 形态 | 解决什么 | 发现机制 |
|---|---|---|---|
| MCP | JSON-RPC 客户端-服务端 | Agent ↔ 工具：安全调用、类型化数据交换 | 服务端声明 |
| ACP | RESTful HTTP，MIME 多部分消息 | 通用通信，同步/异步，运行时无关 | 轻量注册 |
| A2A | 点对点任务外包 | Agent ↔ Agent：基于能 力的 Agent Card，企业级工作流 | Agent Card |
| ANP | W3C DID + JSON-LD 图 | 开放网络的 Agent 发现与安全协作 | 去中心身份 |
论文给出的分阶段采用路径：MCP（工具接入）→ ACP（结构化多模态消息、会话感知）→ A2A（协作任务执行）→ ANP（去中心 Agent 市场）。
落到本专题：五个产品全部处在第一阶段（MCP 或自研工具接入），没有一个把 A2A 用在核心链路上。Kimi CLI 甚至对子 Agent 关掉了 MCP（mcp_configs=[]）。跨组织 Agent 协作目前仍在标准先行、落地滞后的阶段。
六、五个对照维度
MAST 讲「会怎么坏」，下面五个维度讲「怎么造」。02–07 每篇末尾都填这张表。
| 维度 | 问什么 | 取值范围 |
|---|---|---|
| D1 隔离单位 | 「一个子 Agent」物理上是什么 | 函数调用 → 上下文窗口 → 进程/容器 → 虚拟机 |
| D2 通信拓扑 | 子 Agent 之间能否直接说话 | 星型（不能）／共享空间／点对点 |
| D3 结果回收 | 父 Agent 能看到多少、谁裁剪 | 全文／LLM 摘要／确定性截断／仅末条消息 |
| D4 递归深度 | 子 Agent 能否再派子 Agent | 硬禁止／深度上限／不限 |
| D5 生命周期 | 用完即弃还是可复活 | 一次性／可 resume／跨会话记 忆 |
D1 有一条反直觉的规律：隔离越重，可支撑的并发越高。
| 隔离单位 | 代表 | 并发量级 | 原因 |
|---|---|---|---|
| 虚拟机 | Manus | 上百 | 横向扩展只受基础设施限制 |
| 容器/沙箱 | Suna | 数十 | 同上，但单机密度更高 |
| 上下文窗口（同进程） | Kimi CLI | 未硬编码 | 受进程资源约束 |
| LangGraph 分支（同进程） | DeerFlow | 3 | 同上，且显式限流 |
所以「要不要上重隔离」等价于「要不要几十上百路并行」。
七、全专题对照总表
| Kimi CLI | Manus | Claude Code | DeerFlow | Suna | |
|---|---|---|---|---|---|
| D1 隔离 | context.jsonl | 虚拟机 | 上下文窗口 / git worktree | LangGraph 分支 | 沙箱容器 |
| D2 拓扑 | 星型 | 星型（官方禁止通信） | 星型 + SendMessage | 星型 | 星型 |
| D3 回收 | 末条消息，<200 字重写 | 主 Agent 综合 | 仅最终结果 | 确定性截断 2000 字 | 由 OpenCode 负责 |
| D4 递归 | 硬禁止（三重） | 未公开 | 默认 3 层 | 默认禁止 | 继承 OpenCode |
| D5 生命周期 | 前台/后台/resume | 一次性 | background / memory / fork | checkpointer 续跑 | 温 fork / 失控中止 |
| 并发上限 | 未硬编码 | 上百 | 未公开 | 3 | 沙箱数决定 |
| 步数上限 | 1000/轮 | 均值 ~50 | maxTurns 可配 | 150 / 60 | 由 OpenCode 决定 |
| 子 Agent 用 MCP | 禁止 | —— | 按 Agent 配 | 有路由中间件 | 继承 |
| Agent 循环 | 自研 52,049 行 | 自研 | 自研 | LangGraph + 40 中间件 | 包 OpenCode |
09 那篇 补的两家在同一张表上的取值，单独列出来，因为它们在 D1 和 D5 上落在上面五家覆盖不到的位置：
| Grok Bot | grok-4.20-multi-agent | |
|---|---|---|
| D1 隔离 | 共享计算机上的一块屏幕，官方声明非安全边界 | 服务端不可见的一个 agent 槽位 |
| D2 拓扑 | 点对点 + 2–6 人群聊 | 星型，leader 汇总 |
| D3 回收 | 消息文本（Bot 间交接仅文本）+ 共享文件系统 | 只回 leader 的工具调用与终稿，子 Agent 全程加密 |
| D4 递归 | 无嵌套概念，账号上限 50 个 Bot | 未公开，agent_count 是唯一旋钮 |
| D5 生命周期 | 持久具名实体，跨会话保留记忆、文件、登录态 | 单次请求，多轮靠 previous_response_id |
| 并发上限 | ≤ 50，每 Bot 同时 1 个操作任务 | 4 或 16，二选一 |
| Agent 循环 | 闭源产品 | 在 xAI 服务端，你碰不到 |
D1 的取值范围因此要往回补一档：上面那条「函数调用 → 上下文窗口 → 进程/容器 → 虚拟机」的阶梯默认隔离越重越好，Grok Bot 证明了还有一条岔路——故意把隔离做薄，换持久化与交接成本。
八、延伸材料
下一篇：02 Kimi CLI——唯一完整开源的一线产品子 Agent 调度实现。