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

当单个 LLM 给出错误答案时，你的直觉可能是询问更多模型。并行运行三个模型并取多数票——这就是集成（Ensemble）。或者把它们放在一个房间里让它们相互辩论——这就是辩论（Debate）。两者听起来都很严谨，且背后都有同行评审的研究支持。但在条件不成熟时，它们会以完全相同的方式失效，而这正是从业者鲜少讨论的部分。

这种失效模式并不隐晦：当你的所有模型都从相同的数据中学习、带有相同的偏见，或者是由具有相同世界观的人训练时，增加模型数量并不会带来更多信号，只会带来更“自信”的噪声。最近的研究为这一现象给出了量化数据：顶尖前沿模型之间的两两错误相关性（pairwise error correlation）约为 r = 0.77。这意味着大约 60% 的错误方差是共享的。来自不同供应商的三个模型实际上只相当于 1.3 个独立模型，而不是 3.0 个。

当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。

根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。

想象一个处理用户支持工单的多智能体流水线。智能体 A 读取工单历史并认为用户是一个需要进阶回复的高级用户。智能体 B 在并行的调用中读取同样的工单历史，却认为用户是一个需要分步引导的初学者。两个智能体同时完成并将输出交给组合智能体——而现在，组合智能体必须调和这两个对同一个人的根本不兼容的心理模型。

这并非罕见的极端情况。分析生产环境多智能体故障的研究发现，36.9% 的失败是由智能体间的失调引起的：冲突的输出、移交过程中的上下文丢失，以及独立得出的不兼容结论。一致性鸿沟（consistency gap）——即并行 LLM 调用对共享实体产生相互矛盾的倾向——是智能体系统中被低估最多的失效模式之一。

用户报告说助手在上午 9:47 给了他们一个错误答案。你打开 Trace。这里有 340 个 Span。它们几乎都被命名为 agent.run、llm.invoke 或 tool.call。有些有父节点，有些是兄弟节点。其中三个进行了重试，一个重试后被取消了。没有一个能告诉你错误的输出是来自 Planner、Worker、Critic、Reflection 过程，还是在 Critic 标记后 Worker 的第二次重试。

在接下来的一个小时里，你根据截图中的 UUID 前缀搜索日志行，比对 Slack 通知的时间戳，并根据 Trace 查看器中的缩进模式在脑海中重建 Agent 拓扑。最终，你猜想第三次 Worker 调用使用的模型别名在昨晚被静默切换到了另一个快照。但你无法仅凭 Trace 证明这一点。

Agent 正常运行，Trace 完整无缺。杂乱无章的 Trace 团（Hairball）本身就是 Bug。

一个用于市场数据研究的多智能体系统在无人察觉的情况下，在四周内悄悄烧掉了 47,000 美元的推理成本。原本的每周账单仅为 127 美元。原因既不是流量激增，也不是模型升级——而是两个智能体在十一天里来回传递同一个对话，每个智能体都确信对方才是处理该请求的正确位置。没有任何报错。没有任何警报触发。一个机器人的“队列已转移”指标和另一个机器人的“任务已接收”指标都在同步增长，两边的仪表盘看起来都很健康。

这就是闭环升级漏洞 (closed-loop escalation bug)。它是两个热心的同事互相坚持“不，你来处理”的多智能体版本，只不过他们谁都不会感到厌烦并走开。你在设计时画的架构图中，每个专业智能体都拥有一块清晰的问题领域。而运行时实际执行的架构却包含了一个房间里没人能看到的路由循环。

这是多智能体系统设计在架构评审中很少被提及的一个令人不安的事实：当你让两个智能体处理同一任务时，它们在20%到40%的情况下不会就答案达成一致，具体比例取决于任务类型。大多数系统的应对方式是静默地选择其中一个答案。日志中只显示最终决策，中间的分歧消失无踪。一切看起来运转正常，直到下游出现故障——而你要花费三到五倍的时间来调试，因为你搞不清楚哪个智能体出错了，甚至根本不知道它们曾经存在过分歧。

智能体之间的分歧不是一个可以稍后处理的边缘情况。随着并行智能体拓扑逐渐成为标准架构模式，冲突解决从脚注升级为一级可靠性纪律。

A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。

这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。

研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。

架构图上写着“三个前沿模型集成、辩论与对齐、多数投票”。追踪记录显示，所有三个智能体在第一轮就达成了一致，并又花了两个回合礼貌地互相转述。评估结果显示比单次调用高出 0.4 分。账单显示成本是 4.2 倍。在这其中的某个环节，有人判定这个委员会运作良好。

多智能体辩论被宣传为一种获取分歧驱动推理的方法：三个大脑相互争论，以获得比其中任何一个单独达到的更好的答案。但这取决于智能体是否真的存在分歧。在重叠的网络语料库上训练、针对重叠的偏好数据集进行指令微调、并针对重叠的安全分类法进行对齐的前沿 LLM，其共享的先验知识远比架构图所承认的要多。在经过一轮“让我们达成一致”之后，你观察到的并不是三种观点向真理汇聚——而是来自同一个分布的三个样本向它们原本就相距不远的众数汇聚。

这种模式在最近的文献中有一个名字：当一个集成的投票分歧率趋于零且与问题难度无关时，你就遇到了辩论多样性崩塌（debate diversity collapse）。委员会仍在投票。但投票已不再携带任何信息。

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

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

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

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

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

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

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

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

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