深度剖析基于MCP实现AI应用架构设计新范式（一）AI Agent 现状与架构

最新推荐文章于 2025-05-18 20:17:36 发布

大模型本地部署_

最新推荐文章于 2025-05-18 20:17:36 发布

阅读量660

点赞数 30

文章标签：人工智能架构语言模型 AI大模型自然语言处理 LLM MCP

本文链接：https://blog.csdn.net/Androiddddd/article/details/147161268

版权

本文提供了一个全面的视角，来看待如何利用模型上下文协议（MCP）实现 AI 应用架构设计新范式的落地实现，核心内容主要是以下5点：

MCP 概念与机制。
MCP 与 Function Calling 区别。
MCP 本质与挑战：挑战包括系统提示词的准确性、Client 与 Server 协同、快速构建 Server、自建 Dify 的痛点等。
解决 MCP 挑战的方法：通过 MCP Register、统一管理 Server 和 Prompt、建立效果验证体系与安全保障、设置 MCP 网关、动态服务发现、Streamable HTTP、弹性效率、可观测等手段解决。
AI 应用架构设计新范式：MCP 推动 AI 应用架构向新范式发展，并通过 Server First 理念，提升应用性能和用户体验。

一、AI Agent 现状与架构

AI 大模型在商业领域的应用正成为推动创新和效率提升的核心力量。其关键在于多个AI Agent 的协作，这些 AI Agent 通过分工与合作，共同承载 AI 应用所支持的业务需求。这种协作模式不仅优化了企业运营，还展现了 AI 在解决高影响力挑战中的潜力。

目前 AI Agent 与各种 Tools（业务服务接口）、Memory（存储服务接口）以及 LLMs（大语言模型）的交互主要通过 HTTP 协议实现。除了 LLMs 基本遵循 OpenAI 范式外，与其他 Tools 和 Memory 的交互需要逐一了解它们的返回格式进行解析和适配，这增加了开发的复杂性。

当一个 AI 应用包含多个 AI Agent，或者需要与多个业务服务接口和存储服务接口交互时，开发工作量显著增加，主要体现在以下三个方面：

第一、寻找合适的接口

寻找三方服务接口。
在公司内部寻找合适的服务接口。
如果找不到，就需要自行开发接口。

第二、解析接口返回格式

无论是三方服务接口还是公司内部的服务接口，返回格式可能千差万别，需要逐一了解和解析。

第三、编排多个 AI Agent

使用如 Dify 这类流程可视化的工具辅助编排，虽然减轻了一些工作量，但复杂度依然较高，且在运行效率和性能方面存在瓶颈。
通过编码方式编排（比如：使用 Spring AI Alibaba 或 LangChain 等），虽然性能更优，但复杂度更高，编排效率和灵活性不足。

因此，目前许多 AI应用只包含少数几个 AI Agent，甚至很多应用背后只有一个 AI Agent。这也是目前 AI 应用背后的 AI Agent 仍处于第一阶段（Siloed, Single-Purpose Agents）的原因。

为了使 AI Agent 进入第二阶段（Platform-Level Agents），我们使用云原生 API 网关作为统一的接入层，通过网关的三种不同角色，解决了部分复杂度问题：

第一、作为南北向流量网关

统一管理 AI Agent 的入口流量，核心功能包括转发、负载均衡、鉴权认证、安全和流控等。

第二、作为 AI 网关

代理各类 LLMs，向 AI Agent 屏蔽了繁杂的接入，并解决了许多生产级问题，比如：多模型切换、模型 Fallback、多 API Key 管理、安全和联网搜索等。

第三、作为东西向网关

统一管理来自不同源（ACK、ECS、函数计算FC、SAE、三方服务）的各类服务，供 AI Agent 使用。

然而，上述方法仅解决了部分复杂度问题，更核心的寻找接口和解析接口的问题仍未得到解决。直到 MCP（Model Context Protocol）的出现，我们看到了真正通往第二阶段（Platform-Level Agents）的道路，甚至有望触及第三阶段（Universal Agents, Multi-Agents）。