多智能体系统最贵的失败不是某个 agent 出错，而是**这一个错误会沿着同步等待、毒丸输出、重试风暴三条路径自我放大**。某团队在一次 API 抖动期间实测：放开重试，30 秒内单条对话烧掉约 2 美元 token；加上断路后降到 0.01 美元——**200 倍**的差距全来自一条 flaky API。本轮把多智能体的「级联失败 + 隔离边界」拆开实测：失败如何传播、为什么微服务那套断路器搬过来会失灵、以及幂等键 + 超时预算 + 舱壁这三式如何给级联画上物理边界。 ## 核心账本：三种放大路径 在多智能体拓扑里，一次失败有三条互不相同的放大路径，传统分布式系统的经验只能压住第一条： | 放大类型 | 触发结构 | 理论放大倍数 | 实测常见倍数 | 主治机制 | |---------|---------|------------|------------|---------| | 垂直放大 Vertical | 单 agent 对同一工具重试 | 4×（8000 ctx × 4） | 3–5× | 指数退避 + jitter + Retry-After | | 水平放大 Horizontal | pipeline 步 N 依赖步 N-1 | 3⁵ = 243 | 10–50× | 超时预算 + 步级断路 | | 递归放大 Recursive | A→B→C 委派树整体重试 | 指数爆炸 | 50×+ | 幂等键 + checkpoint | 关键区别：垂直放大发生在**工具层**，水平放大发生在**编排层**，递归放大发生在**委派树**——同一个断路器根本管不到全部三层。 ## 一、垂直放大：8000 token 烧四遍 最简单的一种。一个 agent 持有 8000 token 上下文，调用工具拿到 429。朴素的「重试 3 次」策略意味着原始调用 + 3 次重试 = 4 次 LLM 调用，每次都把完整 8000 token 上下文重新喂进去。结果是 **32000 输入 token 换来零产出**。加上断路器：1 次调用即失败返回，约 8000 token 收尾——4 倍差距。 这一层有微服务没见过的「影子重试」陷阱。微服务里重试逻辑在基础设施层，agent 系统里 LLM 自己看到失败响应就可能换个参数再调一次，**绕过你写在工具层的那套退避**。每次重试还把累积的失败历史一起带上，上下文越滚越大。所以垂直层必须双保险：工具层做退避，同时给 LLM 的系统提示里写死「同一工具连续失败 N 次就停手」。 ## 二、水平放大：一条流水线 243 次重试 当 agent workflow 是步 N 依赖步 N-1 的顺序链，早期一步失败会把毒输入灌给后面所有步。每步 3 次重试 × 5 个依赖步，理论上能产生 3⁵ = 243 次重试。超时能拦住完全爆炸，但实测里 10–50 倍放大是常态。 更阴的是**静默版本**：agent 不报错，而是从降级服务拿到一个残缺或错误结果，原样传给下一步，错误潜伏两三步后才暴露。这时候 debug 要沿整条链回溯找最初的失败点。治本之策是给每步加 fidelity gate——校验上游产物完整度，残缺就拒绝而不是悄悄往下传，把水平放大在第一跳就掐断。 ## 三、递归放大：委派树的指数爆炸 这是传统断路器最无能为力的一种。Agent A 委派给 B，B 委派给 C。C 的工具调用失败，B 重试它的整个 workflow（包含对 C 的委派），A 又重试它的整个 workflow（包含对 B 的委派）——**指数级爆炸**。问题根源：重试决策发生在与失败完全不同的抽象层。A 只看到「子任务失败」就重试，根本不知道这次重试会触发下游几十次重试。 唯一能压住递归放大的是**幂等键**。对委派任务算确定性 ID（输入相同则 ID 相同），子 agent 的结果按 ID 缓存。A 重试对 B 的委派时，如果 B 的那次执行已落地结果，直接取缓存，不再穿透到 C。没有幂等键，任何委派树重试都是定时炸弹。 ## 四、五种真实生产失败模式 把放大路径落到生产，是五种具体死法。它们和 HTTP 状态码无关，**agent 系统必须为这五种而不是为 5xx 编程**： ```mermaid flowchart TD H[健康 pipeline] --> F1 F1[1.超时留僵尸
调用方放弃 子agent仍在烧] -->|僵尸进程| LEAK[算力泄漏] F2[2.部分输出伪装成功
截断JSON/错误混入正文] -->|骗过验证| POISON[毒丸下游] F3[3.级联失败
编排器不知该等还是该弃] -->|瘫痪| STALL[整体停摆] F4[4.静默降级
低质输出通过校验] -->|最毒| SILENT[结果可信度崩塌] F5[5.状态不一致
半写入 半提交] -->|腐烂存储| CORRUPT[下游读到脏数据] style F4 fill:#fdd,stroke:#c00,stroke-width:2px style SILENT fill:#fdd,stroke:#c00,stroke-width:2px ``` 其中第 4 种「静默降级」最危险——它不报错、通过验证、却毒化最终结果，是唯一不会触发任何告警的失败。第 1 种「超时留僵尸」则最隐蔽：调用方 30 秒放弃，但子 agent（一个昂贵的 web search 或大文档分析）可能还在后台跑，持续烧钱烧算力，且没有任何机制能 resume 或 cancel 它。 ## 五、微服务断路器为何失灵：三个错配 直接把微服务的断路器（追踪失败率 → 触发阈值 → 冷却期 fail-fast）搬过来，在 agent 系统会撞上三个硬错配： **粒度不匹配**。微服务断路器管的是服务到服务的调用，agent 系统需要在四层都挂断路器——单次工具调用、每个 workflow 步、每条对话的 token 预算、每条 agent 委派链。只盯工具层会漏掉高层放大。 **非确定性问题**。微服务断路器打开，调用方拿到确定性错误响应；agent 断路器打开，LLM 收到的是工具失败，接下来怎么走**完全由模型决定**——可能优雅降级，也可能幻觉一个答案，还可能「创造性」地绕过失败。断路器管住了基础设施，管不住模型对基础设施失败的反应。 **上下文累积问题**。微服务每次请求独立，断路打开零内存成本；agent 系统每次失败尝试都往对话上下文里加内容，断路器开得越久，下次恢复重试时上下文越肥，token 成本越高。 ## 六、隔离三式：给级联画物理边界 把断路器、舱壁、超时预算组合起来，才构成完整的隔离边界： ```python # 幂等键：压制递归放大的唯一根 def generate_task_id(task_input: dict) -> str: """输入相同 → ID相同 → 安全重试，不穿透下游""" serialized = json.dumps(task_input, sort_keys=True) return hashlib.sha256(serialized.encode()).hexdigest()[:16] ``` **舱壁（Bulkhead）**——把 token 预算和并发槽切成互不相交的池。给每条委派链独立的 token 配额，一条链失控烧爆配额，不会饿死其他链。这是「资源维度的隔离」，防的是一 agent 拖垮全网算力。 **超时预算（Timeout Budget）**——不要给每个 agent 各设独立 30 秒超时。整条链只有一个总 deadline，从根往下传递（deadline propagation），越靠近叶子越紧。这样 A→B→C 链路里 C 不会独占全部时间预算，根 agent 永远留有兜底响应的余量。 **多级断路器**——工具层、步级、委派链各挂一个，三态（closed/open/half-open）独立计数。一旦某条委派链断路打开，根 agent 拿到的是「子任务不可用」而不是「子任务失败」，从而走 fallback 而不是重试。 ## 七、Fallback 三态：失败后该怎么往下走 断路打开或超时触发后，编排器需要显式的 fallback 策略，三种可叠加： **部分结果带 flag**——返回 `{"result": "...", "complete": False}`，让下游知道这是残缺数据，可选择性使用。 **降级模型**——主模型 Sonnet 超时，立刻 fallback 到 Haiku（更快更便宜）出一份简版结果。代码层用 `asyncio.wait_for` 包主调用，`except TimeoutError` 触发降级路径： ```python async def analysis_with_model_fallback(content: str) -> str: try: resp = await asyncio.wait_for( asyncio.to_thread(client.messages.create, model="claude-sonnet-4-6", max_tokens=1024, messages=[{"role": "user", "content": content}]), timeout=20) return resp.content[0].text except asyncio.TimeoutError: # 主模型超时 → 降级 Haiku 出简版 resp = client.messages.create( model="claude-haiku-4-5-20251001", max_tokens=512, messages=[{"role": "user", "content": f"Briefly: {content}"}]) return f"[Abbreviated] {resp.content[0].text}" ``` **跳过继续**——非关键 agent 直接跳过，用现有数据推进，而不是整体停摆。这要求编排器在拓扑设计阶段就标注每个 agent 的 criticality（关键路径 vs 可选增强）。 ## 八、静默降级：唯一不报警的杀手 五种失败里，前四种都会产生超时、错误或瘫痪——至少能被监控抓住。只有静默降级是**完全静默**的：子 agent 没有硬失败，输出低质但通过了校验，最终产出看起来正常，实际已被毒化。生产数据显示多智能体系统 41–86% 的失败率里，相当部分就是这类「看起来成功了」的失败。 对抗静默降级需要独立于业务校验的 **fidelity gate**：用第二个轻量 agent 或规则引擎对子结果做完整性评分（覆盖率、引用数、字段填充率），低于阈值就标记为 degraded 并触发 fallback，而不是默默往下传。校验通过的「形状正确」和「内容可信」是两回事——agent 时代，验证层必须从「检查 schema」升级到「检查语义保真度」。 ## 推荐方案 **轻量 pipeline（≤3 agent，无委派）**：只上「垂直放大」防御即可——工具层指数退避 + jitter + Retry-After，给 LLM 写死连续失败上限。成本最低，能挡住 70% 的日常抖动。 **顺序流水线（5+ 依赖步）**：必加超时预算链式分配 + 步级断路 + fidelity gate。重点防水平放大的静默版本，在第一跳就掐断毒输入传播。 **委派树架构（A→B→C 多层）**：幂等键是底线，没有它任何重试都是炸弹；叠加深层 checkpoint（写前日志 WAL，状态可回放）；给每条委派链独立舱壁配额，断路打开就走 fallback 三态。这一档实施最重，但能扛住递归爆炸这种最贵的事故。 **通用原则**：永远为「超时留僵尸」「部分输出伪装」「静默降级」这三种编程，别只盯着 HTTP 状态码——agent 的失败从来不在状态码里，而在上下文和半状态里。 --- ## 参考来源 1. [The Retry Storm Problem in Agentic Systems: Why Naive Retries Burn 200x the Tokens](https://tianpan.co/blog/2026-04-10-retry-storm-agentic-systems-cascading-failure) — 三种放大路径（垂直/水平/递归）、200× 成本削减实测、微服务断路器三错配 2. [Multi-agent failure handling: timeouts, partial outputs, and recovery patterns](https://www.aicodex.to/articles/multi-agent-failure-handling) — 五种生产失败模式、幂等键实现、timeout+fallback 三态代码 3. [Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657)](https://arxiv.org/abs/2503.13657) — Cemri 等 2025，MAS 在流行 benchmark 上增益与失败分类的学术分析 4. [From Spark to Fire: Modeling and Mitigating Error Cascades in LLM-Based Multi-Agent Systems](https://arxiv.org/abs/2603.04474) — LLM-MAS 中错误级联的建模与缓解 5. [Why do multi-agent LLM systems fail (and how to fix) — 2026 Guide](https://futureagi.substack.com/p/why-do-multi-agent-llm-systems-fail) — 生产环境 41–86% 失败率与修复指引 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。