AI 智能体架构企业级落地的工程化能力设计 原创

AI 智能体在企业业务场景落地过程中的好坏与架构设计的工程化能力密切相关，特别是：总体架构分层设计、AI 智能体协作模式设计、MCP 工具调用标准化设计、AI 智能体编排框架设计等4个维度，本文结合我们实际落地的工程实践视角，来展开剖析。

下文我们详细剖析之。

一、AI 智能体总体架构分层设计

下图展示了 AI 大模型时代和微服务时代技术架构分层设计的简单对比，主要是为了明确领域层和基础设施层的架构设计范围。

在 AI 大模型时代，架构设计主要包括：AI 智能体的抽象定义、Tool 的抽象定义、业务 Prompt 的设计、业务数据的供给、经过微调的大模型以及完整的评测集。

明确这些架构设计分层技术目的是为了让业务产品的开发和接入更多地围绕这些关键部分展开。AI 智能体平台需要提供与之配套的服务能力，比如：AI 智能体注册与编排能力、Tool 接入能力、Prompt 调试能力、大模型微调能力和测评能力。

二、AI 智能体协作模式设计

1、互联网架构的演变

如下图所示，过去的互联网架构经历了从单体服务到微服务/云原生的架构演变。这种架构演变本质上是对业务系统高内聚低耦合的实践。比如：一次优惠活动的创建，可能涉及营销、库存、限购、商品等多个领域，每个领域都有不同程度的参与。随着单个领域的业务知识不断膨胀，以及行业需求的不断迭代，推动了我们对系统和服务进行拆分。

在微服务实践中，我们在统一的系统编排框架（比如：Spring Cloud Alibaba）下进行交互，领域之间的互联通过服务接口进行。因此，在 AI 时代，未来的系统交付物可能不再是某个服务，而是某个 AI 智能体。AI 智能体与传统接口的最大区别在于，它可能涉及多轮交互，而不仅仅是简单的输入输出。因此，协议设计需要考虑多轮交互来完成任务。同时，像服务注册与发现这类能力，仍然具有很高的参考价值。

2、AI 智能体架构的演进路径

在 AI 智能体系统的发展中，也会有类似的架构演进路径。最初，一个 AI 智能体可能会逐渐变得功能强大，但随着领域知识的积累和复杂度的增加，会催生出更多的 AI 智能体来共同完成某个任务。这种从单体 AI 智能体到多 AI 智能体协作的演进是必然的。

3、多 AI 智能体协作模式

既然从单体 AI 智能体到多 AI 智能体协作是必然的演进规律，那么就有必要关注多 AI 智能体协作模式。以下是多 AI 智能体协作的核心内容：

• 任务分配机制

     a.集中式任务分配

     b.分布式任务协商

     c.基于角色的任务划分

     d.动态任务重分配

• 协作方式

     a.平行协作：多 AI 智能体并行解决问题

     b.层级协作：管理 AI 智能体统筹下级 AI 智能体

     c.专家协作：不同领域 AI 智能体联合解决问题

• 冲突解决

     a.基于优先级的决策

     b.投票机制

     c.仲裁 AI 智能体介入

     d.基于规则的冲突处理

当前市面上关于多 AI 智能体协作的讨论，主要围绕任务的解决展开，包括任务分发、任务处理和任务结果回收。这也是 A2A 协议引入“任务”这个概念的原因。

4、多 AI 智能体协作架构设计

下图是对多 AI 智能体协作架构设计的一个简化理解。从业务主 AI 智能体出发，需要基于任务中心恢复当前任务上下文，继续本次任务的处理。接着通过 AI 智能体仓库找到需要协同的 AI 智能体。我们通过多 AI 智能体交互协议与其他协作 AI 智能体交互，并在主 AI 智能体的业务流程中完成结果决策或子 AI 智能体的状态透传。

这套多 AI 智能体架构设计也呼应了前面提到的，AI 智能体可以是任意一个能够完成一定范围内人类任务的系统，只要它能在我们的业务流程中参与协同并解决一类问题。它可以是“一行 Hello World 代码”，也可以是一个复杂的交互系统。同样，基于“万物皆 AI 智能体”的思路，MCP 工具服务也可以抽象成一个 AI 智能体，并且可以在这一层做一些额外的事情，比如：鉴权、参数校验等。

三、MCP 工具调用标准化设计

AI 智能体在企业落地中，Tool 的抽象也比较关键，尤其通过 Tool 来扩展和增强大模型的能力边界。现在，虽然 MCP 已经成为行业标准，但是当前 MCP 协议整体还比较薄，需要进一步工程化的架构设计能力来增强，特别是：公网/内网级的权限控制、用户态的权限控制、工具快速接入能力、长工具列表优化等工程化，如下图所示：

1. 公网/内网级的权限控制

单体服务向微服务转变后，会抽象出许多只在公司内部供给能力的领域。因此，工具和 AI 智能体需要在公网和内网的维度进行隔离。当前的 MCP 服务是基于公网的协议，这意味着内网的 MCP 服务需要有统一的网关层来收口，并根据请求类型提供相应的工具集。

2. 用户态的权限控制

当前的 MCP 协议没有用户态信息，这会导致一些只对特定用户开放的工具无法进行用户级的鉴权。因此，需要在用户态信息层面补充 MCP。对于公司来说，用户态信息可以是多类型的，比如：电商用户、外卖用户、公司员工等。有了这层信息后，业务工具可以在自己的服务内部进行鉴权行为。与传统应用不同，面向大模型的服务最好在工具供给这一层就做好权限控制，用户没有权限的工具直接对大模型不可见，以避免请求后无法获取数据的错误。

3. 工具快速接入能力

从零开发一个 MCP Server 对业务团队来说是有一定工作量的。开发框架（比如：Spring AI Alibaba）支持零代码一键转 MCP Server，这就是一种工具快速接入的能力。除了开发框架外，还有很多业务团队常用的接入诉求，比如：SLS 日志查询的接入、表读取的接入、服务的接入等。这些能力可以快速支撑起一个简单的应用场景。对于公司的 MCP 中心，如果能够支持这种工具接入的收敛，可以提高业务应用建设的效率。

4. 长工具列表优化

随着业务系统的复杂性提升，一个 AI 智能体系统依赖的工具可能会显著增加。对于业务侧来说，需要让工具更加内聚和简单。对于 MCP 中心来说，可以通过一些更通用的工程化手段来处理，比如：在服务发现的末端，基于用户的请求前置过滤一些与本次无关的工具，可以通过向量相似性或 LLM 来处理。这种二阶段工具匹配的做法不仅可以减少长任务下的上下文长度，还能提高工具匹配的准确性。

四、AI 智能体编排框架设计

下图很好地总结了 AI 智能体编排框架的分层设计。除了前面提到 AI 智能体协作构建模式和既定的工具调用标准（MCP），AI 智能体在企业落地过程中还需要引入问题理解、关键记忆召回、知识库增强、评测等能力。

基于这些能力，AI 智能体平台衍生出了以下关键模块：知识库的管理与干预、模型市场中心、记忆管理、链路追踪、评测管理与微调能力。这些关键模块每一个都可以深入剖析，改天再来详细剖析。

本文转载自​​​玄姐聊AGI​​  作者：玄姐