生产级 Multi-Agent 系统的 4 层架构

Agent 层

Agent 组织工作。每个 agent 都有一个框架（指令和工具）、一个运行时（它在哪里运行）、一个所有者（谁维护它），以及清晰的角色和边界定义。

Model 层

模型提供智能。并不是每个 agent 都需要最昂贵的模型。协调 agent 可能需要使用最先进的模型来规划复杂任务，而负责格式化输出的 agent 则不需要。模型路由和回退链可以将成本降低一个数量级。

Tool 层

工具扩展了 agent 的能力。内置工具为 agent 提供基本功能。MCP 服务器上的外部工具使它们能访问数据库、API 和服务。工具治理确保 agent 只能调用它们被授权调用的内容。

State 层

状态是记忆。每个 agent 拥有自己的状态分区。没有 agent 写入其他 agent 的分区。共享无关的所有权意味着故障保持隔离。

我构建的每个多代理系统都始于单体架构：一个 agent，一个运行时，一套工具。这对演示很有效。然后你添加第二个 agent，再添加第三个，忽然间每次故障都会导致整个系统崩溃。

本能反应是修复 agent。更好的 prompt、更强的计算、更聪明的模型。但真正的问题不在于 agent。而在于它们底下的架构。

在构建了能够真正承受现实工作负载冲击的生产级多代理系统后，我得出了一个四层模型，它能保持各个部分的独立性并将故障局限化。

各层通过协议（如用于 agent 间通信的 A2A（Agent2Agent）和用于工具发现的 MCP）连接。在 Azure 上，Foundry 将运行时、框架、工具和编排组合成单一托管服务，但架构本身是平台无关的。

关键洞察：并非每个系统都需要所有四层。有些解决方案使用两层。有些使用三层。模式是将组件组合成在现实中有效的东西。

想了解完整架构？阅读 zulmehdi.blog 上的完整文章（https://zulmehdi.blog/4-layer-multi-agent-enterprise-architecture-azure/）。

如有进一步操作，你可以考虑屏蔽此人和/或报告滥用。