规划代理（Planner agent）接收一个任务，将其分解，并生成一个研究员子代理（researcher subagent）来处理其中一个分支。编排框架会将父代理的完整上下文传播给子代理，因为这是最容易交付的默认设置。现在，研究员拥有了规划者的完整系统提示词（system prompt）——策略文本、内部工具名称、父代理被授权使用的凭证，以及暗示你计费流水线结构的 few-shot 示例。研究员的工作原本只是阅读三份文档。但这次调用的爆炸半径却是父代理的全部权限。
这并非假设。这是目前大多数投入生产的多代理框架的默认行为。最近的一项审计发现，93% 的代理项目使用未限制范围（unscoped）的 API 密钥；当一个代理调用另一个代理时，子代理要么继承父代理的全部凭证，要么接收自己独立的密钥——没有一个项目实现了针对委派访问的范围缩小、深度限制或级联撤销。框架将“共享父状态”视为一种便利，而将“缩小子代理范围”视为可选步骤。而这个可选步骤，恰恰是没人会去写的。
你的规划智能体（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）重建执行模型。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
