为什么多智能体系统会在接缝处断裂：设计可靠的交接机制

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

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

上下文在移交中失效的两种方式

每一次智能体移交都在回答同一个问题：下一个智能体应该知道什么？对此有两种本能的回答，但两者都是错误的。

上下文堆砌（The context dump）。 传递一切信息。完整的对话历史、每个工具的结果、所有的中间推理。接收端的智能体拥有完整的信息，因此它肯定能理清重点。但在实践中，这会产生研究人员所说的“迷失在中间（Lost in the Middle）”效应：模型表现出 U 型准确率曲线，埋藏在长上下文中间的信息变得明显难以提取。将整个对话历史发送给智能体，相当于把过去一个月的所有邮件都丢给一名新员工，并要求他立即进入状态。

压缩摘要（The compressed summary）。 总结要点。保持简短。这听起来很明智，但摘要会剥离推理链和证据。下游智能体接收到的是一个结论，却没有支持该结论的逻辑。当该智能体需要扩展、验证或质疑早前的决策时，支持性材料根本不在那里。结果就是从业者所说的“幻觉逻辑”——智能体用听起来合理的虚构内容来填补其上下文中的空白。

这两种方法都将上下文视为一次性的文本传输。这是最根本的诊断误区。

三种相互叠加的失效模式

对生产环境多智能体系统的研究确定了三类主要的失效类型，它们会以极具破坏性的方式相互作用。

规范失效（Specification failures） 约占事故的 42%。当智能体在技术上完成了分配的任务，但误解了业务实际需求时，就会发生这种情况。编排器委托了一个带有模糊成功标准的财务计算。专家智能体根据其理解返回了一个技术上正确的数字。下游智能体将此输出视为经过验证的内容并加以整合，错误随之在工作流的其余部分传播并累积。当人类看到输出时，根因已经隔了三个步骤。

协作死锁（Coordination deadlocks） 约占失败的 37%。编排器在等待专家智能体的响应，而专家智能体在继续操作前正等待编排器的确认。系统不会抛出显式错误——只有延迟在增加。这在异步系统中尤为隐蔽，因为每个智能体的等待在局部看来都是合理的，但集体来看却是循环的。协作延迟呈非线性增长：两个智能体时尚可接受的开销，在智能体数量达到 8 个或更多时，会飙升超过 4 秒。

记忆污染（Memory poisoning） 占其余的 21%。一个幻觉事实被写入共享记忆。随后的智能体将其作为既定上下文提取。污染是逐渐发生的，导致根因分析变得困难。当错误浮出水面时，被破坏的“事实”已经过多个智能体的确认和引用。回滚不仅需要了解哪里出了错，还需要了解它是在什么时候变得具有决定性的。

这些失效模式之所以特别难以对付，是因为它们会叠加产生复利效应。规范失效向共享记忆输入模糊数据，导致第二个智能体产生引发死锁的确认请求。当实际根因是五个步骤前的规范问题时，故障链看起来却像是一个死锁。

结构化简报模式

解决方法是用结构化简报（Structured briefings）取代原始上下文传输。与其问“我应该传递什么上下文？”，不如问“下一个智能体执行任务需要什么，且仅需要什么？”。

一个结构化简报包含四类信息：

• 带有理由的决策（Decisions with rationale）：由先前智能体确立的不可协商的约束条件，以及产生这些约束的推理。这不仅仅是结论，而是下一个智能体需要应用或质疑的逻辑链。
• 通过引用获取的制品（Artifacts by reference）：指向原始文档和数据的指针，而非摘要。接收端智能体根据需要提取相关信息，而不是接收一段由他人判断生成的有损压缩信息。
• 开放性问题（Open questions）：明确标记未解决的问题，而不是让模糊性悄悄流向下游。
• 移交约束（Handoff constraints）：接收端智能体被授权和未被授权执行的操作。审核智能体不应重新起草；研究智能体不应做决策。

这将模型从“上下文即文本传输”转变为“上下文即支持查询的知识”。接收端智能体可以根据需要提取相关信息，而不是在噪声中搜索或依赖他人构建的摘要。

在实践中，这意味着为你系统中的每个移交边界定义一个 Schema——这是智能体之间关于将呈现什么信息以及以何种形式呈现的契约。这在前期可能很繁琐，但在你第一次需要调试多步故障时，它会带来巨大的回报。

状态架构：数据的存放位置

结构化简报告诉你 要传递什么。你仍然需要决定将它 存放在哪里。

生产系统中出现了三种模式：

中心化状态存储。 一个单一的事实来源 —— 通常是 Redis 或专门构建的智能体状态库 —— 所有智能体都从中读取并写入。这种模式易于理解，也便于审计。瓶颈在大规模场景下会出现：随着智能体数量的增加，写入竞争（write contention）也会随之加剧。在四到五个智能体的情况下运行良好；超过这个数量就会变得非常棘手。

带有选择性同步的私有状态。 每个智能体维护自己的上下文。只有当智能体产生了其他智能体需要的信息时，才会将更新发布到共享内存。这种方式具有可扩展性，但一致性维护确实非常痛苦 —— 你需要投入大量的工程时间来确保智能体看到的是共享状态的一致快照，特别是当两个智能体同时更新相关信息时。

事件溯源日志。 每一次状态变更都是只增日志（append-only log）中的一个不可变事件。智能体通过重放日志来重建当前状态。这为你提供了可审计性、重放能力，以及当智能体在工作流中途失败时的自然恢复机制。权衡之处在于性能：重放冗长的事件日志来响应读取请求的开销很大，因此你通常需要一个快照层（snapshot layer），将近期的事件折叠为当前的状态投影。

大多数生产系统最终会采用混合模式：使用事件日志进行审计和恢复，使用 Redis 缓存进行快速读取，并在智能体交换结构化简报时设置明确的同步点，而不是完全依赖共享存储来保持一致。

熔断器与可观测性

无论你多么仔细地设计移交契约（handoff contracts），失败总会发生。目标随之从预防转向隔离。

熔断器在达到连续失败的阈值（通常为三次）后，会隔离发生故障的智能体，并将任务重新路由到备选方案，而不是让错误产生级联反应。实现起来很简单；难点在于为每个智能体正确定义失败阈值和恢复条件。一个确实感到困惑并请求澄清的智能体，看起来与一个陷入死循环的智能体非常相似。你的熔断逻辑需要区分这两种情况。

多智能体系统的可观测性不仅仅是记录输入和输出。传统的日志记录了“智能体 B 在下午 2:34 被调用”，但遗漏了关键问题：为什么智能体 B 做出那样的决定？分布式追踪能够捕捉跨智能体交互的完整决策流 —— 相当于推理链的 OpenTelemetry spans —— 这才是真正实现生产调试的关键。当一个由三个智能体组成的工作流产生错误输出时，你需要重建的不只是数据流，还有决策流。

实际的最低标准包括：涵盖从初始请求到最终输出的整个工作流的 trace ID；明确记录每个智能体收到的内容与它请求的内容；以及对延迟激增的告警（这通常能在协调死锁演变为错误之前将其暴露出来）。

从小规模开始不是可选项

在构建多智能体系统时，诱惑往往在于预先设计完整的架构：五个专业智能体、一个监督者（supervisor）、共享内存等等。而在生产环境中持续取得成功的模式却截然不同。

从两个智能体和一个移交点开始。在添加第三个智能体之前，对该移交点进行完整的埋点监测。在三个或四个智能体同时运行之前，先弄清楚上下文是如何跨越单个边界流动的。多智能体系统的复杂性并不是随着智能体数量线性增长的 —— 它是随着移交边界的数量增长的，因为每个边界都是一个潜在的失败点和错误放大源。

那些在生产多智能体系统中报告最高可靠性的团队都有一个共同特征：他们在扩大规模之前构建了全面的可观测性。经过妥善编排的系统显示的故障率比未经编排的系统低 3.2 倍。这种差距主要源于能够尽早发现并隔离故障，而不是完全消灭故障。

多智能体协作与其说是一个 AI 问题，不如说是一个分布式系统问题。使分布式系统可靠的那些准则 —— 清晰的接口契约、显式的状态管理、熔断器、分布式追踪 —— 也正是使多智能体系统可靠的关键。模型的好坏取决于它们所嵌入的基础设施。