多智能体 LLM 系统为何失败（以及如何构建不失败的系统）

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。

三大故障类别

研究将多智能体故障分为三大类：规范与设计 (42%)、智能体间错位 (37%) 和 任务验证与终止 (21%)。让我们具体审视每种情况。

规范与设计 (42%)

这指的是智能体甚至开始相互通信之前发生的故障。最常见的原因包括：

• 模糊的角色定义 — 智能体职责重叠，缺乏明确的所有权
• 糟糕的任务分解 — 子任务过于精细（导致大量交接）或过于宽泛（单个智能体试图做太多事情并静默截断）
• 缺失的约束条件 — 没有 token 预算、迭代限制、超时设置或定义的输出格式
• 未定义的完成标准 — 系统如何知道任务已实际完成？

解决方案是像对待 API 契约一样对待智能体规范。使用 schema 定义输入和输出。设置明确的停止条件。如果你不会发布一个没有规范的 API，那么也不要发布一个没有规范的智能体。

一个有用的思维模型是：每个智能体都应该有一个角色描述、一套具有明确访问权限的工具、一个输入 schema、一个输出 schema、成功标准和失败标准。这并非官僚主义 — 而是另一个智能体（或协调器）与之可靠交互所需的最小接口。

智能体间错位 (37%)

这一类别涵盖了智能体尝试协调但协调失败的情况：

• 上下文崩溃 — 一个智能体的输出超出了另一个智能体的上下文窗口，导致关键状态悄悄丢失
• 格式不匹配 — 智能体 A 生成 YAML，智能体 B 期望 JSON，但中间没有验证步骤
• 资源所有权冲突 — 两个智能体写入同一位置，造成竞态条件
• 自然语言歧义 — “处理订单”对不同的智能体而言意味着不同的事情，这取决于它们累积的上下文

这里的解决方案模式是结构化通信协议。自然语言对人类来说很好，但对于大规模的机器间协调来说则糟糕透顶。JSON-RPC、Protocol Buffers 或任何经过 schema 验证的消息格式都能显著减少此类故障。每条智能体间消息都应在边界进行验证，而非隐式信任。

对于资源所有权，规则很简单：一个智能体拥有一个资源。如果两个智能体需要共享状态，应通过一个具有明确语义的显式共享内存层进行传递，而不是让每个智能体独立读写同一位置。

上下文丢失更棘手。实际的缓解措施是设计智能体交接，使其只包含接收智能体实际需要的内容，而不是发送智能体的完整对话历史。想象一下设计一个好的函数签名 — 不要传递整个程序状态，而要传递相关的参数。

任务验证与终止 (21%)

这是最容易被忽视的故障模式：系统认为成功了，但输出却是错误的。

其子类型：

• 过早终止 (6.2%) — 智能体在任务实际完成之前发出完成信号
• 不完整的验证 (8.2%) — 验证步骤存在但检查了错误的内容
• 错误的验证 (9.1%) — 验证器本身对正确性进行了不正确的推理

有效的模式是：一个独立的判断智能体，拥有自己独立的上下文和预定义的评分标准。这并非冗余 — 而是应用于 LLM 智能体的基本分布式系统原则。产生输出的智能体不应该是验证它的那个；否则就会陷入循环推理。

普华永道 (PwC) 报告的结果说明了其影响：将结构化验证循环和判断智能体添加到基于 CrewAI 的代码生成管道后，准确率从 10% 提升到了 70%。任务相同，模型也相同。区别在于验证架构。

协调开销问题

贯穿这三大类故障的一种模式是协调开销饱和。每次智能体间交接都会增加 100-500 毫秒的序列化和网络延迟。随着后续智能体从先前输出中重建上下文，token 消耗会不断增加。达到某个阈值时，协调成本将超过并行化的好处。

这就是为什么“投入更多智能体”往往是应对性能不佳的错误方法。更多的智能体意味着更多的状态同步、更多的过时状态传播机会以及更高的尾部延迟。

对于大多数工作流，在添加智能体之前需要回答的问题是：这个智能体并行化了什么，是单个智能体上下文内无法并行化的？如果答案是“什么都没有，但看起来像是清晰的关注点分离”，那么这就是一个进行整合的信号。

当任务是高并发、大部分独立且需要最小智能体间状态共享时，多智能体架构被证明是最可靠的。一旦协调变得频繁，可靠性曲线就会急剧下降。

经久不衰的架构模式

考虑到故障分类法，一些结构模式始终优于临时的多代理设计：

明确状态管理的层级编排。 顶层编排器维护权威的系统状态。工作代理接收该状态的限定视图，根据其执行操作，并返回结构化结果。编排器合并结果并管理状态转换。这是 LangGraph 的设计核心模式——带有明确节点转换的基于图的状态管理。

基于角色的协调与所有权规则。 每个代理都有一个定义的角色、一套定义的工具以及一套它可以修改的资源。CrewAI 将其作为一流约束实现。实际效果是，对于遵循所有权模型的代理来说，竞争条件在结构上变得不可能发生。

带有超时强制的自适应切换。 当代理 A 等待代理 B，而 B 在 N 毫秒内没有响应时，切换应该发出明确的失败信号，而不是静默超时并无限期重试。重试风暴——多个代理同时重试失败操作——是级联故障的常见来源。断路器和硬超时预算可以防止这种情况。

贯穿始终的关联 ID 和分布式追踪。 每个 LLM 调用和每个代理切换都应携带一个关联 ID。没有这个，在生产环境中调试多代理故障将涉及从断开的日志中重建因果链，这既缓慢又容易出错。

框架选择的实际影响

不同的框架明确了不同的权衡：

• AutoGen — 动态消息传递使其灵活适用于研究型自适应工作流，但这种灵活性也意味着协调契约很容易被隐式处理
• CrewAI — 基于角色的编排和明确的所有权规则使其非常适合预先明确代理职责的业务流程自动化
• LangGraph — 基于图的状态管理和明确的边缘条件对于需要可审计性和合规性的企业部署来说是最易于管理的
• OpenAI Swarm — 分散式切换对于小型系统来说轻量且易于理解，但缺乏规模化所需的验证基础设施

所有这些框架都不能为你解决规范问题。它们提供结构，使你更容易清晰地表达规范——实际良好定义规范的工作仍由工程师完成。

在扩展之前构建可观测性

对于多代理系统而言，投入产出比最高的单一投资是可观测性，而它几乎总是在事后才构建。追踪每个 LLM 调用。记录每次切换。在每个边界捕获输入和输出模式。记录每个代理的 token 计数和延迟。

没有这些，当多代理管道失败时，故障表现为不良的最终输出，没有可见的追溯链。有了这些，故障将表现为特定代理之间特定切换中违反了特定不变性——这是可以诊断和修复的。

实际的最低要求是：带有关联 ID 的结构化日志记录、每个代理每个任务的延迟预算，以及在触发故障前触发警报的 token 预算。

核心洞察

多代理系统的失败方式与分布式系统一样——通过规范空白、协调中断和缺失的验证层——而不是因为单个代理无能。适用的工程学科是分布式系统工程，而不是提示工程。

更好的模型有所帮助，但它们无法解决模糊的角色定义、格式不匹配或缺失的验证步骤。这些是设计问题，需要设计解决方案。构建可靠多代理系统的团队将每个代理边界视为一个服务边界：明确定义的契约、明确的故障模式和独立的验证。