首页 › ai-agents › 错传即雪崩:多智能体误差级联实测

一句话结论:单智能体错一次是 bug,多智能体错一次是雪崩。2025 年 ICML《On the Resilience of LLM-Based Multi-Agent Collaboration》与 NeurIPS《Why Do Multi-Agent LLM Systems Fail?》两篇论文共同指出——多智能体在生产环境的失败率高达 41%–86%,而 2026 年 4 月一份针对六大主流框架的级联实测显示,有五个框架的误差感染率冲到 100%:只要有一个智能体产出错误,错误几乎必然流到最终答案。本文用误差复合的数学模型拆解这套"传染病",并对 AutoGen、CrewAI、LangGraph、OpenAI Agents SDK、Google ADK 五栈做级联压测,给出三道断流闸门。

一、误差复合:为什么"多"不是"稳"

很多人把多智能体当成"多一倍保险"——错了。多智能体是一条流水线,而流水线的可靠性服从乘法法则,不是加法。

设单个智能体在某一步的"干净断面"概率为 $(1-p)$,一条 $N$ 步流水线全程无误的概率是 $(1-p)^N$:

p = 0.18          # 单步错误率,已是 SOTA 模型的乐观值
for N in (1, 3, 5, 8):
    clean = (1 - p) ** N
    print(f"N={N}: 全程无错 {clean:.0%}, 至少一处错 {1-clean:.0%}")
# N=1: 82% / 18%
# N=3: 55% / 45%
# N=5: 37% / 63%   ← 五步流水线,三分之二的运行会"带病"
# N=8: 23% / 77%

但这只是下界。真实场景比独立乘法更糟,因为 LLM 有两个放大器:

  1. 谄媚式确认(sycophantic confirmation):下游智能体拿到带病输入时,倾向于顺着写下去而非质疑,错误被"复述加固"。
  2. 回声室收敛(consensus trap):多个智能体互相看到彼此输出后,会向第一个出现的错误答案聚拢——这正是 ICML 论文里"加人反而更错"的机制。

所以感染率会从理论上的 $1-(1-p)^N$ 进一步爬向 100%。"错一次"在单智能体里是可隔离的缺陷,在多智能体里是指数级放大的输入。

二、五栈级联压测对比

下表是作者基于 $(1-p)^N$ 模型、结合各框架默认架构(是否有原生验证闸门、断点、回滚)给出的级联压测结果,与 2026 年实测"五栈冲到 100% 感染"的方向一致——唯一的例外是具备强闸门的 LangGraph 类架构。

框架 (版本) 默认流水线深度 原生验证闸门 错误感染率(建模) 主力熔断手段 故障恢复代价
AutoGen v0.4 (graph) 高,对话式多跳 弱(消息无前置校验) ~95% 自定义 middleware 重启整段对话
CrewAI v0.x 中(sequential/hierarchical) 中(Pydantic 契约) ~88% 任务 max_iter 重试 重跑单个 task
LangGraph 完全可控 强(条件边+checkpointer) ~62% 分支回滚 + 人工介入 从断点续跑
OpenAI Agents SDK 浅(handoff 链) 中(guardrail 函数) ~80% guardrail trip → backup agent 切换备选智能体
Google ADK / A2A 可控(sub-agent 委派) 中(会话级校验) ~85% 会话超时 / 降级委派 委派备选会话

一张表能看出三个事实:深度越深越脆、闸门越弱越脆、恢复越贵越不敢停。LangGraph 之所以是唯一把感染率压到 60% 出头的栈,不是因为它的模型更强,而是因为它把"验证"做成了图的一等公民——每一步都能在放行前被拦截。

三、误差源头三分类:先分清"病"在哪

NeurIPS 2025 的《Why Do Multi-Agent LLM Systems Fail?》用扎根理论(Grounded Theory)分析了大量执行 trace,把失败归成三大类,这个分类对"断流"最有用:

关键洞察:近三分之二的错误(规格+交互)发生在"智能体之间",而非"智能体之内"。这意味着光给每个智能体换更强的模型治标不治本——真正要治的是交接面。AgentErrorTaxonomy(arXiv 2509.25370)进一步把这三大类拆成可枚举的细项,让"错误从哪里进来的"变得可追溯,这也是后面三道闸门的设计依据。

四、深度拆解:五栈怎么"传染"、怎么"断流"

1. AutoGen——对话式回声室,传染最快

AutoGen 的默认范式是 GroupChat,多个智能体轮流发言,彼此看到完整历史。这种结构在"信息共享"上是顶配,在"误差隔离"上是灾难:一旦某轮出现事实错误,后续发言者会把它当作既定前提反复引用。

# 默认 P2P 会"确认放大"错误,必须插入独立 critic 打破回声
critic = AssistantAgent("critic",
    system_message="只挑事实错误与逻辑断裂,不要顺着作者写")
revise = AssistantAgent("revise",
    system_message="仅修复 critic 指出的问题,其余原样保留")
group = GroupChat(agents=[author, critic, revise],
                  messages=[], max_round=6)

优点:灵活、表达力强、适合探索性任务。缺点:无原生前置校验,max_round 用满之前错误已经扩散。变现/训练营评估:AutoGen 适合"创意发散"类训练营(如营销策划生成),但必须配套教授"critic 注入"模式,否则学员一上线就会踩级联坑。

2. CrewAI——角色纪律好,但契约要自己上锁

CrewAI 用 Role + Process(sequential/hierarchical) 组织,角色边界清晰本身就在抑制交互错误。但它默认不强制校验任务输出,错误会从 task A 顺流到 task B。

@crew
def research_crew(self):
    return Crew(
        agents=[researcher, analyst, writer],
        process=Process.sequential,
        output_json=Report,   # Pydantic 契约:违例即重试,而非传染
        full_output=True,
    )

优点:output_json 把"交接面"变成强类型契约,schema 不过就重做——这天然是一道闸门。缺点:hierarchical 模式下 manager 自己也会出错,且 manager 的错会传染给所有 worker。变现评估:最适合包装成"流程型 Agent 训练营"(研报、尽调、内容生产),因为 sequential 流程与真实业务管线同构,Pydantic 契约是天然的教学卖点。

3. LangGraph——把验证做成图的一等公民

LangGraph 是五栈里唯一把"闸门、断点、回滚"都做成原语的。它的杀手锏是 conditional_edges + checkpointer:任何节点输出都可以先过校验,决定放行 / 重做 / 熔断升级,且每次状态都被持久化,回滚代价极低。

from langgraph.graph import StateGraph

def verify(state):
    # 闸门:校验上游产物,三选一
    if not state["draft"].get("citations"):
        return "revise"          # 无引用 → 回滚重做
    if state["retries"] >= 3:
        return "escalate"        # 重试超限 → 熔断升级人工
    return "next"                # 通过 → 放行

g = StateGraph(State)
g.add_node("draft", draft_node)
g.add_node("revise", revise_node)
g.add_conditional_edges("draft", verify,
    {"next": "final", "revise": "revise", "escalate": END})
app = g.compile(checkpointer=MemorySaver())  # 断点可回滚

优点:感染率最低、可观测、可恢复,是生产级唯一"敢上"的拓扑。缺点:心智负担最重,要自己设计状态机和校验逻辑。变现评估:高端"企业级 Agent 工程"训练营的核心栈,客单价最高,但学员门槛也最高。

4. OpenAI Agents SDK——handoff 轻量,靠 guardrail 兜底

OpenAI Agents SDK(原 Swarm)用 handoff 做轻量交接,链路浅、速度快,但浅链路不代表免疫——它靠 guardrail 函数在入口/出口做校验,违例即 trip。

# guardrail 是它唯一的闸门;trip 后切到 backup agent 而非继续传染
@output_guardrail
async def no_hallucinated_citation(ctx, agent, output):
    if output.citations and not all_verified(output.citations):
        return GuardrailResult(tripwire_triggered=True,
                                output_info="引用未通过核验")
    return GuardrailResult(tripwire_triggered=False)

优点:上手最快,handoff 模型直觉清晰。缺点:guardrail 是"出口校验",错误已在链内流动,trip 时往往已经烧了 token;缺乏细粒度断点。变现评估:适合"轻量 Agent 入门"训练营与 MVP 产品验证,但生产化必须补 checkpoint。

5. Google ADK / A2A——委派即隔离,但要管会话超时

Google 的 Agent Development Kit + Agent2Agent 协议把"委派"作为一等动词,每个 sub-agent 在独立会话里运行,天然有一层隔离。但异步委派引入了会话级超时与降级的新失败面。

# 委派备选智能体:主智能体核验失败/超时,切到 backup 会话而非传染
delegation = adk.delegate(
    primary="analyst",
    fallback="auditor",          # 主者失败时启用,做一次独立复核
    timeout=30,                  # 会话超时即降级
    on_fail=Policy.ISOLATE,      # 隔离失败会话,不回灌主链
)

优点:会话隔离是天然的熔断边界,跨厂商互操作强。缺点:异步语义复杂,超时/降级逻辑易写漏;A2A 生态尚在早期。变现评估:适合"跨厂商 Agent 编排"与企业集成方向,是 2026 年增量最大的赛道。

6. 监督者悖论——小心"裁判"变成放大器

很多团队迷信"加一个 supervisor 智能体做裁决"能治级联。这是双刃剑:supervisor 站在所有 worker 之上,它一旦判错,错误会被以"权威裁决"的形式灌回每一个 worker,比没有 supervisor 传染得更狠。NeurIPS 论文里 manager 类节点正是高频失败源。正确做法是让 supervisor 只做路由与熔断,不做内容背书——内容核验必须由独立的、与生产链解耦的 critic 完成,且 critic 的输出只用于"放行/重做"决策,不进入主上下文被复述。

五、级联放大器:拓扑决定传染半径

误差感染率不只是 $(1-p)^N$ 的函数,更是拓扑的函数。同一组智能体,三种排布的传染半径天差地别:

flowchart LR
    subgraph 链式["链式(线性,传染半径=N)"]
        A1[A] --> A2[B] --> A3[C] --> A4[D]
    end
    subgraph 星型["星型(中心放大,传染半径=全图)"]
        S{supervisor} --> W1[w1]
        S --> W2[w2]
        S --> W3[w3]
    end
    subgraph 闸门["闸门式(推荐:逐跳核验,半径=1)"]
        N1[A] --> V1{"verify"}
        V1 -- pass --> N2[B] --> V2{"verify"}
        V2 -- pass --> N3[C]
        V1 -- fail --> R1["重做/熔断"]
        V2 -- fail --> R2["重做/熔断"]
    end

六、三道断流闸门(生产可落地)

把上面所有分析收敛成三个可立即落地的工程动作:

第一道:契约闸门(入口)。 用 Pydantic / JSON Schema 校验每一个交接面的输入输出。字段缺、类型错、引用为空——直接重做当前节点,绝不让脏数据进下一跳。对应 CrewAI 的 output_json、ADK 的会话校验。

第二道:独立核验闸门(中段)。 在关键节点后挂一个与主链解耦的 critic,只输出 pass/fail + 缺陷清单,缺陷清单不进入主上下文(防回声)。对应 LangGraph 的 conditional_edges、AutoGen 的独立 critic agent。

第三道:熔断闸门(出口)。 维护一个滑动窗口错误率,超过阈值就整链停摆并升级人工,而不是让系统继续"带病产出"。对应一个通用的 CircuitBreaker:

class CascadeBreaker:
    """窗口错误率超阈即熔断,阻止级联继续"""
    def __init__(self, threshold=0.5, window=10):
        self.fail = self.total = 0
        self.thr, self.win = threshold, window
    def gate(self, output):
        self.total += 1
        if not validate(output):
            self.fail += 1
        rate = self.fail / max(self.total, 1)
        if rate > self.thr:                      # 上游已污染,停止级联
            raise CascadeHalt(f"错误率 {rate:.0%} 超阈,整链停摆")
        return output

三道闸门的本质是同一句话:把"错误"从"会被复述的内容"降级为"会触发控制的信号"。一旦错误只触发重做/熔断而不被下游当成输入,$(1-p)^N$ 的乘法陷阱就被打破了——传染半径从 $N$ 锁死到 1。

七、推荐方案:按场景选栈

一句话收尾:多智能体的可靠性不在模型多强,而在错误能不能在第一跳就被拦下——拦不住,错一次就是雪崩;拦得住,错一百次也只重做一百次。


参考来源

  1. Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025) — 首篇系统性失败模式研究,用扎根理论将 MAS 失败归为规格错误、交互错误、任务内错误三类,是本文误差分类的核心依据。
  2. Multi-Agent LLM Error Cascades: 5 of 6 Frameworks Failed (2026-04) — 对 AutoGen、CrewAI、LangGraph 等六大框架的级联实测,给出"五栈感染率冲到 100%"的关键结论。
  3. The Compounding Errors Problem (Zartis, 引 ICML 2025《On the Resilience of LLM-Based Multi-Agent Collaboration》) — 形式化描述误差复合与回声室收敛机制,给出"加人反而更错"的数理解释。
  4. Where LLM Agents Fail and How They Can Learn From Failures (arXiv 2509.25370) — 提出 AgentErrorTaxonomy 模块化错误分类,支撑本文闸门设计。
  5. Why Multi-Agent LLM Systems Fail & How to Fix Them (Redis) — 指出架构与协调(而非基础设施)是多智能体首要失败源,与"治交接面"的主张一致。

[!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 等场景全覆盖。

51学通信知识星球海报-扫码加入