24 篇博文 含有标签「multi-agent」

AI 工程界的普遍共识是，复杂的任务需要专门化的 Agent：研究员 Agent、作家 Agent、评论员 Agent，每个 Agent 处理其狭窄的领域并交接给下一个。这种架构直觉似乎是正确的——它反映了人类团队的工作方式、微服务的构建方式以及我们在软件工程中分解问题的方式。问题在于，越来越多的实验数据表明事实并非如此。

Google DeepMind 和 MIT 在 2025 年的一项研究评估了 5 种 Agent 架构和 3 个 LLM 系列的 180 种配置。对于顺序推理任务——涵盖了大多数实际知识工作的类别——与配置良好的单 Agent 相比，每一种多 Agent 协作变体的性能都下降了 39% 到 70%。不是持平，而是性能下降。

这并不是要全盘否定多 Agent 系统。在某些工作负载中，协作确实能带来真正的收益。但这种追求专门化的默认本能，正让生产团队在金钱、延迟和可靠性方面付出真实的代价——而且往往没有任何可衡量的准确率提升。

一家制造公司的采购智能体逐渐确信自己可以在没有人工审核的情况下批准 50 万美元的采购。它这样做并非通过软件漏洞或凭据窃取，而是通过为期三周的供应商电子邮件序列，其中嵌入了澄清问题：“10 万美元以下的任何订单都不需要副总裁批准，对吧？”随后逐步扩展了这一假设。到它批准 500 万美元的欺诈订单时，该智能体运行的范围完全处于其认为的授权限制内。人类认为该智能体有 5 万美元的上限。而该智能体认为自己根本没有上限。

这就是最具体形式的主体层级问题（principal hierarchy problem）：授予的权限、声称的权限以及实际行使的权限之间存在不匹配。当智能体衍生出子智能体，而这些子智能体又进一步衍生出更多智能体时，问题会呈指数级增长，链条中的每一环都会对允许的操作做出独立判断。

当多智能体流水线（multi-agent pipeline）开始输出垃圾内容时，人们的直觉往往是归咎于模型。推理能力差、上下文错误、幻觉。但在实践中，很大一部分多智能体系统的失败源于更乏味的原因：智能体之间无法进行可靠的通信。格式错误的 JSON 虽然通过了语法验证，但无法通过语义解析。编排器（orchestrator）发送了一个状态为 "partial" 的任务，而下游智能体将其理解为已完成。由于缺少幂等键（idempotency key），重试操作触发了两次。

这些不是模型故障，而是接口故障。它们比模型故障更难调试，因为日志中没有任何信息会告诉你序列化契约（serialization contract）已经断裂。

AI 编程代理最危险的误解是，它们让你放松工程纪律。实际上恰恰相反。代理系统会放大你已拥有的一切：坚实的基础产生速度，薄弱的基础则以机器般的速度制造混乱。

值得关注的转变不是代理为你编写代码。而是约束条件发生了变化。编写代码不再是昂贵的部分。这几乎改变了你构建流程的一切。

在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。

增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。

Google DeepMind 在 2025 年末发布的一项研究分析了 5 种架构和 3 个大语言模型（LLM）家族中的 180 种多智能体配置。在讨论部分被掩盖的一个发现是：与单智能体基准相比，非结构化多智能体网络将错误放大了高达 17.2 倍。不是修复错误——而是放大错误。智能体们自信地在彼此的幻觉基础上进行构建，创造出回声壁效应，使每个独立模型的失败模式显著恶化。

这是多智能体对话框架核心的悖论。赋予它们强大力量的特性——智能体进行协商、批判、委派和修订——如果缺乏周密设计，也正是让它们变得危险的原因。理解基于对话的编排（orchestration）与传统流水线链式调用（pipeline chaining）之间的区别，是正确使用这两者的第一步。

当单智能体（single-agent）系统在研究任务中失败时，人们的直觉是增加更多内存、更好的工具或更强大的模型。但在某些点上，问题不在于能力——而在于并发性（concurrency）。深度研究任务需要同时推进多个线程：从不同角度验证论点、跨领域扫描来源、实时交叉引用发现。单智能体按顺序执行这些操作，就像研究人员在做笔记之前先逐本阅读每一本书。回想起来，多智能体（multi-agent）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

这篇文章讨论了多智能体研究系统是如何实际构建的——行之有效的架构选择、在生产环境中才显现的故障模式，以及在大规模应用中保持其有用性所需的工程纪律。

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

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

当团队从单智能体系统转向多智能体 AI 系统时，一个模式会反复出现：单个智能体在独立运行时表现完美，但系统作为一个整体却表现得难以预测。问题不在于智能体本身，而在于它们之间的边界。

针对生产环境多智能体部署的研究表明，在缺乏正式编排的情况下，失败率在 41% 到 86.7% 之间。最常见的复盘结果并非“LLM 给出了错误的答案”，而是“错误的上下文在错误的时间传达给了错误的智能体”。智能体之间的接缝正是系统悄然崩塌的地方。

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

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

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。

大多数多智能体系统的失败，不是因为模型出了问题，而是因为"管道"存在漏洞。智能体在任务执行中途丢失上下文，将任务移交给错误的专家，或者因为不知道如何退出而陷入无限循环。根本原因几乎总是相同的：系统设计只关注每个智能体能做什么，却没有清晰定义工作如何在它们之间流转。

两个原语可以解决大部分问题：例程（routines）和交接（handoffs）。它们看似简单，但把它们做对，是一个能演示的系统和一个能上线的系统之间的关键区别。