近期事务繁忙，久未更新。今天与大家深入聊聊企业AI应用架构这一热门话题。先看下面这张架构图：

首先理清概念：AI应用是一个广泛的范畴，日常所说的智能体（AI Agent）本质上也是AI应用的一种形态。

企业进行AI应用开发时，常见场景主要包括：在现有业务系统中嵌入AI功能、对接第三方系统或AI应用、以及从零构建全新AI应用并接入已有业务数据。本篇文章所介绍的企业AI应用架构，恰好全面覆盖了这些典型场景。下面将进行详细拆解。

企业AI应用架构详细解析：

第一步：应用网关。当用户请求进入后，网关除了执行传统的鉴权、安全防护及限流等操作外，更核心的功能是将请求精准路由至对应的Agent业务模块。

目前编写AI Agent的方式众多，主流有三种：纯编码、低代码平台、以及两者混合。对于业务逻辑较简单的场景，可借助Dify等低代码平台快速封装并创建Agent；当需要精确控制、追求高灵活性与可控性时，则建议自行编码，利用LangChain等框架实现。在实际企业环境中，多数情况采用混合方式——根据不同业务类型和Agent需求，选择最合适的构建策略。

第二步：无论采用何种实现方式，Agent在接收请求后，需先向MCP网关发送消息，以获取当前可用的MCP Server及MCP Tool信息。

第三步为可选步骤。由于MCP网关维护的信息可能相当庞大，可借助LLM来缩小MCP范围，从而减少Token消耗。具体操作是向LLM网关发送请求，与大模型进行交互筛选。

第四步：MCP网关将经过筛选确定范围的MCP Server与Tool列表返回给Agent。

第五步：Agent将用户请求信息，连同从MCP网关获取的全部MCP信息，通过LLM网关发送至大模型。

第六步：大模型完成推理后，依据用户请求，返回对应的MCP Server与Tool信息。

第七步：Agent获取到确定的MCP信息后，通过MCP网关调用相应的Tool，从而获取所需数据。

在实际运行过程中，第二步至第七步会反复循环多次。整体全景图如下：

后续流程尚未完全展开。例如，通过上述第七步多次循环获取各业务数据后，最后仍需通过LLM网关再次调用大模型，由大模型统一处理后返回给终端用户。

这里需要特别说明：通过MCP调用服务获取数据时，若系统采用微服务架构，则MCP Server必须注册到注册中心，否则无法发现后续的各业务微服务。

讲了这么多，可能仍有读者不清楚MCP究竟是什么。这里简单补充：MCP（Model Context Protocol）是一个开源协议，旨在让大模型通过标准化方式连接各类外部数据源与工具。在此之前，主要依赖API方式进行访问。

至于MCP未来是否能成为国际标准，目前尚无定论。不过业界对其认可度很高，众多厂商已纷纷接入。此外，近期还涌现出A2A（Agent to Agent）和AG-UI（Agent to UI）等协议。总体来看，AI发展进程中仍存在一定混乱，新概念与协议层出不穷，有些可能仅是昙花一现，有些则可能成为正式标准。因此，为稳妥起见，下面再展示最传统、不依赖MCP通信的架构：

该架构相对简洁——AI Agent可直接连接数据源获取数据，亦可通过API方式访问其他服务。

最后总结一下。无论采用何种架构（核心区别在于是否使用MCP），均能覆盖企业常用的几种场景：AI应用直接连接数据源、接入企业内部各系统（如现有业务微服务或其他方式），以及接入第三方服务。以上内容供大家参考。