规划代理（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）、成本经济学、来源可靠性和多代理协作。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
