多智能体编排与监管器控制

一个单独的 AI 智能体在 85% 的情况下能给出正确答案,听起来不错——直到你把五个串联起来,端到端的成功率骤降至 44%,或者串联十个,只剩 20%。这种失败率的累积效应,正是多智能体项目在通过演示阶段之后走向失败的原因,而根源几乎从来不是模型太差,而是缺乏治理的编排。我们的做法是构建这样的多智能体系统:编排层本身就是产品,由一个确定性的监管器来治理,而不是交给另一个可能被迷惑或越狱的大语言模型。

无人警示的多智能体可靠性难题

上文所述的累积效应,是一种只有在系统离开演示环境后才会浮现的失败模式。一项分析了七个开源智能体框架、共 1,642 条执行轨迹的研究发现,失败率介于 41% 到 86.7% 之间,其中协调失灵占全部失败的 36.9%。Gartner 预测,超过 40% 的智能体 AI 项目将在 2027 年前被取消,而首要原因不是模型太差——而是缺乏治理的编排。

在我们设计的系统中,监管器是一个确定性的策略引擎,而不是另一个可能被迷惑或越狱的大语言模型。每个智能体都在一个经过形式化规定的封套内运行:定义好的输入/输出模式、允许访问的工具、令牌预算、API 调用配额以及执行时间上限。监管器在每个智能体动作生效之前,都会对照这些约束进行校验。这不是在“加装护栏”——而是在协调层从架构上让不安全的行为根本无法发生,正是我们在 关于超越 LLM 封装、构建真相架构的研究中详述的方法。

为什么仅靠框架无法达到目标

2026 年的多智能体框架格局是一片充满破碎承诺的雷区,而这些差异并非表面文章——它们决定了系统是能正常运行,还是会悄然失败或超支。

即便是最具生产可行性的 LangGraph,也带着尖锐的棱角:其默认的 ToolNode 无法处理需要读取或写入图状态的工具,它需要手动的循环计数器来防止失控的自我纠错循环,而其检查点(checkpointer)实现在大规模并发分支解析时也力不从心。这些都是可解决的问题,但它们所需的工程能力,远非一份框架的 README 所能涵盖。

我们会针对你的实际需求评估各种框架——延迟预算、智能体数量、工具复杂度、合规要求——然后构建位于框架之上的编排层,提供任何框架都无法开箱即用的监管控制、成本治理与可观测性——正是我们在 关于构建有韧性企业级 AI 的白皮书中所描述的那种有韧性的编排层。

监管器实际上做了什么

我们所采用的模式是:确定性编排,大语言模型的推理置于边缘。大语言模型负责判断——理解意图、提取结构化参数、决定调用哪个专家智能体。状态机负责流程:路由、排序、并行扇出、共识聚合以及错误恢复。Pydantic 校验将每一次智能体间的交接都捕获为带类型、受模式约束的载荷,因此智能体之间不会传递任何自由格式的文本——这就消除了困扰基于聊天的智能体架构的提示注入向量与语义漂移。

监管器旨在强制执行四类控制:

• 单智能体资源预算 ——令牌上限、API 调用配额、挂钟超时。
• 单智能体工具访问限制 ——文件系统目录、网络端点、数据库作用域。
• 动作审批关卡 用于影响外部系统的写操作。
• 成本熔断器 在支出超过阈值时中止执行。

受治理系统的推荐 SLO:成功率高于 95%,交接延迟低于 30 秒,工具调用保真度高于 80%。

有据可查的灾难,变得可以预防

这些控制旨在把广为人知的灾难变成几分钟内即可捕获的事件——正是同一套确定性安全方法在 我们确定性安全控制的实景演示中所展现的:

• 那笔 47,000 美元的 API 账单 ,源于一个持续 11 天的递归智能体循环——通过令牌支出上限加上语义循环检测(连续输出之间 95% 相似度阈值),在几分钟内而非几天内被捕获。
• 那起 每月 60,000 美元的自动扩缩容事故 ,智能体触发了从 12 个节点暴增到 500 个节点——被基础设施动作关卡阻止,该关卡要求扩容命令执行前须经监管器批准。
• 亚马逊 630 万笔订单损失 ,源于一个智能体遵循了过时的 wiki 指引——通过监管器执行前检查中的来源新鲜度校验与知识截止期强制约束得以预防。

跨智能体边界追踪失败的可观测性

多智能体系统中最棘手的调试难题在于:失败是图状的——智能体 A 工具调用中的幻觉会成为智能体 B 的输入上下文,进而成为智能体 C 那自信却错误的输出。传统监控只看到智能体 C 失败,却完全不知道根本原因在两跳之上游。我们设计的可观测性会把智能体交互可视化为有向无环图,并在每个节点保留完整的溯源信息。每一条智能体间消息、工具调用、状态转换与监管器决策都带着因果关联被记录下来,因此当某处出问题时,你能从症状逆向追溯到肇始的智能体动作,只需几秒而非几小时。

我们会根据你的技术栈接入 Langfuse、LangSmith 或 Arize,并叠加自定义埋点,以捕获这些平台原生无法采集的指标:

• 跨智能体令牌归因 ——哪个智能体在消耗你的预算。
• 协调开销比率 ——你的支出中,有多少是智能体之间相互交流,而非在做实际工作。
• 监管器干预频率 ——确定性层覆盖智能体行为的频率有多高。

协议栈:MCP、A2A,以及夹在两者之间的东西

Anthropic 的 Model Context Protocol(截至 2026 年 3 月已达 9,700 万次安装,现归属 Linux 基金会)标准化了智能体连接外部工具的方式。Google 的 Agent2Agent 协议负责处理跨厂商的智能体协作,已有 50 多家行业合作伙伴。AWS Bedrock 提供带分层监管路由的托管式多智能体主机服务。这些都是真实的能力,而非空头承诺。

但它们都没有提供治理层。MCP 定义的是工具访问,而非按智能体划分的工具授权。A2A 定义的是跨厂商消息传递,而非成本预算或动作审批。Bedrock 的监管器会路由任务,却不会对智能体行为强制施加确定性约束。“智能体能与工具及彼此对话”与“智能体在受治理、可审计、成本受控的编排下运行”之间的鸿沟,正是我们的定制工程所在——正是我们在 关于从封装跨越到深度 AI 系统、跨越 GenAI 鸿沟的研究中所阐述的深度系统工作。

何时多智能体是错误的架构

如果单个智能体就能处理你的工作负载,我们会告诉你不要构建多智能体系统。微软自己的指引很直接:“默认使用单个智能体。只有在你有证据表明额外的复杂度能带来相称的价值时,才引入多智能体架构。”单个智能体因没有智能体间开销,响应速度快 30%–50%,而多智能体系统的投资回报盈亏平衡点,要比单智能体方案晚 8–14 个月才能到达。

在以下情形下,一个构建精良的单智能体是更好的投资:

• 你的任务在单个逻辑流程中即可完成。
• 你的业务量在每天 10,000 次操作以下,且增长可预测。
• 你需要具备清晰错误隔离的简单审计轨迹。

当你确实拥有需要不同工具访问、不同模型选择或不同延迟预算的截然不同的能力时;当你需要在相互独立的子任务之间并行执行时;或者当技能范围狭窄、经过充分测试的专家智能体表现优于一个提示臃肿的单智能体时,多智能体才配得上它的复杂度。决策框架比技术选型更重要,而我们会在编写任何编排代码之前先应用它。

我们交付什么

一次合作的范围界定为产出:

• 一份 框架评估 ,针对你的具体需求——而非一张通用的对比表。
• 一套 监管器架构 ,附带你的合规团队可审阅的确定性策略规范。
• 单智能体沙箱化 ,配备工具访问控制与资源预算。
• 成本治理 ,配备令牌支出上限与熔断器。
• 可观测性埋点 ,配备跨智能体因果追踪。
• 一个 仿真环境 ,用于通过故障注入测试多智能体工作流。
• 运维手册 ,针对生产环境中有据可查的失败场景:智能体超时级联、输出冲突、资源耗尽、监管器策略违规,以及框架并未记录的协调死锁。

自建一个多智能体系统需要 6–18 个月,以及大约 50 万美元的高级工程师薪资,才能拥有一个生产级的编排层。我们的做法将其压缩到几周的架构设计与构建,借助上文所列的框架失败模式,而不是让你付出代价去重新发现它们。