一慢烧全网：多智能体级联实测

多智能体系统最贵的失败不是某个 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 编程：

flowchart TD
    H[健康 pipeline] --> F1
    F1[1.超时留僵尸<br/>调用方放弃 子agent仍在烧] -->|僵尸进程| LEAK[算力泄漏]
    F2[2.部分输出伪装成功<br/>截断JSON/错误混入正文] -->|骗过验证| POISON[毒丸下游]
    F3[3.级联失败<br/>编排器不知该等还是该弃] -->|瘫痪| STALL[整体停摆]
    F4[4.静默降级<br/>低质输出通过校验] -->|最毒| SILENT[结果可信度崩塌]
    F5[5.状态不一致<br/>半写入 半提交] -->|腐烂存储| 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 成本越高。

六、隔离三式：给级联画物理边界

把断路器、舱壁、超时预算组合起来，才构成完整的隔离边界：

# 幂等键：压制递归放大的唯一根
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 触发降级路径：

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 的失败从来不在状态码里，而在上下文和半状态里。