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

一个研究员智能体向一个检索智能体请求一份文档。检索智能体在任务执行到一半时，决定需要研究员智能体澄清查询意图后才能继续搜索。而正在等待文档的研究员智能体，在拿到文档之前不会做出响应。它们谁都没有出错，也没有陷入死循环。它们只是都在礼貌地、无限期地等待着对方——而你的编排器（orchestrator）根本没有“这两个智能体正在互相阻塞”的概念，它会一直愉快地维持这个状态，直到你从未配置过的超时设置最终触发，或者直到某个大活人注意到这个运行已经“进行中”整整 40 分钟了。

这就是死锁（Deadlock）。它是计算领域最古老的故障模式之一，且与你的模型有多聪明毫无关系。它是工作协调方式的一种属性，而不是工作执行方式的属性。过去一年多智能体研究中一个令人不安的发现是：在智能体集群中，大部分出问题的地方都在这里，即协调层，而不是任何单个智能体的推理能力。

单智能体思维永远无法暴露这些 Bug。当一个模型运行工具调用循环时，它最坏的情况也就是空转——而空转至少是肉眼可见的。一旦你拥有两个或更多可以互相等待的智能体，你就继承了分布式系统所有的病理特征：循环等待、活锁、丢包、过早终止、共享状态下的竞态条件。没有人会坐下来决定构建一个分布式系统，但在你添加第二个智能体的那一天，你就已经构建了一个分布式系统。

如果你的 Agent 团队通过一个共享的计划文件、仓库或设计文档进行协作，每个人都在上面读写，那么恭喜你：你重新发明了黑板架构 (blackboard architecture)。这种架构在 1975 年曾是顶尖技术。令人尴尬的不是“重新发明”本身——好的想法值得回归。尴尬之处在于，原始架构有三个承重组件，而大多数现代 Agent 技术栈只重建了其中之一。

Hearsay-II 是 1971 年至 1976 年间在卡内基梅隆大学构建、由 DARPA 资助的语音理解系统。它面临着一个听起来很熟悉的问题：许多专业但不可靠的专家——声学分析器、语法预测器、语义评分器——没有一个能独立解决问题，它们都需要建立在彼此的局部推测之上。由此产生的架构包含一个共享工作区（黑板）、独立的专家（知识源）以及一个调度程序，调度程序在每一步决定接下来应该执行哪个专家的贡献。五十年后，将 LLM Agent 连接在一起的团队正趋向于同样的形态——一个主 Agent、一组执行者、一个共享产出物——并陷入了黑板架构文献在大多数人出生前就已命名并解决的失败模式。

你可能目睹过这样一种失败，只是没有给它命名。你的编排者（orchestrator）读取用户请求并向工作代理（worker agent）下达简报。工作代理运行了十几次工具调用，消化输出，然后汇报一份简洁的摘要。编排者将该摘要并入下一名工作代理的任务简报中，后者如法炮制。五跳（hop）之后，系统给出了一个自信的最终答案——却违反了用户在请求的第二句话中明确提出的约束。没有人故意丢掉这个约束。每一跳只是稍微压缩了一下上下文，方向无人选择，而这些压缩不断叠加。

这就是“传声筒游戏”（the telephone game），而多智能体系统（multi-agent systems）本质上就在玩这个游戏。流水线中的每一次交接都是一个有损压缩步骤：编排者的简报是对用户的转述，工作代理的报告是对其工具输出的转述，而最终答案则是转述之上的转述。问题不在于信息是否丢失——它确实丢失了，而且是可衡量的——而在于你是否决定了哪些信息允许被丢失，还是将这个决定留给了采样温度（sampling temperature）。

打开你多智能体系统的架构图。然后再打开你的组织架构图。如果你眯起眼睛看，它们其实是同一张图。“研究智能体”对应着负责搜索的团队。“账单智能体”的硬边界恰恰就在财务部门停止与产品部门沟通的地方。那个将工作分发给五位专家的编排器，看起来极其像是一个带着五名直属下属的工程经理。你并非有意如此设计。是康威定律（Conway's Law）为你做了决定。

Melvin Conway 在 1967 年的观察是：任何系统设计都会反映出设计该系统的组织的沟通结构。六十年来，这始终是一个关于微服务和单体架构的故事。但智能体集群是我见过的对该定律最字面意义上的展示：智能体本身 就是 沟通结构。智能体边界是一个进程将消息传递给另一个进程并等待的地方。当你为了匹配团队而不是为了解决问题而划定这些边界时，你不仅继承了组织架构的形态，还继承了它的功能障碍，并以机器速度运行它。

规划代理（Planner agent）接收一个任务，将其分解，并生成一个研究员子代理（researcher subagent）来处理其中一个分支。编排框架会将父代理的完整上下文传播给子代理，因为这是最容易交付的默认设置。现在，研究员拥有了规划者的完整系统提示词（system prompt）——策略文本、内部工具名称、父代理被授权使用的凭证，以及暗示你计费流水线结构的 few-shot 示例。研究员的工作原本只是阅读三份文档。但这次调用的爆炸半径却是父代理的全部权限。

这并非假设。这是目前大多数投入生产的多代理框架的默认行为。最近的一项审计发现，93% 的代理项目使用未限制范围（unscoped）的 API 密钥；当一个代理调用另一个代理时，子代理要么继承父代理的全部凭证，要么接收自己独立的密钥——没有一个项目实现了针对委派访问的范围缩小、深度限制或级联撤销。框架将“共享父状态”视为一种便利，而将“缩小子代理范围”视为可选步骤。而这个可选步骤，恰恰是没人会去写的。

大多数构建多智能体系统的团队，把大量时间花在授权信任上：智能体 B 被允许执行哪些操作、可以调用哪些工具、能访问哪些数据。这是一个重要的问题。但还有第二个信任问题同样关键，却鲜少得到足够重视——而正是它在实际生产系统中造成严重故障。

这个问题是认知层面的：当智能体 A 将任务委托给智能体 B 并收到答案时，A 应该在多大程度上相信 B 返回的内容？

这不是 B 是否被授权回答的问题，而是 B 是否真的有能力回答的问题。

你的多智能体（multi-agent）流水线运行结束了。没有抛出任何异常。编排器报告成功。然而，答案却是错的，而且错得离谱 —— 执行器跳过了两个步骤，总结器将三个部分合并成了一个风马牛不相及的结论，输出看起来像是完全来自另一个任务。没有堆栈跟踪可以遵循，没有错误代码可以搜索。只有一个悄无声息的错误结果。

这就是输出耦合陷阱（output coupling trap）。这不是模型质量问题，而是接口工程（interface engineering）问题，也是多智能体系统在生产环境中发生隐形故障的首要原因。

关于多智能体 AI 系统，有一个令人不安的事实：当你让两个或更多由 LLM 驱动的代理共享资源并同时做出决策时，它们的死锁率在 25% 到 95% 之间。不是偶尔发生。不是在边缘负载下。在使用标准提示的正常运行条件下，一旦代理必须同时协调，系统就会卡住。

这不是理论上的担忧。协调故障约占生产环境中多智能体系统故障的 37%，而没有正式编排的系统故障率在 41% 到 87% 之间。经典的分布式系统故障模式——死锁、活锁、优先级反转——又回来了，只是穿上了新衣服。

每家在构建多 Agent 系统的公司最终都会发现同一个令人不安的事实：他们的 Agent 并没有反映技术架构图，而是反映了组织架构图。

处理客户入职的 Agent 与管理计费的 Agent 协调不好——不是因为技术限制，而是因为构建它们的团队之间本来就不怎么沟通。

康威定律——系统设计会映射构建它的组织的沟通结构——已经有五十年历史了，但从未像现在这样切中要害。在 AI Agent 时代，这条定律不仅适用，而且被放大了。当你的"系统"是一个由自主 Agent 组成的网络在做决策时，每一个组织接缝都会成为潜在的故障点：上下文丢失、交接中断、Agent 各自为局部指标优化而相互冲突。

传统的标准 LLM 在没有迭代检索的情况下，在多步网络研究基准测试中的得分低于 10%。深度研究代理（Deep research agents）——即在循环中进行搜索、阅读、综合和重新查询的系统 —— 得分则超过 50%。这种五倍的提升解释了为什么每个严肃的 AI 产品团队都在构建此类工具。但这无法解释为什么大多数实现要么在追逐无关的细枝末节时耗费 $15 的账单，要么在两次肤浅的搜索后就宣布胜利。

核心问题不在于构建循环，而在于知道循环何时应该停止。事实证明，这是一个出人意料的深度系统设计挑战，涉及收敛检测（convergence detection）、成本经济学、来源可靠性和多代理协作。