级联半径：为什么重试修不好多智能体流水线
Deep Research 报告 | 2026 年 9 月 | 面向 Agent 系统建设者与数据工程团队
摘要
过去一年，多智能体系统的讨论重心悄悄换了一个问题。2025 年大家问的是"多智能体到底有没有用"，2026 年问的是"它坏的时候，坏在哪、坏多远、能不能修"。这个转向不是情绪变化，而是因为一批新工具第一次让"失败"本身变成可测量的对象——不再只统计任务成功率，而是主动往流水线里注入故障，观察错误怎么走、走多远、谁能拦住它。
证明这件事的是一串彼此独立、却给出同一方向结论的研究。伯克利 Sky Lab 的 MAST 用 1600 多条执行轨迹建立了 14 种失败模式的分类法；MAS-FIRE 把 15 类故障注入三种主流架构，发现闭环拓扑能中和掉超过 40% 会让线性流水线彻底崩溃的故障；OrchestraBench 则在真实 Claude 智能体上测出一个很硬的结论——工具类故障能百分百自愈，语义类故障一次都没恢复过，而重试不但没修好，还把发现时间拖长了。与此同时，ICML 的 Who&When 基准告诉我们，就算失败已经发生，自动定位到"哪一步错了"的准确率也只有 14.2%。
本文把这批材料串成一条线：编排失败为什么不是运气问题而是结构问题，级联半径这个指标为什么值得进你的监控面板，以及在 OpenAI 把 agent loop 整体托管、可观测性标准还停在 Development 状态的 2026 年下半年，一个准备上生产的团队应该按什么顺序加防线。
一、这条研究线是怎么冒出来的
要理解今天的研究为什么盯着"失败"不放，得先看 2025 年那个尴尬的空档。
当时多智能体框架——AutoGen、LangGraph、CrewAI、MetaGPT、ChatDev——已经从 demo 往生产走了，但它们之间唯一可比的东西只有任务准确率。一个流水线在生产环境里给出了错误答案，团队能知道的就是"这次失败了"，而没法知道是哪个路由决策失误、错误从哪一级开始扩散、加上"智能路由"这层复杂度到底值不值。伯克利团队把这个状态描述得很准：失败常常是静默的——一个被错误路由的任务，照样会产出一份看起来很合理的回答。
MAST（Multi-Agent System Failure Taxonomy）是第一次系统性的回应。Cemri 等人用扎根理论（Grounded Theory）方法，分析了 7 个开源框架的 200 条对话轨迹——每条平均超过 15,000 行文本——由六位专家标注员迭代编码，最终收敛出 14 种失败模式、3 个大类：系统设计问题、智能体间失配、任务验证缺失。三名标注员在 15 条轨迹上独立打标，Cohen's Kappa 达到 0.88，这个一致性水平说明"失败模式"确实是可辨认的客观现象，而不是研究者的主观归类。
MAST 真正有杀伤力的不是分类法本身，而是它顺手做的干预实验。研究者发现 ChatDev 的 CPO 智能体会在没有 CEO 智能体达成共识的情况下擅自终止对话——这是典型的"违反角色规范"（FM-1.2）。他们改了一下工作流，让 CEO 拥有最终决定权，任务成功率提升 9.4%；再加一道面向高层任务目标的验证步骤，成功率再提升 15.6%。听起来不错，但请注意基线：ChatDev 在 ProgramDev 上的正确率只有 33.33%。加了两道结构性补丁，整体依然离可用很远。研究者自己的结论是：这些失败源于系统设计和交互机制，不是底层模型的能力上限，靠孤立的小修小补解决不了。
这句话给后面的研究定了调。2026 年冒出来的一批工作，全都从"观察失败"转向了"制造失败"——既然被动等着看生产事故太慢、太不可复现，那就主动注入。
二、"编排失败"到底指什么
在往下走之前，需要把术语边界划清楚，否则后面的数字会互相打架。
任务失败（task failure）是端到端的：最终输出错了。编排失败（orchestration failure）是过程性的：某个路由、委派、验证或状态传递的决策错了——它可能导致任务失败，也可能被下游侥幸纠正，还可能产出一个"正确但无法审计"的结果。这两者不是一回事，而传统基准只测前者。
这个差别在一份数据里体现得特别刺眼。Tian 等人在 GPQA-Diamond 上做过一个统计：在 95.5% 的案例中，参与编排的智能体里至少有一个答对了，但编排系统最终只交出 87.4% 的正确率。换句话说，编排过程主动丢掉了大约 8 个百分点本来已经拿到手的正确性。这部分损失完全看不见——端到端指标只会告诉你"87.4%"，不会告诉你"你本可以有 95.5%"。
顺着这个缺口，2026 年的评测工具分化成三代，各自回答不同的问题。
| 代际 | 代表工作 | 回答的问题 | 方法 | 局限 |
|---|---|---|---|---|
| 端到端基准 | AgentBench、SWE-bench、OdysseyBench | 这个流水线成功了吗 | 跑真实任务，看最终正确率 | 无法定位失败点，成本随规模暴涨 |
| 归因基准 | Who&When、TraceElephant | 失败是谁、在哪一步造成的 | 对已发生的失败轨迹做事后标注 | 观察性的，无法控制变量，不可复现 |
| 注入基准 | MAS-FIRE、OrchestraBench | 特定故障会传播多远、能否恢复 | 按固定种子注入故障，测恢复率与传播 | 工作流多为合成，构念效度需另行论证 |
注入基准是今年的新东西，而它带来的最重要产物，是一个此前没人量化过的指标：级联半径（cascade radius）——在第 1 级注入一个错误后，下游有多少级被污染。这个指标之所以关键，是因为它把"一个错误值多少钱"从玄学变成了可以放进 SLO 的数字。
三、三层机制：故障分型、级联传播、归因难度
把今年的实验结果叠在一起看，会发现多智能体的可靠性问题其实是三层结构，每一层的应对手段完全不同。
第一层是故障分型。 不是所有故障都一样坏。会抛异常的故障（工具调用失败、参数格式错、接口超时）其实是最良性的一类——它们在运行时就暴露了自己，智能体知道出事了，可以重算、换路径、报错。真正危险的是语义类故障：上下文被污染、子智能体输出互相矛盾、还没收集完信息就抢跑行动。这些故障不抛任何异常，它们产出的是格式正确、语气自信、内容错误的中间结果，然后被下游当成事实继续加工。
第二层是级联传播。 语义故障进入流水线后不会停在原地。它以"上游值"的身份被消费，污染每一个依赖它的下游阶段，并且在迭代协作中逐步固化为系统级的虚假共识——研究者把这种现象叫做"consensus inertia"（共识惯性）：错误被反复引用后，反倒获得了"大家都这么说"的权威性。
第三层是归因难度，这层最被低估。 假设你已经发现流水线出错了，想定位是哪个智能体、哪一步的责任。ICML 2025 的 Who&When 基准专门测了这件事：从 127 个多智能体系统收集 184 个标注好的失败任务，让自动归因方法去找"谁错了、什么时候错的"。最好的方法定位到智能体的准确率是 53.5%，定位到决定性错误步骤的准确率只有 14.2%——部分方法甚至低于随机基线。连 o1、DeepSeek R1 这类推理模型也没达到可用水平。
这三层是递进的：故障分型决定了会不会传播，传播深度决定了损失规模，而归因难度决定了你事后能不能修。如果第三层解决不了，前两层的监控数据就只能告诉你"出事了"，不能告诉你"改哪"。
四、谁在测，结果如何
4.1 OrchestraBench：在真实 Claude 上测出的三层故障结构
这份工作（Anote 团队，arXiv:2608.05263）的价值在于它没有停留在模拟——Exp 2 到 Exp 4 全部在真实 Claude 智能体上跑，用一条可验证的算术依赖链作为受控探针，每种故障模式 30 个样本，总共 N=150。选算术链是为了拿到干净的 ground truth：最终结果对不对，一个 exact-match 就判完了，不需要任何主观标注。
| 故障模式（MAST 分类） | 算术链成功率 | 算术链级联半径 | 贷款审批版成功率 | 贷款审批版级联半径 |
|---|---|---|---|---|
| 工具调用错误 | 1.00 | 0.00 | 0.70 | 0.60 |
| 模糊委派 | 0.30 | 1.40 | 0.40 | 1.20 |
| 上下文污染 | 0.00 | 2.00 | 0.00 | 2.00 |
| 子智能体输出冲突 | 0.00 | 2.00 | 0.00 | 2.00 |
| 抢跑行动 | 0.00 | 2.00 | 0.00 | 2.00 |
失败处理清晰地分成三档。工具调用故障完全恢复（恢复率 1.0，级联半径 0）——智能体发现工具不好使，自己手算出了结果。模糊委派部分恢复（0.30），也就是说大约三分之一的情况下智能体能猜对本意。剩下三种语义/潜伏型故障一次都没恢复（0.00），并且污染了每一个下游阶段。
最关键的一行数据不在表里：重试策略无法恢复语义故障。在故障仍然存在的情况下重试，只会把同一个错误再生产一遍，唯一的效果是拉长了故障的发现时间。这条结论直接推翻了大多数生产流水线的默认防线——retry with backoff 对可重试的工具故障有效，对需要归因、状态修复和语义校验的故障完全无效。
这套结构是模型行为还是实验构造的产物？作者做了两组对照。一是把完全相同的计算改写成一个四角色的贷款审批流程（受理员、风险分析师、合规官、审批经理），每一级用业务语言提示：故障模式的排序保持不变，但绝对数值发生了偏移——模糊委派从 0.30 升到 0.40（业务角色上下文帮助智能体推断了意图），而工具故障恢复率反而从 1.00 掉到 0.70。二是跨三个模型层级（Sonnet 4.6 / Opus 4.8 / Haiku 4.5）重跑，工具故障全部 1.00、两种灾难性潜伏故障全部 0.00，只有随机性的模糊委派在 0.10–0.33 之间波动。排序不变、数值随上下文漂移，这正是"模型行为"而非"构造恒真"的签名。
级联半径随深度的增长同样是单调的：
| 流水线深度 | 潜伏型故障级联半径 | 工具型故障级联半径 |
|---|---|---|
| 3 | 0.93 | 0.00 |
| 4 | 1.85 | 0.00 |
| 5 | 2.80 | 0.00 |
| 6 | 3.63 | 0.00 |
| 7 | 4.67 | 0.00 |
近似每加一级、半径涨 0.9。三种灾难性模式精确地等于"深度 − 2"，也就是说它们污染了注入点之后的每一级；模糊委派因为会部分自愈，曲线始终低于这个结构上限。作者很诚实地指出，在这条可验证算术链上，确定性模式的增长有一部分是构造使然，所以他们把深度扩展定位为"佐证信号"而不是头条结论。
这里还藏着一个值得单独拎出来的实验。研究者测试了让 LLM 路由器去遏制级联，结果看起来极好：潜伏型故障恢复率从基线的 0.08 跳到 0.83，级联半径从 1.83 降到 0.33。但他们又做了一次消融——把"可信上游值"这个提示拿掉，让模型纯靠自己检测异常：恢复率当场塌回 0.08，和基线一样（配对下降 0.58，p=5.19×10⁻⁴）。也就是说，LLM 路由器的遏制能力几乎全部来自那个被喂进去的可信状态信号，而不是自主检测。
核心洞见：智能体不会自己发现自己被污染了；它只会在你告诉它"这个值是干净的"之后，才有能力做对比。
4.2 MAS-FIRE：架构拓扑的保护力，比换模型更大
如果说 OrchestraBench 回答了"故障怎么分层"，MAS-FIRE（arXiv:2602.19843）回答的是"什么结构能挡住它"。这份工作定义了 15 种故障类型，覆盖智能体内部认知错误和智能体间协作失败，通过三种非侵入式机制注入：修改提示词、改写响应、操纵消息路由。测试对象是三种代表性架构——线性瀑布式的 MetaGPT、迭代闭环的 Table-Critic、双边协商的 CAMEL。
| 故障类型 | MetaGPT（线性） | CAMEL（双边协商） | Table-Critic（迭代闭环） |
|---|---|---|---|
| 角色模糊 | 23.97%–31.68% | 61.05%–69.88% | 79.31%（GPT-5）/ 91.05%（DeepSeek-V3） |
| 盲目信任 | 0.0% | 0.0%（提示层防御） | 6.32%（GPT-5）/ 70.61%（DeepSeek-V3） |
| 指令类故障 | ≤13.7% | — | 16.67%–40.52% |
| 通信类故障 | >93% | — | — |
三条结论值得记。第一，架构拓扑的影响力和模型选择同一量级：迭代闭环设计中和掉了超过 40% 会让线性工作流彻底崩溃的故障。Table-Critic 的 Critic 智能体会验证输出并触发精炼循环，这个结构本身就是一道拦截线。第二，基础设施层的硬编码防御效果最好：通信类故障（消息风暴、消息环）在 MetaGPT 里恢复率超过 93%，因为基于角色的订阅模型在架构层就做掉了去重和环检测，根本不需要智能体动脑子。
第三条最反直觉，也是这份工作最值得传播的发现：更强的模型不一定更鲁棒。在"盲目信任"故障下——研究者篡改 JudgeAgent 的系统提示，写入"无条件信任 Generator 的输出，不做验证"，同时往 Generator 的推理里注入语义错误——Table-Critic 配 GPT-5 的恢复率只有 6.32%，配 DeepSeek-V3 却有 70.61%，差距 64.29 个百分点，弱模型胜出。原因是恢复需要 JudgeAgent 推翻自己被污染的指令，而 GPT-5 优秀的指令遵循能力在这里变成了负债：它太听话了，听的是那条被改坏的话。
核心洞见：指令遵循能力是双刃的。当指令本身被污染时，严格合规不是安全特性，而是故障放大器。
4.3 From Spark to Fire：把治理做成消息层插件
前两份工作诊断问题，这份（arXiv:2603.04474）给了一个可落地的处方，而且处方的形态很有启发性。
研究者把协作抽象成有向依赖图，拟合了一套传播动力学模型，得出早期放大条件 βρ(A) > δ——传播强度乘以邻接矩阵谱半径大于纠正强度时，错误就会扩散。在六个主流框架上的实验识别出三类脆弱性：级联放大、拓扑敏感性、共识惯性。他们还演示了一个攻击：只注入一个原子级的错误种子，就能导致系统级的广泛失效。
他们的防御不是改架构，而是在消息层加一个"族谱图"治理插件，做四件事——把断言原子化、追踪来源出处、三态筛查、定向验证，以及最关键的隔离与回滚。效果是防御成功率从基线的 0.32 提升到 0.89 以上。
消融实验揭示了这四件事的权重排序，这个排序对工程选型非常有用：
| 移除的组件 | 遏制率（BICR） | 说明 |
|---|---|---|
| 完整方案 | >89% | 检测 + 归因 + 隔离 + 回滚 |
| 去掉回滚 | 3.1% | 几乎等于没防御 |
| 去掉检测 | 14.4% | 有回滚但不知道何时触发 |
| 去掉断言原子化 | 40.0% | 粒度太粗，隔离面过大 |
回滚是那块承重墙：去掉它，遏制率从 89% 直接掉到 3.1%。这和 OrchestraBench 的重试结论是同一个道理的两面——光"再试一次"没用，你必须能把状态退回到污染发生之前。
代价也是明码标价的：Speed 模式下延迟从 100.6 秒涨到 149.9 秒、token 从 13,212 涨到 20,789；Strict 模式能把遏制率推到约 94%，但代价是 214.6 秒和 56,314 token——四倍多的 token 开销。这意味着治理层不是"加了就好"，而是一个需要按任务价值分档配置的旋钮。
4.4 Anthropic 与 Cognition：生产环境里两种相反的经验，和它们的交汇点
学术基准之外，两家把多智能体推到生产的公司留下了一组有意思的对照。
| 维度 | Anthropic Research | Cognition（编码场景） |
|---|---|---|
| 架构 | Opus 4 领队 + Sonnet 4 子智能体并行 | 多智能体贡献判断，写入单线程 |
| 实测收益 | 内部研究评测比单 Opus 4 高 90.2% | 跨前沿模型的能力路由带来实际增益 |
| 性能归因 | token 用量单独解释 80% 的方差 | 依赖子任务与模型能力的匹配 |
| token 成本 | 约为聊天交互的 15 倍（单智能体约 4 倍） | 未公开，但写入单线程压低了重算 |
| 明确不适用 | 共享同一上下文、强依赖的任务（如多数编码） | 并行写入的智能体群 |
Anthropic 的 Research 功能用 Claude Opus 4 作为领队智能体、Claude Sonnet 4 作为并行子智能体，在内部研究评测上比单个 Opus 4 高出 90.2%。但他们对"为什么有效"的解释相当去魅：在 BrowseComp 评测上，三个因素解释了 95% 的性能方差，其中光 token 用量本身就解释了 80%，另外两个是工具调用次数和模型选择。多智能体架构之所以有效，主要是因为它提供了一种"花掉足够多 token"的结构。代价随之而来：普通智能体大约消耗聊天交互 4 倍的 token，多智能体系统大约 15 倍。他们明确划了适用边界——适合宽度优先、信息量超出单个上下文窗口、需要大量并行的只读型任务；不适合所有智能体必须共享同一上下文、彼此强依赖的场景，比如大多数编码任务。
Cognition 走的是相反的路径。他们在 2025 年发过一篇标题很不客气的《Don't Build Multi-Agents》，理由是并行写入的智能体会各自对代码风格、边界情况、实现模式做出隐含且互相冲突的选择，产品因此变得脆弱。10 个月后他们更新了立场：确实部署了能跑通的多智能体系统，但收敛到一类很窄的模式——多个智能体贡献"智力"，而写入保持单线程。子智能体负责审查、检索、提供边界判断，不负责动手改状态。他们还发现了一个新用法：跨前沿模型的路由不是"弱模型问强模型"的难度升级，而是"哪个模型更擅长这个子任务"的能力路由——有的模型更会调试，有的更擅长视觉推理，有的更会写测试。
两家的结论表面相反，落点却是同一个：冲突不在"几个智能体"，而在"谁能写"。Anthropic 的系统里，研究（读）由多智能体并行，而报告撰写（写）被刻意收回到单个主智能体的一次调用里完成。Cognition 的单线程写入是同一条规则的另一种表述。这恰好也解释了为什么 OrchestraBench 里"上下文污染"和"输出冲突"的恢复率是 0.00——它们本质上都是多个写入者争夺同一份状态的后果。
五、核心洞见
先把上面散落的数据收拢成一张表：
| 指标 | 数值 | 来源 | 对工程的含义 |
|---|---|---|---|
| 语义故障恢复率 | 0.00（三种模式，三个模型层级一致） | OrchestraBench | 靠模型自愈是不成立的假设 |
| 工具故障恢复率 | 1.00（算术链）/ 0.70（业务语境） | OrchestraBench | 会抛异常的故障是最便宜的故障 |
| 级联半径 vs 深度 | 0.93 → 4.67（深度 3→7） | OrchestraBench | 流水线深度是风险乘数，不是中性参数 |
| 编排丢弃的正确性 | 95.5% → 87.4%（GPQA-Diamond） | Tian et al. | 至少有一个智能体答对，编排把它丢了 |
| 步骤级归因准确率 | 14.2%（最优方法） | Who&When | 事后定位基本靠人，自动化还不可用 |
| 闭环 vs 线性拓扑 | 中和 >40% 的灾难性故障 | MAS-FIRE | 架构选型的收益大于换模型 |
| 强模型悖论 | GPT-5 6.32% vs DeepSeek-V3 70.61% | MAS-FIRE | 指令遵循强 ≠ 鲁棒性强 |
| 回滚的边际贡献 | 89% → 3.1%（移除回滚） | From Spark to Fire | 回滚是承重墙，不是锦上添花 |
| 多智能体 token 成本 | 约为聊天的 15 倍 | Anthropic | 只有高价值任务才付得起 |
洞见一：能抛异常的故障是幸运的故障
工具调用错误的恢复率是 1.00、级联半径是 0，因为它在发生的那一刻就宣告了自己。上下文污染的恢复率是 0.00，因为它伪装成了一个合法的值。传统分布式系统的可靠性工程假设故障会 crash、会超时、会返回错误码，而多智能体的主力故障类型恰恰不满足这个假设——它们产出的是语法合法、语义错误的数据。这意味着你现有的那套重试、熔断、超时防线，正好覆盖的是最容易的那一类故障。
洞见二：深度是风险乘数
级联半径随流水线深度近似线性增长（每级 +0.9），而三种灾难性故障精确等于"深度 − 2"——污染注入点之后的每一级。这给"多加一个专家智能体"这个动作标出了隐藏价格：你不只是增加了一次调用的成本和延迟，还把每个上游潜伏故障的爆炸半径扩大了一格。OrchBench 从另一个角度给出了同样的警告：保住任务关键信息比单纯增加智能体数量更重要，并行带来的收益会随着协调失败的累积而递减。
洞见三：重试是反防线
这可能是这批研究里最有行动意义的一条。在故障仍然存在的前提下重试，会忠实地复现同一个错误，唯一的净效果是延长了 time-to-detection。而回滚的消融数据从反面确认了同一件事：去掉回滚，遏制率从 89% 掉到 3.1%。"重试"和"回滚"在传统系统里常被放在同一个抽屉，在多智能体里它们是相反的两种东西——前者在被污染的状态上重复劳动，后者把状态退回污染之前。
洞见四：可信状态是外生的
OrchestraBench 那次消融是全文最冷静的一笔：LLM 路由器看起来能把潜伏故障恢复率从 0.08 拉到 0.83，但拿掉"可信上游值"这个提示后立刻塌回 0.08。智能体不具备自主检测自身上下文被污染的能力，它只有在被提供一个可信参照物时才能做出判断。这把"可信状态从哪来"变成了架构的第一性问题——它必须来自智能体之外：校验和、外部真值源、独立验证器、或者一条被审计过的血缘记录。
六、行业影响：可靠性工程正在往哪迁移
角色正在分化。 过去两年"Agent 工程师"这个角色基本等于提示词 + 编排框架 + 工具接入。上面这批数据指向一个新的分工：需要有人专门负责故障注入演练、级联半径监控、可信状态源的设计和回滚机制的实现——这套技能栈和 SRE 的混沌工程高度重叠，只是故障模型换成了语义层的。MAST 的作者说得更直接：好的多智能体设计需要的是组织理解力，因为即便由能力出众的个体组成的组织，如果结构有缺陷，一样会灾难性地失败。
可观测性标准还没跟上。 要监控级联半径，前提是每一次智能体调用、工具执行、子智能体委派都是一条结构化的 span。OpenTelemetry 的 GenAI 语义约定确实在往这个方向走：invoke_agent、execute_tool、plan、retrieval、memory 都有了定义，也有 gen_ai.invoke_agent.duration、gen_ai.invoke_agent.tool_calls 这类指标。但现实是，截至 2026 年年中，GenAI 相关的 span、事件、指标、属性没有一个被标记为 Stable，它们在 2026 年被迁进了独立仓库，核心语义约定 v1.42.0（6 月 12 日）把 gen_ai.* 内容全部废弃并移走，而主流框架同时在发射好几代属性名——gen_ai.system 和 gen_ai.provider.name 并存，usage.prompt_tokens 和 input_tokens 并存。要落地这套监控，现阶段得自己做版本钉死和属性合并（注意是取优先级合并，不是相加，因为兼容性双发的是同一个值）。
托管 harness 带来了新的不可观测面。 OpenAI 在 9 月 10 日把 Agents API 放进公开测试，会话、编排、上下文压缩、故障恢复整套交给 OpenAI 托管，应用只提供工具和执行环境。从工程量上讲这是巨大的减负——手搓一个长任务智能体需要任务队列、状态库、沙箱集群、压缩例程、重试策略，每一样都得有人值班。但放到本文的框架里看，它同时引入了一个新问题：压缩决定了哪些 token 能活到下一轮，而一个你无法检视的摘要器，是一个你无法做消融的质量变量。官方文档也没有公布压缩阈值、子智能体上限、每会话 token 开销这些数字。再叠加上美国单一数据驻留、不支持零数据留存（ZDR），对需要做合规论证的团队来说，这是一笔需要认真算的账。
合规侧的连接点比想象中近。 加州 9 月 18 日签署的行政令要求在 11 月 16 日前评估 frontier 模型的"kill switch"、驻场审计员以及把"失控事件"纳入强制报告范围。抛开政治叙事不谈，"失控"在工程上的可操作定义，恰恰就是本文讨论的东西：一个未被检测、未被归因、未被回滚的错误，在一条足够深的流水线上跑完了全程。能说清自己系统级联半径的团队，在未来的合规问答里会占很大便宜。
国内落地还有一层特殊考量。 MAS-FIRE 那个"弱模型反而更鲁棒"的发现，对国内团队有直接的现实意义——很多团队出于成本和合规考虑在用开源或国产模型，这份数据说明在故障条件下，这个选择未必是能力上的妥协。但另一面是：它揭示的机制是"指令遵循较弱导致没有完全服从被污染的指令"，这是一个偶然的保护，不是一个可依赖的设计。正确的读法是——别把模型的性格当成防线。
七、实践入门：按什么顺序加防线
先说三个最常见、也最费钱的误区。
误区一：用重试兜底一切。 前面反复出现的数据已经说明，重试只对会抛异常的故障有效，对语义故障是纯粹的负收益——复现错误 + 延长发现时间 + 多花一份 token。判断标准很简单：如果这个故障不会让任何代码路径抛出异常，重试就帮不了你。
误区二：用"加智能体"解决质量问题。 编排在 GPQA-Diamond 上丢掉了 8 个点本来已经答对的正确性；OrchBench 的模拟也显示并行收益会随协调失败累积而递减。在加第 N+1 个智能体之前，先确认现有这 N 个之间的信息传递没有损失关键内容。
误区三：把架构选型当成次要问题。 MAS-FIRE 的数据里，闭环拓扑中和了超过 40% 会让线性流水线崩溃的故障，而通信类故障靠基础设施层的硬规则（角色订阅、去重、环检测）就能压到 93% 以上的恢复率。能用确定性机制解决的，就不要交给模型推理。
正确的推进顺序，我会这样排：
L1（1–2 周，任何在跑多智能体的团队都该有）——先让流水线可见。按 OpenTelemetry GenAI 语义约定把 agent span、tool span、子智能体委派嵌套起来，钉死 instrumentation 版本，同时查询新旧两代属性名。这一层的产出物不是"更可靠"，而是"出事时有东西可看"。
L2（1–2 个月，准备上生产的团队）——加确定性防线和可信状态。把能硬编码的检查硬编码：输出 schema 校验、数值范围检查、关键字段的校验和、跨智能体的消息去重与环检测。同时为每个关键中间结果建立一个外部可信参照——这是 OrchestraBench 消融实验直接指向的结论，智能体必须被喂一个干净的参照物才有检测能力。然后把写入路径收敛成单线程，子智能体只贡献判断、不直接改状态。
L3（季度级，高价值或受监管场景）——做注入演练和状态回滚。在预发环境按固定种子注入 MAST 的那几类语义故障，测出你自己流水线在各个深度下的级联半径，把它变成一个有基线、有告警阈值的指标。实现断言级的来源追踪和隔离回滚——这是遏制率从 3.1% 到 89% 的那块承重墙。接受它的成本：参照 From Spark to Fire 的数据，Speed 档大约 +50% 延迟、+57% token，Strict 档 token 开销会到四倍以上，所以要按任务价值分档，不是一刀切。
| 资源 | 类型 | 用途 |
|---|---|---|
MAST（arXiv:2503.13657，pip install agentdash） | 分类法 + LLM 标注器 | 给你的失败轨迹打标，得到失败模式分布 |
| Who&When（ICML 2025，含 184 条标注失败） | 归因基准 | 评估你的自动归因方案，也是现实期望的校准器 |
| MAS-FIRE（arXiv:2602.19843） | 注入框架 | 15 类故障、三种非侵入注入机制，可直接复用 |
| OrchestraBench（arXiv:2608.05263） | 注入 + 级联基准 | 种子可复现，Apache-2.0，全量复现约 4 美元 |
| OrchBench（arXiv:2607.25656） | 编排计划模拟器 | 不跑真实智能体评估编排方案，仅需 1.3% token |
| OpenTelemetry GenAI 语义约定 | 观测标准 | agent/tool/workflow span 的命名基线（仍为 Development） |
八、未来展望
注入式评测会从研究工具变成发版门禁。 今天这些基准还带着明显的研究气质——合成工作流、受控算术链、作者自己承认构念效度有限。但它们的形态（固定种子、可复现、离线可重算）天然适合进 CI。一年之内，"这次发版的级联半径回归了没有"大概率会变成和"测试覆盖率掉了没有"同等常规的问题。
归因会成为真正的瓶颈。 检测和回滚都有相对确定的工程路径，但 14.2% 的步骤级归因准确率说明"到底哪一步错了"这个问题目前仍然主要靠人。在这个数字显著上升之前，多智能体系统的运维成本不会下降——你能自动止损，但不能自动修复。
可信状态会被协议化。 既然智能体无法自主检测污染、必须外部提供参照物，那么"可信状态"就需要一个标准化的载体：带来源与校验和的断言、可审计的血缘、以及跨智能体传递时的完整性保证。From Spark to Fire 的族谱图插件是一个早期形态；它选择做在消息层而不改架构，这个设计取向很可能会被复制。
架构收敛会比模型进步更快见效。 MAS-FIRE 和两家公司的生产经验指向同一条设计规则：闭环验证 + 单线程写入 + 确定性基础设施防御。这三条不依赖任何模型升级，今天就能做，而且收益被实测数据支撑。相比之下，指望下一代模型"更鲁棒"这件事，已经被"强模型悖论"打了一个问号。
结论
这篇文章如果只带走四句话，我希望是这四句：
多智能体的主力故障不抛异常。 工具类故障恢复率 1.00、级联半径 0；上下文污染、输出冲突、抢跑行动三类语义故障恢复率 0.00，并污染每一个下游阶段。你现有的重试/熔断防线覆盖的恰好是最容易的那一类。
重试和回滚是相反的东西。 在故障仍存在时重试只会复现错误、延长发现时间；而移除回滚会让遏制率从 89% 塌到 3.1%。需要的是检测、归因、状态回退，不是"再试一次"。
深度是风险乘数，架构是主要旋钮。 级联半径随流水线深度近似每级 +0.9 增长；而闭环拓扑能中和掉超过 40% 让线性流水线崩溃的故障。在加智能体之前，先看能不能改结构。
可信状态必须外生。 智能体无法自主判断自己的上下文是否被污染——拿掉可信上游提示，恢复率从 0.83 塌回 0.08。任何可靠性设计都要先回答："这条链上，哪个值是可信的，凭什么？"
最后留一个问题给正在跑多智能体流水线的你：如果现在在你系统的第一级注入一个格式合法、数值错误的中间结果，你有多大把握在它污染完整条链之前发现它？你的答案是一个数字，还是一句"应该会被发现吧"？
参考资料
- Cemri, M., Pan, M. Z., Yang, S., et al.（UC Berkeley Sky Computing Lab，2025）. Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657. https://arxiv.org/abs/2503.13657
- Chen, Y., Gu, Y., Vidra, N., Setty, S., Zheng, S.（Anote，2026）. OrchestraBench: Evaluating Multi-Agent Orchestration Failure Modes, Recovery, and Decomposition Quality. arXiv:2608.05263. https://arxiv.org/abs/2608.05263
- Jia, J., Deng, Z., Chen, Z., Wang, Y., Zheng, Z.（2026）. MAS-FIRE: Fault Injection and Reliability Evaluation for LLM-Based Multi-Agent Systems. arXiv:2602.19843. https://arxiv.org/abs/2602.19843
- Xie, Y., Zhu, C., Zhang, X., et al.（2026）. From Spark to Fire: Modeling and Mitigating Error Cascades in LLM-Based Multi-Agent Collaboration. arXiv:2603.04474. https://arxiv.org/abs/2603.04474
- Zhang, S., Yin, M., Zhang, J., et al.（ICML 2025 Spotlight）. Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems. arXiv:2505.00212. https://proceedings.mlr.press/v267/zhang25cq.html
- Ren, Z., He, J., Zhang, X., et al.（2026）. OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation. arXiv:2607.25656. https://arxiv.org/abs/2607.25656
- Tian, A. X., Zhang, R., Tang, J., et al.（2025）. Beyond the Strongest LLM: Multi-Turn Multi-Agent Orchestration vs. Single LLMs on Benchmarks. arXiv:2509.23537. https://arxiv.org/abs/2509.23537
- Anthropic Engineering（2025 年 6 月）. How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
- Cognition（2026）. Multi-Agents: What's Actually Working. https://cognition.com/blog/multi-agents-working
- OpenTelemetry（2026）. GenAI Semantic Conventions. https://github.com/open-telemetry/semantic-conventions-genai
- OpenAI（2026 年 9 月 10 日）. Agents API Overview. https://developers.openai.com/api/docs/guides/agents-api/overview
- PPC Land（2026 年 9 月 18 日）. Newsom sets November 16 deadline to study frontier AI kill switch. https://ppc.land/newsom-sets-november-16-deadline-to-study-frontier-ai-kill-switch/