为什么多智能体 AI 架构总是失败（以及你应该构建什么）

大多数构建多智能体系统的团队都会遇到同一堵墙：系统在演示时效果出色，但在生产环境中却分崩离析。这并不是因为他们实现协作协议的方式不对，而是因为协议本身就是问题所在。

多智能体 AI 具有一种直观的吸引力。复杂的任务应该被分解为并行的工作流；专门的智能体应该处理专门的工作；编排器（orchestrator）将它们组合在一起，整体就会大于部分之和。这种直觉是错误的——或者更准确地说，它还不成熟。研究表明，在已研究的执行追踪中，多智能体系统在生产环境中的实际失败率在 41% 到 86.7% 之间。这不是调优问题，而是结构性问题。

复合错误问题比你想象的更严重

链式智能体的失败概率计算是残酷的，而且大多数工程师都低估了它。如果每个智能体步骤的成功率为 90%（这对于复杂任务来说已经很乐观了），那么一个包含 10 个步骤的多智能体链的成功率仅为 35%。如果每步的准确率下降到仍然体面的 85%，那么 10 步链条的成功率大约只有 20%。

这并非 AI 所特有——这与你在任何具有顺序依赖关系的系统中看到的可靠性下降是一样的。但智能体链比典型的分布式系统更糟糕，原因有两个。首先，错误不会显性地表现出来。一个做出错误推断的智能体通常会产生看起来合情合理的输出，而不是抛出异常。下游智能体将该输出视为事实（ground truth）。其次，没有回滚。当第三阶段的智能体根据第一阶段的幻觉做出决定时，你直到最后才会发现——而撤销它需要人工干预。

团队通常会使用验证智能体（verification agents）来缓解这种情况：由一个单独的 LLM 环节来审查每个阶段的输出。这有所帮助，但也会增加延迟、成本和另一个错误来源。你并没有解决复合错误问题，只是在链条中增加了更多步骤。

当智能体不共享上下文时会发生什么

并行智能体更深层次的问题是上下文碎片化（context fragmentation）。当你将任务分配给不同的智能体时，每个智能体只能看到自己的工作，而看不到其同级智能体同时做出的决定。

考虑一个现实的场景：你正在构建一个代码生成系统，其中有一个设计智能体和一个实现智能体并行工作。设计智能体决定使用事件驱动架构（event-driven architecture）。而实现智能体根据相同的原始规范，假设使用的是请求-响应（request-response）模型。两个智能体都产出了各自合理的输出。集成步骤收到了两个不兼容的组件，并不得不协调它们——这项任务通常比单独构建任何一个组件都要困难。

发生这种情况是因为行动带有隐性决策。当智能体编写代码时，它不仅仅是在解决既定问题；它还在做出数十个制约下游工作的小型架构选择。一个并行工作的智能体在无法看到这些选择的情况下，会做出不同的、通常是不兼容的选择。

协作延迟加剧了这个问题。研究显示，协作开销会从两个智能体时的约 200 毫秒增长到八个或更多智能体时的 4 秒以上。等到编排器收集完结果并分发上下文时，智能体通常已经致力于冲突的路径了。

标准的解决方案是在智能体之间传递摘要。但摘要会丢失隐性决策。一个被告知“设计智能体选择了事件驱动方法”的智能体不会知道决定了哪些事件模式，考虑并拒绝了哪些故障模式，或者做出了哪些权衡。完整的追踪共享（trace-sharing）——让每个智能体都能看到其协作方的完整决策历史——是唯一真正有效的方法，但这很快就会触及上下文窗口（context window）的限制。

调试非确定性分布式系统的隐藏成本

有一类问题是分布式系统工程师最讨厌的，因为它们会耗尽职业生涯：具有多个交互组件的系统中的非确定性故障。多智能体架构就是这种问题，而且还增加了一个转折：组件是随机性的（stochastic）。

当单智能体流水线失败时，你可以追踪一系列输入和输出。而当多智能体系统失败时，你面对的是一个编排图，故障可能起源于智能体 B，体现在智能体 D，并且直到最终输出才变得可观察。复现故障需要以相同的输入运行所有智能体，并希望它们做出相同的决定——但这不会发生，因为 LLM 是非确定性的。

这使得多智能体系统的维护难度远超其复杂性所暗示的程度。规范失效（Specification failures）约占生产中多智能体故障的 42%，协作崩溃（coordination breakdowns）占另外 37%。这两类故障都极难诊断，因为故障信号通常是细微的错误输出，而不是报错。

单就调试体验而言，就是支持简约性的强力论据。一个你可以线性追踪的系统是一个你可以迭代改进的系统。一个拥有六个相互作用的智能体、每个智能体都有自己的上下文和决策历史的系统，是一个抵制改进的系统。

何时并行确实有帮助（以及何时没有）

这里的论点并不是说并行总是错误的——而是错误形式的并行会使系统变得脆弱。并行执行（Parallel execution）与协作执行（Collaborative execution）之间存在着本质的区别。

无需协调的并行执行是行得通的。如果你有五个独立的研究查询并希望同时运行它们，那么启动五个具有独立上下文的智能体（Agent）并合并它们的输出是一个合理的模式。每个智能体都完成一个自包含的任务。不存在会产生冲突的隐含决策，也不存在会产生分歧的共享状态。这是典型的“易并行（embarrassingly parallel）”工作，可以干净利落地实现并行。

协作执行——即智能体必须意识到并兼容彼此正在进行的工作——则是问题所在。Flappy Bird 的案例是一个有用的思维模型：让一个智能体构建背景，另一个智能体构建游戏的玩家精灵（sprite），你很可能会得到一个马里奥风格的背景配上一个审美和坐标系统都不兼容的小鸟精灵。随后的集成任务将比按顺序构建整个游戏还要困难。

在将任务拆分给多个智能体之前，正确的问题不是“这些子任务可以并行化吗？”，而是“这些子任务是否真正独立？”独立意味着：了解子任务 A 的结果不会改变你处理子任务 B 的方式。大多数复杂任务都无法通过这一测试。

有效的方案：具备智能上下文管理的线性智能体

2026 年诚实的工程答案是，在大多数实际任务中，具有良好上下文管理的单线程线性智能体表现优于多智能体架构。它们更容易追踪、更容易调试，并且不会在协调边界上复合错误。

反对意见通常是上下文窗口（Context window）的长度。复杂任务所需的上下文超出了单个智能体所能承载的范围。这是一个现实的约束，但解决方案是压缩，而非并行。一个能够定期总结自身历史的模型——在压缩原始追踪记录的同时保留明确的决策——可以在比其上下文窗口建议的长得多的任务中维持有效的上下文。这是可行的工程实践。而管理并行智能体之间的隐含决策冲突则并非如此。

单智能体架构真正力不从心的地方在于那些确实可以分解为独立并行流的任务：运行测试套件、处理独立文档、查询多个数据源。对于这些任务，使用非协作智能体进行并行执行是正确的答案。将每个并行流视为一个完整的、隔离的任务。在最后合并结果，而不要求智能体彼此感知。

过度架构的组织压力

构建多智能体系统往往不是因为它们能更好地解决问题，而是因为它们看起来更高级。存在一种组织压力，要求构建带有编排器（Orchestrator）、专家智能体和路由层的“真正”智能体系统。架构图看起来令人印象深刻。带有智能体间交接和并行工作流的演示看起来非常强大。

这正是产生脆弱生产系统的动力所在。复杂性是昂贵的。每一个协调边界都是一个失效模式。每一个智能体间的接口都是一个可能断裂的隐含契约。那些从最简单的可行方案开始——由单个智能体线性地完成整个任务——并且仅在遇到具体极限时才引入复杂性的团队，才能构建出真正有用的系统。

一个实用的观察信号是：你增加智能体是为了处理真正的规模或并行需求，还是为了分解一个你不想让单个智能体处理的任务？后者通常是过早的。上下文压缩和更长的提示词（Prompts）能处理的情况比你预期的要多。请将协调开销留到你真正耗尽了更简单的选项之后。

多智能体系统的未来

现状并不意味着多智能体协作永远是行不通的。它意味着用于共享上下文、管理隐含决策、协调智能体间状态的工具尚未赶上人们的雄心。框架正在改进。上下文窗口正在扩大。智能体之间的结构化通信协议是一个活跃的开发领域。

但对于“工具尚未就绪”的正确反应是，在工具赶上之前使用更简单的架构进行构建——而不是用验证智能体和重试逻辑来掩盖协调问题并寄予希望。

现在内化这一点的工程师将能够构建出在生产环境中真正起作用的系统。目标是可靠的软件，而不是令人印象深刻的架构图。当多智能体协调成熟到在协作任务上确实比单智能体方法更可靠时，选择它的理由将显而易见。在此之前，默认选择应该是：单个智能体、线性执行、智能上下文压缩——并且仅在任务真正并行且真正独立时才采用多智能体。