本文提供了一个全面的视角，来看待如何利用模型上下文协议（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 理念，提升应用性能和用户体验。
—1—
AI Agent 现状与架构
AI 大模型在商业领域的应用正成为推动创新和效率提升的核心力量。其关键在于多个AI Agent 的协作，这些 AI Agent 通过分工与合作，共同承载 AI 应用所支持的业务需求。这种协作模式不仅优化了企业运营，还展现了 AI 在解决高影响力挑战中的潜力。
寻找三方服务接口。 在公司内部寻找合适的服务接口。 如果找不到，就需要自行开发接口。
无论是三方服务接口还是公司内部的服务接口，返回格式可能千差万别，需要逐一了解和解析。
使用如 Dify 这类流程可视化的工具辅助编排，虽然减轻了一些工作量，但复杂度依然较高，且在运行效率和性能方面存在瓶颈。 通过编码方式编排（比如：使用 Spring AI Alibaba 或 LangChain 等），虽然性能更优，但复杂度更高，编排效率和灵活性不足。
统一管理 AI Agent 的入口流量，核心功能包括转发、负载均衡、鉴权认证、安全和流控等。
代理各类 LLMs，向 AI Agent 屏蔽了繁杂的接入，并解决了许多生产级问题，比如：多模型切换、模型 Fallback、多 API Key 管理、安全和联网搜索等。
统一管理来自不同源（ACK、ECS、函数计算FC、SAE、三方服务）的各类服务，供 AI Agent 使用。
—2—
MCP 架构设计剖析
基于各语言的 MCP SDK 开发的程序或服务。 它通过某种机制将现有的程序或服务转换为 MCP Server，使其能够与 AI 应进行交互。
MCP Tool 属于 MCP Server，一个 MCP Server 可以有多个 MCP Tool。 可以将其理解为一个类中有多个方法，或者一个服务中有多个接口。
当一段代码、一个 AI Agent 或一个客户端基于 MCP 的规范去使用或调用 MCP Server 中的 MCP Tool 时，它就被称为 MCP Client。
要真正理解 MCP，我们需要深入其运作机制，这不仅能揭示 MCP 调用方式与传统 HTTP 调用方式的差异，还能让你明白为何 MCP 能够助力 AI Agent 迈向第二阶段。
以开发一个获取时间的 AI Agent 为例，用户只需提问“现在几点了？”即可。假设我们已有一个处理时间的 MCP Server，其中包含两个 MCP Tool：一个用于获取当前时区，另一个用于获取当前时间。
基于 MCP 的调用过程分为六个核心步骤：
第一、用户提问
用户向 AI Agent 提问“现在几点了？”。此时，AI Agent 作为 MCP Client，将用户问题连同处理时间的 MCP Server 及 MCP Tool 信息一并发送给 LLM。
第二、LLM 推理
LLM 接收到信息后，根据用户问题和 MCP Server 信息，筛选出最合适的 MCP Server 和 MCP Tool 来解决问题，并将结果反馈给 AI Agent（MCP Client）。LLM 返回的信息可能是：“使用 time MCP Server 中的 get_current_time MCP Tool，它能解决用户的问题。”
第三、调用 MCP Tool
AI Agent（MCP Client）依据 LLM 的建议，调用 time MCP Server 中的 get_current_time MCP Tool，获取当前时间。
第四、返回结果
time MCP Server 将当前时间的结果返回给 AI Agent（MCP Client）。
第五、内容规整
AI Agent（MCP Client）将用户问题和从 time MCP Server 获取的结果再次提交给 LLM，请求 LLM 结合问题和答案规整内容。
第六、最终反馈
LLM 将规整后的内容返回给 AI Agent（MCP Client），AI Agent 再将结果原封不动地返回给用户。
在整个 MCP 调用过程中，MCP Server 及 MCP Tool 的信息至关重要。从第一步和第二步可以看出，这些信息为 LLM 提供了解决问题的关键线索。这些信息本质上就是 MCP 中的 System Prompt，其核心作用是为 LLM 提供清晰的指导，帮助其更好地理解用户需求并选择合适的工具来解决问题。
MCP（模型上下文协议）与传统协议定义不同，它并没有固定的数据结构。其核心在于通过自然语言清晰地描述 MCP Serve r和 MCP Tool 的功能及作用，让大语言模型（LLM）通过推理来选择最合适的 MCP Server 和 MCP Tool。因此，MCP 的本质仍然是提示词工程（Prompt Engineering）。
以下是一些关键的示例和步骤解析：
第一、 MCP Client（Cline）中的 System Prompt
Cline 是一个 MCP Client，其 System Prompt 对 MCP Server 和 MCP Tool 都有明确的描述。比如：它会详细说明每个 MCP Server 的功能以及其中包含的 MCP Tool 的作用。这种描述为 LLM 提供了足够的上下文，使其能够理解每个工具的用途。
上图告诉 LLM：
告诉 LLM 你有一堆工 具可以用。
告诉 LLM 每次你只能选一个工具用。
告诉 LLM 工具是通过 XML 描述定义的。并详细描述了 XML Tag 的定义。并给出了样例。本质就是告诉 LLM 你选择完后该返回什么样的格式。
向 LLM 解释了什么是 MCP。 对每个 MCP Server 和 MCP Tool 做了详细描 述。包括传参格式。
第二、流程第一步：发送问题和 System Prompt
在调用流程的第一步，用户的问题（如“现在几点了？”）和 System Prompt 一起被发送给 LLM。System Prompt 的作用是为 LLM 提供清晰的指导，帮助其理解用户问题的背景和可用的工具。
第三、流程第二步：LLM 返回解决方案
在第二步，LLM 根据用户问题和 System Prompt 中的信息，推理出最合适的 MCP Server 和 MCP Tool，并返回明确的解决方案。比如：LLM 可能会返回：“使用 time MCP Serve r中的 get_current_time MCP Tool 来解决用户的问题。”并以 XML 格式 返回给 Client/Agent。
通过这种方式，MCP 利用自然语言描述和 LLM 的推理能力，动态地选择和调用最适合的工具，从而实现灵活且高效的 AI 应用开发。
通过前面的介绍，相信大家对 MCP 有了清晰的认识。MCP 是否解决了找接口和解析接口的问题呢？答案是肯定的。因为这两个任务都交给了 LLM（大语言模型）来完成。
第一、LLM 负责为 AI Agent 找到最合适的接口。
第二、AI Agent 调用接口时，无需解析返回结果，而是将结果原封不动地交给LLM。
第三、LLM 结合用户问题和接口返回的结果，进行内容规整处理。
那么，MCP 与 LLM 的 Function Calling 有什么区别呢？核心区别在于是否绑定特定的模型或模型厂商：
第一、MCP 是通用协议层的标准，类似于“AI 领域的 USB-C 接口”，定义了 LLM 与外部工具/数据源的通信格式，但不绑定任何特定模型或厂商。它将复杂的函数调用抽象为客户端-服务器架构，使得不同模型和工具之间的交互更加灵活和通用。
第二、Function Calling 是大模型厂商提供的专有能力，由大模型厂商定义，不同厂商在接口定义和开发文档上存在差异。它允许模型直接生成调用函数，触发外部 API，依赖模型自身的上下文理解和结构化输出能力。
例如，LLM Function Calling 需要为每个外部函数编写一个 JSON Schema 格式的功能说明，并精心设计一个提示词模板，才能提高 Function Calling 响应的准确率。如果一个需求涉及几十个外部系统，那么设计成本将是巨大的，产品化成本极高。
而 MCP 统一了客户端和服务器的运行规范，并且要求 MCP 客户端和服务器之间也统一按照某个既定的提示词模板进行通信。这样，通过 MCP 可以加强全球开发者的协作，复用全球的开发成果，降低开发成本，提高开发效率。
通过前面的讨论，我们可以总结 MCP（模型上下文协议）的本质：MCP 并非一个固定的数据格式或结构，而是系统提示词与 MCP Server 和 LLM 之间协同关系的结合。它通过自然语言描述 MCP Server 和 MCP Tool 的功能，让 LLM 能够推理出最适合的工具来解决问题，从而解决了找接口和解析接口的问题。
然而，将 MCP 引入企业级生产应用时，会面临诸多挑战：
第一、描述 MCP 信息的系统提示词的挑战
系统提示词的安全性：系统提示词是 MCP 的核心，如果被污染，LLM 可能会被误导，选择错误甚至存在安全漏洞的 MCP Server 和 MCP Tool，从而导致整个 MCP 流程瘫痪，给 AI 应用带来巨大风险。
系统提示词的管理：当 MCP Server 或 MCP Tool 更新时，系统提示词也需要相应地进行版本管理，以确保 LLM 能够获取最新的工具信息。
系统提示词的调试与实时生效：系统提示词没有标准定义，每个企业都可以自定义模板。由于提示词需要反复调试，因此需要一种机制能够快速调整并实时生效。
系统提示词的 Token 消耗：如果 MCP Server 和 MCP Tool 数量众多，系统提示词会变得非常长，消耗大量 Token，增加成本。因此，需要一种机制基于用户问题预筛选 MCP Server 和 MCP Tool 的范围，减少 Token 消耗，提高效率。
第二、MCP Client 与 MCP Server 之间协同关系的挑战
MCP Client 的稀缺性：目前市面上的 MCP Client（比如：Cline、Claude、Cursor 等）数量有限，且大多基于 C/S 架构，仅支持 SSE 协议。这种有状态的协议存在诸多弊端，比如：不支持可恢复性、服务器需维持长期连接、仅支持单向通信等，难以与企业级 AI 应用结合。
现存业务的转换难题：开发 MCP Server 依赖于特定语言的 MCP SDK （目前仅支持 Python、Java、TS、Kotlin、C#）。对于使用 Go 或 PHP 等其他技术栈的企业，转换为 MCP Server 的工作量巨大，且不现实。
MCP Server 的统一管理：企业可能拥有自建的 MCP Server、第三方的 MCP Server 以及通过某种机制转换而来的 MCP Server。需要一个类似 MCP Hub 或 MCP 市场的平台来统一管理这些 Server，方便 MCP Client 使用。
企业级应用中的安全与权限问题：在企业级应用中，身份认证、数据权限和安全防护是关键问题。在 MCP 的协同模式下，如何实现这些功能是亟待解决的挑战。
总之，尽管 MCP 为 AI 应用开发带来了灵活性和效率提升，但在企业级应用中，仍需克服系统提示词的安全性、管理、调试以及 MCP Client 与 MCP Server 之间的协同关系等多方面的挑战。
—3—
AI 应用架构设计新范式
AI 应用架构结合 MCP，我们定义了 AI 应用架构的新范式。
一个云原生 API 网关三种角色，具备统一的管控底座，同时又实现各角色的协同调度。
Nacos 发挥注册中心优势，增加 MCP Server 的注册能力，实现普通服务和 MCP Server 的统一管理，结合网关实现现存业务0改造转换为 MCP Server。
SpringCloud 服务/Dubbo 服务/Go 服务 → 各类 MCP Server SpringCloud 服务/Dubbo 服务/Go 服务暴露的接口 → 各类 MCP Server 提供的 MCP Tool SpringCloud 服务/Dubbo 服务/Go 服务暴露的接口描述 → 各类 MCP Server 提供的 MCP Tool 的描述 SpringCloud 服务/Dubbo 服务/Go 服务的配置文件 → 各类 MCP Server 的系统提示词
手动创建：在 Nacos 控制台手动创建，将 MCP Server 的 Endpoint 配置到 Nacos 中。
自动注册：通过 Nacos SDK 自动将 MCP Server 注册到 Nacos，逻辑与当前 Java SpringCloud、Java Dubbo 服务类似。
健康检查：监控 MCP Server 的健康状态。 负载均衡：合理分配流量，提高系统稳定性。 描述信息转换：支持从 JSON 到 XML 的格式转换。 上下线管控：灵活控制 MCP Server 的上线和下线。
手动创建：手动创建 MCP Server 的配置信息，配置文件的 Data ID 命名格式为 [MCP Server name]-mcp-tools.json。在配置文件中管理 MCP Tool 的提示词信息，比如：整体作用描述、入参描述等。 自动感知：结合治理能力，如果是Java或Go语言，可以自动感知服务的 Schema，自动生成 MCP Server 和 MCP Tool 的提示词信息。
版本管理：支持版本回滚，确保系统稳定运行。 灰度管理：支持灰度发布，逐步推广新版本。 安全管理：确保提示词的安全性，防止被污染或篡改。 动态调优：支持动态调整提示词，实时生效，提高系统灵活性。
在 MCP 范式中，主要涉及三个角色之间的协同工作：
MCP Client：与 LLM 交互，发起请求并接收响应。
LLM：处理 MCP Client 的请求，推理并选择合适的 MCP Server 和 MCP Tool。
MCP Server：提供具体的工具和功能，执行实际的任务。
MCP Client 与 LLM 以及 MCP Client 与 MCP Server 之间的协同关系，本质上是服务提供方与服务消费方之间的关系。这涉及到两个核心点：代理协作和流量管控。在传统的开发范式中，这些功能通常由网关来负责。因此，我们在云原生 API 网关中增强了 LLM 代理和 MCP Server 代理的能力，使其具备了流量网关、AI 网关（LLM 代理）和 MCP 网关的功能。这使得云原生 API 网关成为 AI 应用开发新范式的核心组件。
在企业的整体系统架构中，通过使用云原生 API 网关，可以实现流量网关、API 网关、微服务网关、AI 网关和 MCP 网关的功能。这不仅在代理和流量管控层面实现了传统业务和 AI 业务的统一，还通过结合 AI 应用开发的新范式，平滑地将 AI 业务与传统业务相结合。这种整合方式极大地简化了企业的技术栈，提高了系统的灵活性和可维护性，同时也降低了开发和运维的复杂性。
MCP Client 与 LLM 之间的交互，以及传统业务与 LLM 之间的交互，本质上都面临一系列共性问题。这些问题在应用生产环境中尤为突出，具体如下：
成本平衡问题：部署大语言模型（比如：DeepSeek R1 671B 满血版）需要高昂的成本，至少需要2台8卡 H20 机器，年度费用超过100万元，且其 TPS 有限，难以满足多用户并发请求。即使是 Meta 新发布的 Llama4，也需要至少一张 H100 显卡来运行。因此，需要找到 TPS 与成本之间的平衡点。
模型幻觉问题：即使是性能强大的 DeepSeek R1 671B 满血版模型，在没有联网搜索的情况下，也会出现严重的幻觉问题。
多模型切换问题：单一模型服务存在较大风险和局限性，比如：稳定性风险，以及无法根据不同业务（消费者）需求选择最优模型。目前缺乏开源组件和框架来解决这类问题。
安全合规问题：企业客户需要对问答过程进行审计，以确保合规并降低使用风险。
模型服务高可用问题：当自建平台性能达到瓶颈时，需要一个大模型兜底方案，以提升客户对大模型的使用体验。
闭源模型 QPS/Token 限制问题：商业大模型通常基于 API Key 维度设置 QPS/Token 配额限制，需要一种有效方式快速扩展配额限制。
这些问题都是客户在实际使用过程中遇到的，有些源于大模型自身特性，有些则是部署架构导致。如果让客户逐一解决这些问题，不仅复杂度高，而且时间成本也很大。因此，需要 AI 网关的介入，以快速、统一地解决这些核心问题。
云原生 API 网关的 AI 网关增强能力主要体现在以下四个方面：
多模型适配：能够代理市面上所有主流的模型托管服务，以及兼容 OpenAI 协议的 AI 服务。该模块包括协议转换、多 API Key 管理、Fallback、多模型切换等多个核心功能。
AI 安全防护：安全防护涵盖三个层面：输入输出的内容安全防护、保护下游 LLM 服务的稳定，以及管控 AI 接口消费者。该模块包括内容审核、基于 Token 的限流降级、消费者认证等多个核心功能。
AI 插件：AI 网关的灵活扩展机制通过插件形式实现，目前提供许多预置插件，用户也可以开发自定义插件来丰富 AI 场景流量的管控。比如：基于 AI 插件机制实现了结果缓存、提示词装饰器、向量检索等能力。
AI 可观测：AI 场景的可观测性与传统场景有很大区别，监控和关注的指标也不同。云原生 AI 网关结合阿里云日志服务和可观测产品，实现了贴合 AI 应用业务语义的可观测模块和 AI 观测大盘，支持 Tokens 消费观测、流式/非流式的 RT、首包 RT、缓存命中等可观指标。同时，所有输入输出 Tokens 都记录在日志服务 SLS中，可供用户进行更详细的分析。
不支持可恢复性（Resumability）：连接断开后，客户端必须重新开始整个会话。 服务器需要维持长期连接（High Availability Requirement）：服务器必须保持高可用性，以支持持续的 SSE 连接。 SSE 仅支持服务器→客户端消息，无法灵活进行双向通信。 目前只有少数几个C/S架构的客户端和 MCP 提供的用于测试验证的 Web 客户端支持 MCP 范式和 SSE 协议，无法应用于企业级的生产应用中。
更灵活：支持流式传输，但不强制。 更易用：支持无状态服务器。 更兼容：适用于标准 HTTP 基础设施。
Streamable HTTP 打破了目前几个 C 端 MCP Client 的壁垒，意味着任何请求方（甚至是一段简单的 HTTP Request 代码）都可以像请求标准 HTTP API 一样与 MCP Server 交互。 换句话说，当可以使用标准 HTTP API 的方式与 MCP Server 交互时，所谓的 MCP Client 可能就不存在了。
Client 有权使用哪些 MCP Server：Client 有权使用哪些 MCP Server，以及有权使用某 MCP Server 中的哪些 MCP Tool。 Client 通过 MCP Tool 有权获取哪些数据：当 MCP Server 是数据类服务时，权限会下探到库级别、表级别。
在 AI 应用中，涉及 LLM 推理的场景通常调用频率较低，属于稀疏调用场景。由于 MCP 范式强依赖 LLM 推理，无论是基于 HTTP API 的传统 AI 应用开发架构，还是基于 MCP 的新架构，目前都主要应用于这些稀疏调用场景。这引发了两个关键问题：
在稀疏调用场景下，如何优化运行 MCP Server 的计算资源利用率，实现成本最优？
在新的业务中，如何快速构建 MCP Server？
在所有计算产品中，函数计算（FC）这种 Serverless FaaS 类型的计算产品，在资源粒度、弹性策略、弹性效率方面最适合稀疏调用场景。
第一、函数计算（FC）支持 MCP 运行环境
阿里云函数计算（FC）目前支持 Python 和 NodeJS 两种语言的 MCP 运行环境（其他语言的 MCP 运行环境也将很快支持）。用户选择 MCP 运行环境创建函数后，只需编写 MCP Tool 的业务逻辑，无需考虑如何使用 MCP SDK。此外，云原生 API 网关与函数计算（FC）深度集成，天然适配 AI 应用开发的新范式。
第二、MCP Server 的弹性效率
基于函数计算（FC）构建的 MCP Server 在弹性效率方面有显著优势，主要体现在两个维度：
1、资源规格细粒度管控
函数计算（FC）提供从 0.05C 128MB 到 16C 32GB 的多种实例规格，用户可以根据不同 MCP Server 承载的业务灵活选择合适的资源规格。在 AI 应用中，尤其是流程式构建的模式中，大多数 AI Agent 的职责单一，计算逻辑简单，因此可以用较小资源规格的函数承载。较小的资源规格在资源调度和弹性效率方面具有天然优势。
2、完全按请求弹性
函数计算（FC）的弹性机制完全基于请求，根据 QPS 自动拉起对应数量的实例，且实例可以复用。当 QPS 下降时，空闲实例会自动释放，整个过程无需用户介入。此外，用户还可以设置按时间定时弹性或按指标阈值弹性策略，进一步满足复杂多变的业务场景，实现资源成本最优。
第三、MCP Server 的可观测性
函数计算（FC）具备完善的可观测体系，这意味着基于函数计算（FC）构建的 MCP Server 同样具备指标、链路、日志三个维度的可观测能力。通过这套可观测体系，用户可以清晰地了解每个 MCP Server 的各类运行状态，从而更好地管理和优化 MCP Server 的性能和成本。
通过函数计算（FC）的这些特性，企业可以高效地构建和管理 MCP Server，优化资源利用率，降低成本，同时快速响应业务需求，提升 AI 应用的开发和部署效率。
结合阿里云可观测产品 ARMS 和链路追踪 OpenTelemetry，我们构建了覆盖 AI 应用全环节的可观测体系。这一体系的构建主要围绕两个核心部分展开：数据采集和数据串联与分析。
第一、观测数据采集
数据采集的核心是覆盖足够广泛的范围，这主要体现在两个层面：
1、编程语言和开发框架的支持
支持范围广：支持 AI 应用开发的主流编程语言，比如：Python、Java、Go，并且相比社区规范提供更加精细化的埋点和属性。
框架支持：支持常见的 AI 框架和模型，包括 Spring AI Alibaba、LLamaIndex、Langchain、通义千问2、OpenAI、PromptFlow 等。
2、云产品数据上报
标准统一：AI 应用架构新范式中涉及的云产品需要以相同的标准上报数据。
网关支持：云原生 API 网关支持 OpenTelemetry 协议，网关自身和插件都会基于 OpenTelemetry 上报观测数据。
深度集成：函数计算 FC 和 Serverless 应用引擎 SAE 均与应用监控 ARMS 以及链路追踪 OpenTelemetry 产品深度集成。
通过以上措施，我们实现了数据采集的全覆盖，确保了可观测体系的完整性。
第二、数据串联与分析
在应用监控 ARMS 中，专门构建了 LLM 应用监控模块，为 AI 应用场景提供了完善的可观测体系。这一模块从纵向和横向两个维度提供了丰富的监控指标和分析功能。
1、纵向指标
在线 AI 应用数
Trace 数
Span 数
大模型数
Token 使用情况
会话数
用户数
模型调用次数
Token 消耗情况
模型调用耗时
Token 消耗排行
2、横向链路分析
Span 列表：展示每个 Span 的详细信息。
Trace 列表：提供完整的 Trace 记录。
散点图：通过散点图分析性能分布。
全链路聚合：对整个调用链进行聚合分析。
全链路拓扑：展示调用链的拓扑结构。
错/慢 Trace 分析：分析错误和慢 Trace 的原因。
调用链展示：在调用链的每个环节展示输入、输出和 Token 消耗情况。
通过这些功能，用户可以清晰地了解 AI 应用的运行状态，快速定位问题，优化性能，确保 AI 应用的稳定运行。
—4—
AI 应用架构设计新范式对企业的影响
