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

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词，换一个更强的模型，添加更多上下文。

真正的原因往往更平凡，也更危险：并发写入导致的共享状态损坏。两个智能体读取同一块内存，都计算出更新，其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出，没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的，在测试环境中难以复现，仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现，36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。

一个基于流行开源技术栈构建的多 Agent 研究工具陷入了递归循环，运行了 11 天才被发现。账单：47,000 美元。两个 Agent 一直在不停地互相对话，消耗着 token，而团队却以为系统在正常工作。这就是 Agent 流水线没有背压时会发生的事情。

问题是结构性的。当编排 Agent 将任务分解为子任务并生成子 Agent 来处理每一个任务，而这些子 Agent 又可以自行生成更多子 Agent 或在多个工具调用之间扇出时，你就会得到指数级的工作生成。流水线产生工作的速度超过了它能执行、完成甚至核算的速度。这与响应式系统、流式架构和网络协议几十年前解决的问题完全相同——同样的解决方案同样适用。

你有三个 Agent 在分析一个客户支持工单。两个说"立即退款"，一个说"升级到欺诈审查"。你选择了多数答案并执行了退款。三天后，欺诈团队问你为什么自动退款了一个已知的拒付模式。

这就是多 Agent 系统中的共识问题，事实证明分布式系统工程师几十年前就解决了其中的重要部分。但天真地移植这些解决方案——或者更糟糕的是，默认使用多数投票——会在你的"节点"是有自己观点的语言模型时产生独特的危险故障模式。

三个智能体并发处理同一个客户账户更新。三者都记录了成功。最终数据库状态同时出现了三处错误，且始终没有抛出任何异常。团队花了两周时间怪罪模型。

问题不在模型。是竞态条件。

这是生产环境多智能体系统中被误诊次数最多的故障模式：由并发状态访问引发的数据损坏，因为下游智能体会基于损坏的输入自信地进行推理，从而被误认为是幻觉。模型并没有在编造内容，它只是在忠实地处理垃圾数据。

多智能体系统（Multi-agent systems）是基于一个承诺而诞生的：多个并行的专业化智能体协同工作，产生的结果会优于任何单个智能体。但这个承诺隐藏了一个前提——当智能体给出不同答案时，你知道如何调解它们。大多数团队在发现自己无法调解时，往往为时已晚。

天真的做法是取输出的平均值，或者选择多数票答案，然后继续。在实践中，如果所有智能体共享相同的训练分布，多智能体系统会通过多数表决放大它们的共同错误，而不是抵消错误。一个总是听从最有信心智能体的系统，会盲目跟随那个最过度自信的智能体。而一个将所有分歧都交给 LLM 裁判（LLM judge）处理的系统，会继承该裁判的 12 种已被记录的偏差类型。仲裁问题比看起来要难，如果处理不当，你可能会在一周内遇到四次生产事故。

提示注入吸引了所有关注。但提示注入在会话关闭时就结束了。内存投毒（Memory poisoning）——将恶意指令注入 Agent 的长期内存——会创建一个持久性的漏洞，跨会话存续并在几天或几周后执行，由完全不像攻击的交互触发。对生产级 Agent 系统的研究显示，在受测的基于 LLM 的 Agent 中，注入成功率超过 95%，攻击成功率超过 70%。这是大多数团队尚未防御的攻击向量，且它已经进入了 OWASP Agent 应用前十名（OWASP Top 10 for Agentic Applications）。

核心问题很简单：Agent 将自己的内存视为可信的。当 Agent 从向量库或对话历史中检索“内存”时，它处理这些信息的信心与处理系统指令时相同。没有加密签名，没有来源链，Agent 也没有机制来区分它是从真实交互中形成的内存，还是由上周二处理的某个恶意文档注入的。

你的规划智能体（planner agent）在评估套件中的通过率为 94%。你的研究智能体（researcher agent）得分甚至更高。你的合成智能体（synthesizer agent）完美通过了你投喂的每一个基准测试。你将它们组合成一个流水线，部署到生产环境，然后眼睁睁地看着它产生自信的错误答案——而任何单个智能体都不可能独立生成这些错误。

这就是组合测试鸿沟（composition testing gap）——这是一个系统的盲点，即经过独立验证的智能体会以单智能体分析无法预测的方式失败。对多智能体 LLM 系统（multi-agent LLM systems）的研究表明，67% 的生产故障源于智能体之间的交互，而非单个智能体的缺陷。你测试的是原子，但交付的是分子，而分子的行为并非原子属性的简单叠加。

大多数多智能体系统最初都是以链式结构开始的。智能体 A 调用智能体 B，B 调用 C，C 调用 D。这种模式在演示中运行良好，在处理简单任务的五个智能体中也运行良好。但当你增加到第六个、第七个智能体时，原本 8 秒就能运行完的流水线开始需要 40 秒。你在第三步增加了一个重试机制，结果第三步的失败会无声地级联，导致第六步出现状态损坏。你尝试添加一个并行分支，却发现你的框架从设计之初就无法支持。

问题不在于智能体的数量。问题在于执行模型。线性链式结构固有的缺陷在于它将本可以并行的工作串行化，且故障只能单向传播，这使得局部恢复在结构上变得不可能。解决方法并不是在现有系统之上增加更多的基础设施，而是从一开始就围绕有向无环图（DAG）重建执行模型。

最近的一项研究测试了 17 个处于多智能体配置中的前沿 LLM，发现当恶意指令来自同行智能体时，82% 的模型会执行这些指令 —— 尽管当用户直接发出完全相同的指令时，它们会拒绝执行。如果你正在交付多智能体系统，这个数字应该让你重新审视你的威胁模型。你的智能体可能在个体层面已经过加固，但作为一个整体，它们并非如此。

多智能体架构引入了大多数安全思维所忽视的通信渠道。我们加固了模型、系统提示词和 API 边界，但我们几乎不花时间去关注当智能体 A 发送消息给智能体 B 时会发生什么 —— 谁编写了该消息，它是否被篡改过，智能体 B 参考的记忆是否在三个会话前被一个从未接触过智能体 A 的攻击者所植入。

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）：授予的权限、声称的权限以及实际行使的权限之间存在不匹配。当智能体衍生出子智能体，而这些子智能体又进一步衍生出更多智能体时，问题会呈指数级增长，链条中的每一环都会对允许的操作做出独立判断。