企业AI落地实践（三）：使用 AI 网关解决 AI Agent 与 LLM 的交互挑战

从上一篇内容开始，我们开始具体分析 AI 应用实践过程中每一个环节的核心挑战，以及我们对应的解法和思路。

无论是编码方式构建 AI Agent，还是可视化流程式构建 AI Agent，一旦脱离了 LLM，就不存在 AI 一说了。所以 AI Agent 如何合理地、生产级地与 LLM 结合，将是我们今天文章的核心内容。

关注阿里云云原生公众号，后台回复“企业AI实践”获得我们整理的完整的企业级 AI 应用构建的最佳实践 PPT，配合系列文章一起食用，效果更佳。

我们都知道现在大部分的 LLM 都是遵循 OpenAI 范式的请求方式，编码方式构建 AI Agent 和可视化流程式构建 AI Agent 虽然在使用方式上不同，但底层本质是一致的：

• 编码方式构建 AI Agent 使用 LLM：不同的 AI Agent 开发框架都会封装市面上主流的 LLM 厂商的 SDK，比如 OpenAI 的，百炼的，我们只需要简单的声明和配置就可以和 LLM 交互。

• 可视化流程式构建 AI Agent 使用 LLM：流程式通常都是通过 LLM 节点和 Agent 节点和 LLM 交互。

无论是上述哪种，都需要配置 LLM 服务的地址（https://www.xxx.com/v1/chat/completions）和 LLM 服务用于认证鉴权的 API Key。所以 AI Agent 和 LLM 的交互本质上都是通过一层 Proxy，所有对 LLM 请求的管控、LLM 服务的管理都应该是这层 Proxy 协助做的事，这也正是 AI 网关做的事。

在当前 AI 普惠的阶段下，有一个显著的特点就是用户们选择使用 LLM 的方式变多了，自主可控能力变强了。比如可以购买 GPU 资源自己部署大模型，可以在线下机房部署大模型，也可以使用阿里云的 PAI 或者函数计算 FC 来部署大模型。也可以使用各个模型托管平台，通过 API 的方式来使用大语言模型。但无论选择哪种方式，在 LLM 应用上生产项目的过程中，必然都会遇到一系列问题：

• 成本平衡问题：部署 DeepSeek R1 671B 满血版模型，至少需要 2 台 8 卡 H20 机器，列表价年度超过 100W，但 2 台的 TPS 有限，无法满足生产部署中多个用户的并发请求，需要有方案找到 TPS 和成本之间的平衡点。

• 模型幻觉问题：即使是 DeepSeek R1 671B 满血版模型，如果没有联网搜索，依然有很严重的幻觉问题。

• 多模型切换问题：单一模型服务有较大的风险和局限性，比如稳定性风险，比如无法根据业务（消费者）选择最优模型，无法根据不同用户对不同模型做 Token 限额等。目前也没有开源组件和框架解决这类问题。

• 安全合规问题：企业需要对问答过程做审计，确保合规，减少使用风险。

• 模型服务高可用问题：自建平台性能达到瓶颈时需要有一个大模型兜底方案，提升企业大模型使用体验。

• 闭源模型 QPS/Token 限制问题：商业大模型都有基于 API Key 维度的 QPS/Token 配额限制，需要一个好的方式能够做到快速扩展配额限制。

以上问题都是实实在在的企业在使用过程中遇到的问题，有些是模型自身问题，有些是部署架构问题，如果由企业一个一个去解决，复杂度和时间成本都是比较高的。所以就需要 AI 网关的介入来快速的，统一的收敛掉这些核心问题。

AI Agent 与 LLM 交互遇到的问题和普通服务与 LLM 交互的问题基本一致，所以这个章节我们主要讨论使用 AI 网关代理模型服务如何解决目前与 LLM 交互遇到的问题。

阿里云AI网关和阿里云云原生API网关同属一个内核。

AI 网关的能力主要包括六部分：

• 模型服务管理：可以代理市面上所有主流的模型托管服务，以及兼容 OpenAI 协议的 LLM 服务和多模态 LLM 服务。在这个模块中包括协议转换、多 API Key 管理、Fallback、多模型切换等多个核心功能。

• MCP 管理：负责 MCP 服务的代理以及 MCP 服务的策略管理。包括代理原生 MCP 服务，HTTP 服务转 MCP 服务，MCP 服务鉴权认证，和 MSE Nacos 集成实现从 MCP Registry 自动发现 MCP 服务。

• Agent 管理：负责 Agent 的代理以及 Agent 的策略管理。目前支持代理百炼 Agent，dify 构建的 Agent（流程），AIStudio 构建的 Agent（流程），自定义 Agent。

• AI 安全防护：安全防护分为三个层面，一个是输入输出的内容安全防护，另一个是保护下游 LLM 服务的稳定，以及管控 AI 接口消费者。在这个模块中包括内容审核、基于 Token 的限流降级、消费者认证等多个核心功能。

• AI 插件：AI 网关的灵活扩展机制我们使用插件的形式来实现，目前有很多预置的插件，用户也可以开发自定义插件来丰富 AI 场景流量的管控。比如基于 AI 插件机制我们实现了结果缓存、提示词装饰器、向量检索等能力。

• AI 可观测：AI 场景的可观测和传统场景的可观测是有很大区别的，监控和关注的指标都是不同的，云原生 AI 网关结合阿里云日志服务和可观测产品实现了贴合 AI 应用业务语义的可观测模块和 AI 观测大盘，支持比如 Tokens 消费观测，流式/非流式的 RT，首包 RT，缓存命中等可观指标。同时所有的输入输出 Tokens 也都记录在日志服务 SLS 中，可供用户做更详细的分析。

从上图架构中可以看出，AI 网关代理 LLM 方案的架构并不复杂，但是在 AI 应用上生产的过程中通常会遇到 10 个核心的问题，然而在上面这个并不复杂的架构下，通过 AI 网关都可以很有效地解决。接下来我们通过 AI Agent 视角、用户视角、业务场景视角来逐一分析和说明。

解决 AI Agent/用户管理失控的问题

现在大大小小的企业都在部署 LLM，想方设法融入到业务中，或日常工作中，那么站在运维团队或者类似中台团队的视角下，可能会有两个核心的问题：

• 核心问题 1：以什么样的方式将 LLM 服务和能力暴露给用户或 AI Agent？

• 核心问题 2：GPU 资源有限，成本又高，如果是一个面向 C 端用户的 AI Agent，如何限制用户？

第一个问题很好解决，OpenAI API 的协议基本已经是标准协议，目前市场面上大多数 LLM 都支持 OpenAI API 协议。但也有例外，比如 AWS Bedrock 上的模型，Gemini 是不遵循 OpenAI API 协议的。另外还有 Embedding 和 Rerank 模型，以及 Cosyvoice 和 SD、Flux 这类多模态模型都不是 OpenAI API 协议。所以对于一个通用 AI Agent 或者一个企业来说，更希望有统一的 Model API，可以统一管理和管控不同类型模型的 API。

目前上述这些类型的模型，AI 网关都支持代理，所以可以在同一个模型 API 管控平台上，统一管理和管控不同类型的模型 API。

对于第二个问题，AI 接口一旦暴露出去，基本上不可能只让一小部分人知道，所以需要对访问 LLM 服务的用户做以限制，只让能访问的人访问，不能访问的人即便知道了接口也无法访问。

所以可以使用 AI 网关具备的消费者认证的能力来解决这个问题。

核心逻辑是将一个人或一个 AI Agent 抽象为消费者的概念，可以对消费者做权限配置，既可以访问哪些模型 API，消费者下可以生成不同类型的 API Key，请求接口时需要带着 API Key，然后基于权限规则去校验 API Key 的合法性。通过这种就可以精细化地管理访问 AI 接口用户了。

消费者认证的核心价值：

• 身份可信：确保请求方为注册/授权用户或系统。

• 风险拦截：防止恶意攻击、非法调用与资源滥用。

• 合规保障：满足数据安全法规及企业审计要求。

• 成本控制：基于鉴权实现精准计费与 API 配额管理。

典型鉴权场景与 API Key 应用场景：

• 第三方应用接入：

• 挑战：开发者身份混杂，权限难隔离。

• 解决方案：为每个应用分配独立 API Key，绑定细粒度权限策略。

• 企业内部服务调用：

• 挑战：内网环境仍需防越权访问。

• 解决方案：API Key + IP 白名单双重验证，限制访问范围。

• 付费用户 API 访问：

• 挑战：防止 Key 泄露导致超额调用。

• 解决方案：针对 API Key 限流。

• 跨云/混合部署：

• 挑战：异构环境统一身份管理。

• 解决方案：集中式 API Key 管理平台，支持多集群同步鉴权。

解决灵活路由模型的问题

灵活路由模型在实际项目中对应着两类问题：

• 不同的模型解决不同的任务，需要统一的模型服务 API 提供给业务方，不同的业务方只需要基于实际业务切换不同的模型名称即可。对于负责 AI 的中台团队，可以基于同一个模型 API 统计各个业务方的调用情况（尤其是核算成本）。从而解决统一分发、管理、集成的问题。

• 用户期望基于不同的用户和模型做 Token 配额管理。

AI 网关支持一个模型 API 下配置多个模型服务的能力，每个模型服务通过 Glob 语法来匹配模型名称，从而实现上述的第一个场景。

除此以外，AI 网关的模型 API 支持基于不同的匹配规则创建不同的路由，可以基于请求 Header 或者请求参数中的参数值做匹配规则。

这样，我们可以通过 Header 中的 x-higress-llm-model 和 x-mse-customer 这两个标识作为路由匹配规则，实现通过消费者和模型名称路由的功能。

然后再配合模型 API 的限流策略，针对同一个消费者做 Token 限流，从而实现上述的基于不同的用户和模型做 Token 配额管理的需求。

再延伸一下模型路由的核心价值：

• 业务需求适配：根据业务复杂性或性能要求选择不同模型。

• 数据隐私与合规性：在处理敏感数据时，可能需要切换到符合特定法规的模型，确保数据处理的安全性。

• 性能优化：根据实时性能需求，可能会切换到更快的模型以减少延迟。

• 成本与性能平衡：根据预算动态选择性价比最优的模型。

• 领域特定需求：针对特定领域（如法律、医学），可能需要切换到在相关领域微调过的模型，以提高推理准确性。

• 容灾与故障转移：主模型服务异常时快速切换备用模型。

解决闭源模型&模型托管平台 QPM/TPM 限制的问题

像 ChatGPT，豆包这类闭源 LLM，或者百炼这种托管 LLM 平台，都是以提供 API 的方式供大家使用 LLM 的能力，但是受限底层 GPU 资源的压力，以及整体平台的稳定性，每个用户都有请求 QPS 的最大限制（基于平台的 API Key 的维度），且上调比较困难。所以很多企业都有这个核心问题：如何突破这个限制问题？

这个问题有两类解决方案：

• 我们知道这些平台上调限制额度比较困难，那么就用「迂回」方式，即多申请一些帐号，来变相地把限制额度撑大，但是又会带来新的问题，那就是这些帐号的 API Key 如何管理。

• 另一个方法就是对输入/输出内容做缓存，减少对模型服务的请求次数以及 Token 消耗，从而提升业务侧的请求性能，相当于变相增加了限制额度。

多 API Key 管理

AI 网关在 LLM 服务级别支持多 API Key 管理的能力，每次请求会轮循取一个 API Key 向后端模型服务请求。并且 API Key 可以动态新增和删除，极大减轻了用户自己维护多个 API Key 的问题。

结果缓存

AI 网关提供了结果缓存的预置策略，可以将请求和响应的内容存储到 DashVector 做语义化缓存，或者存储到 Redis 做精确缓存，从而提升推理效率。

语义化缓存

支持用户自己选择用于做 Embedding 的模型，需要用户实现开通 DashVector 服务。并且支持只取最新提问和整合历史提问两种缓存键生成策略。语义化缓存的适用范围更宽泛一些。

精确缓存

精确缓存不涉及到 Embedding，是把用户问题和 LLM 的响应直接存储到 Redis 中。精确匹配的适用范围更窄，只适合非常垂直的一些场景。

解决模型服务高可用的问题

现在 GPU 的资源是昂贵的，所以无论是自购 GPU 部署 LLM 还是模型托管平台都不会基于流量峰值去储备资源，所以才会有上文中的 QPM/TPM 限制的情况。但是站在企业业务健壮性的角度来看，如何在成本、稳定性、健壮性之间找到一个平衡点是更需要考虑的事。比如，当主力模型是 PAI 上部署的 DS R1 671B，但 GPU 资源并不是基于流量峰值储备的，所以当高峰期时，DS 服务会请求失败，有什么办法可以保证业务健壮性？

这类问题可以有两种做法，并且可以搭配使用：

• 可以构建多个兜底模型服务，如果要保证模型一致，可以主力使用 PAI 上部署的，兜底使用百炼平台提供的。实现当 PAI 上部署的 DS 服务请求失败时，Fallback 到百炼平台托管的 DS R1 服务。从而保证业务的连续性和健壮性。

• 通过基于 Tokens 的限流策略，解决 Burst 流量，保护后端模型服务。

LLM 服务 Fallback

AI 网关在模型 API 维度支持 LLM 服务的 Fallback 机制，并且可以配置多个 Fallback LLM 服务。当主 LLM 服务因为各种原因出现异常，不能提供服务时，AI 网关侧可以快速将请求 Fallback 到配置的其他 LLM 服务，虽然可能推理质量有所下降，但是保证了业务的持续性，争取了排查主 LLM 服务的时间。

Token 维度限流

除了传统的 QPS 限流降级以外，AI 网关支持更贴合 LLM 推理场景的 Token 维度的限流能力。可以针对模型 API 级别配置一个下游 LLM 服务可以承载的请求量级，在一定程度上保证了整体业务的健壮性，至于被限流的请求，可以返回一些人性化的信息，比如之前 DeepSeek 官网的服务器繁忙。

我们可以再延伸一下基于 Token 维度限流的其他核心价值：

• 成本管理：LLM 的费用通常基于 Token 数量计算，限流帮助用户避免超支。例如，服务提供商可能按 Token 使用量提供不同定价层。

• 资源管理：LLM 需要大量计算资源，限流防止系统过载，确保所有用户都能获得稳定性能，尤其在高峰期。

• 用户分层：可以基于消费者或者 API Key 进行 Token 限流。

• 防止恶意使用：通过限制 Token 数量来减少垃圾请求或攻击。

解决安全合规问题

AI 应用场景下的内容安全问题是大家都很重视的核心问题，模型托管平台通常都自带好几层内容安全审核机制，但是我们在 IDC 部署或者在 PAI 部署的，如何能方便接入内容安全审核服务？

AI 网关中的模型 API 集成了阿里云的内容安全防护服务和 AI 安全护栏能力，可以一键开启，支持请求内容检测和响应内容检测。不过安全防护的规则还是要在内容安全服务侧配置。比如“树中两条路径之间的距离”这个可以让 LLM 无限推理的问题，从内容安全的常规规则来看，它是合规的，但是它却能对 LLM 服务的稳定性造成隐患，所以在 AI 网关开启了内容安全防护后，便可以快速在内容安全防护服务中添加自定义规则来杜绝这类有潜在风险的请求信息。

延伸到内容安全在 AI 领域的核心价值有五类：

• 防止攻击：验证输入可以阻止恶意提示注入，防止模型生成有害内容。

• 维护模型完整性：避免输入操纵模型，导致错误或偏见输出。

• 用户安全：确保输出没有有害或误导性内容，保护用户免受不良影响。

• 内容适度：过滤掉不适当的内容，如仇恨言论或不雅语言，特别是在公共应用中。

• 法律合规：确保输出符合法律和伦理标准，尤其在医疗或金融领域。

解决大语言模型幻觉的问题

有些个人用户或者企业用户可能会发现部署了 DeepSeek R1 671B 的模型，但推理的结果和 DS 官网推理的结果有差距，似乎不满血？

推理的结果和 DeepSeek 官网推理的结果有差距是因为 DeepSeek 官网开启了联网搜索。DeepSeek R1 671B 的模型推理能力是很强，但训练的数据也是有限的，所以要解决幻觉还是需要在推理前先搜索和处理出比较确切的信息后，再由 DeepSeek R1 推理，所以联网搜索是非常关键的。目前模型托管平台提供的 DeepSeek R1 API 和自己部署的 DeepSeek R1 都需要自己实现联网搜索。

其实不只是 DeepSeek，目前除了百炼上的通义千问 Max 以外，其他的模型在 API 层面都不支持联网搜索，即使 ChatGPT 是最早推出联网搜索功能的，但 OpenAI 的 API 协议目前也还没有支持联网搜索。

AI 网关目前在模型 API 维度支持了夸克的联网搜索能力，提供多种搜索策略，可将搜索结果自动如何进输入 Prompt，无需用户对后端 LLM 服务做额外处理，并且我们对输入的问题也通过 LLM 做了意图识别和问题拆分，避免了很多无效的联网搜索，以及提高搜索内容的精准度。

LLM 服务动态负载

很多使用 PAI 或者 ACK 部署 LLM 的用户，经常会遇到 GPU 服务负载不均的情况，这也是AI领域中比较常见的问题。也有一些企业是自研或魔改 vllm/sglang/trt 推理框架，在模型网关层从推理框架侧获取到 GPU 服务的执行状态以及 GPU 资源的使用情况，从而判断做动态负载。

目前 AI 网关内部已经实现了基于 vLLM 和 SGLang 两个推理框架提供的监控指标来动态负载 LLM 服务的能力，AI 网关可以基于这些指标来决定路由流量到哪个节点，帮助用户提升 GPU 的资源利用率，从而优化成本和提升推理效率。

模型 API 可观测

可观测是任何一个领域都必不可少的需求，但是 AI 场景的可观测和传统场景的可观测是有很大区别的，监控和关注的指标都是不同的，AI 网关结合阿里云日志服务和可观测产品实现了贴合 AI 应用业务语义的可观测模块和 AI 观测大盘，支持比如 Tokens 消费观测，流式/非流式的 RT，首包 RT，缓存命中等可观指标。同时所有的输入输出 Tokens 也都记录在日志服务 SLS 中，可供用户做更详细的分析。

AI 网关模型 API 的可观测核心能力：

• 访问日志，其中的 ai_log 字段可以自动打印大语言模型的输入、输出。

• 大语言模型的 metrics 信息： 首字延时（TTFT-Time To First Token）, tokens per second。

• 传统指标： QPS( request per second), RT(延时），错误率。

• 网关功能指标：

• 基于 consumer 的 token 消耗统计(需要把 consumer 的 header 信息加到 sls 的日志里）

• 基于模型的 token 消耗统计。

• 限流指标: 每单位时间内有多少次请求因为限流被拦截; 限流消费者统计（是哪些消费者在被限流）。

• 缓存命中情况。

• 安全统计：风险类型统计、风险消费者统计。

将近 3 个月，我们交流了上百家客户，无论是编码方式构建 AI Agent 还是流程方式构建 AI Agent，使用 LLM 时遇到的问题基本上逃不出我上面总结的那些问题，所以使用 LLM 的最佳实践就是通过 AI 网关代理 LLM 这种方式，在 AI 网关的模型 API 上根据业务需求做各类管控，在稳定性、灵活扩展性（适配业务多样性）、成本优化等方面帮 AI Agent 的大脑具有足够的健壮性。

上文中解析了 AI Agent 的第二个核心组件是工具，它为 AI Agent 提供外部能力，各类业务服务，数据库服务，存储服务等等。即执行 LLM 做出的决策。

然而，无论是和各种 Tools（各类业务服务接口）交互，还是和各类存储服务接口交互，都是通过 HTTP 协议的，和各类 Tools 的交互都需要逐一了解它们的返回格式进行解析和适配。当一个 AI 应用包含多个 AI Agent 时，或者一个 AI 应用需要和多个业务服务接口和存储服务接口交互时，整体的开发工作量是很大的：

• 找适合该 AI 应用的业务接口和存储服务接口：

• 找三方服务接口。

• 在公司内部找合适的服务的接口。

• 找不到就自己先开发接口。

• 解析接口的返回格式：无论是三方服务接口还是公司内部的服务接口，返回格式可能都千奇百怪，需要逐一进行了解和解析。

直到 MCP 的出现，让我们看到真正解决 AI Agent 使用和管理工具复杂度的问题。

MCP 是模型上下文协议（Model Context Protocol）的简称，是一个开源协议，由 Anthropic（Claude 开发公司）开发，旨在让大型语言模型（LLM）能够以标准化的方式连接到外部数据源和工具。它就像 AI 应用的通用接口，帮助开发者构建更灵活、更具上下文感知能力的 AI 应用，而无需为每个 AI 模型和外部系统组合进行定制集成。MCP 被设计为一个通用接口，类似于 USB-C 端口，允许 LLM 应用以一致的方式连接到各种数据源和工具，如文件、数据库、API 等。

MCP目前一共有 3 个核心概念：

• MCP Server：

• 基于各语言的 MCP SDK 开发的程序或服务。

• 基于某种神秘的机制将现存的程序或服务进行了转换，使其成为了 MCP Server。

• MCP Tool：

• MCP Tool 所属于 MCP Server，一个 MCP Server 可以有多个 MCP Tool。可以理解为一个类里有多个方法，或者类似一个服务里有多个接口。

• MCP Client：当一段代码，一个 AI Agent，一个客户端，基于 MCP 的规范去使用、去调用 MCP Server 里的 MCP Tool 时，它就是 MCP Client。

MCP 的运作机制

要真正理解 MCP 是什么，我们需要了解它的运作机制，然后你就能知道 MCP 的调用方式和传统的 HTTP 调用方式有什么不同，可能也能隐约体会到为什么我说 MCP 可以让 AI Agent 进入第二阶段。

如上图所示，一次基于 MCP 的调用，一共有 6 个核心的步骤。我们先拟定一个前提：

• 我要开发一个获取时间的 AI Agent，用户在使用这个 AI Agent 时，只需要问类似“现在几点了？”这种问题即可。

• 我已经有了一个关于处理时间的 MCP Server，这个 MCP Server 里有 2 个 MCP Tool，一个负责获取当前时区，一个负责获取当前时间。

调用步骤解析：

• 第一步：用户向 AI Agent 问“现在几点了？”，此时 AI Agent 就是 MCP Client，它会把用户的问题和处理时间的 MCP Server 以及 MCP Tool 的信息一起发送给 LLM。

• 第二步：LLM 拿到信息后开始推理，基于用户的问题和 MCP Server 的信息，选出解决用户问题最合适的那个 MCP Server 和 MCP Tool，然后返回给 AI Agent（MCP Client）。

• 这里 LLM 返回给 AI Agent 的信息是：“你用 time 这个 MCP Server 里的 get_current_time 这个 MCP Tool 吧，它可以解决用户的问题”

• 第三步：AI Agent（MCP Client）现在知道该使用哪个 MCP Server 里的哪个 MCP Tool 了，直接调用那个 MCP Tool，获取结果。

• 调用 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 Client）再原封不动的返回给了用户。

在 MCP 的整个调用过程中有一个非常核心的点就是 MCP Server 以及 MCP Tool 的信息。从第一步，第二步可以看出，这个信息非常关键，是它让 LLM 知道了该如何解决用户的问题，这个信息就是 MCP 中最重要的 System Prompt，本质上就是 PE 工程。

MCP System Prompt

MCP 不像传统的协议定义，它没有一个确定的数据结构。它的核心是通过自然语言描述清楚有哪些 MCP Server，承担什么作用，有哪些 MCP Tool，承担什么作用，然后让大语言模型通过推理去选择最合适的 MCP Server 以及 MCP Tool。所以它的核心本质上还是提示词工程。

上面两张图是 Cline（一个 MCP Client）中的 System Prompt，可以清晰的看到它对 MCP Server 和 MCP Tool 都有明确的描述。

上图是流程中的第一步，将用户的问题和 System Prompt 一起发送给 LLM 的内容。

上图是流程中的第二步，LLM 返回了解决用户问题明确的 MCP Server 和 MCP Tool 信息。

MCP 和 Function Calling 之间的区别

看到这，我想大家应该对 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 需要 LLM 为每个外部函数编写一个 JSON Schema 格式的功能说明，精心设计一个提示词模版，才能提高 Function Calling 响应的准确率，如果一个需求涉及到几十个外部系统，那设计成本是巨大，产品化成本极高。而 MCP 统一了客户端和服务器的运行规范，并且要求 MCP 客户端和服务器之间，也统一按照某个既定的提示词模板进行通信，这样就能通过 MCP 加强全球开发者的协作，复用全球的开发成果。

MCP 的本质和挑战

根据上文的一些列解释，我们可以总结一下 MCP 的本质：模型上下文协议（Model Context Protocol）并不是一个确定的数据格式或数据结构，它是描述 MCP Server/MCP Tool 信息的系统提示词和 MCP Server 与 LLM 之间的协同关系的结合，解决的是找接口和解析接口的问题。

明确了 MCP 本质之后，将其带入到企业级生产应用中，你就会发现，这两个核心点上会有很多挑战，或者说不足。

描述 MCP 信息的系统提示词的挑战

• 系统提示词的安全性如何保证？

• 这个最核心的系统提示词如果被污染了，LLM 就不能准确知道你有哪些 MCP Server，有哪些 MCP Tool，甚至可能告诉 LLM 错误的，有安全漏洞的 MCP Server 和 MCP Tool，那么对你的AI应用来说将是巨大的风险，会导致整个 MCP 流程的瘫痪。

• 系统提示词如何管理？

• MCP Server 或者 MCP Tool 有了新版本，系统提示词应该也许要有对应的版本管理策略。

• 系统提示词写的不好，如何方便的快速调试？能不能实时生效？

• 系统提示词是没有标准定义的，理论上每个企业可以定义自己的系统提示词模板，类似 PE 工程。提示词不可能一次性就能写好，需要反复调试，需要有机制做快速的调整，并且可以做到使其实时生效。

• 如果MCP Server很多，那么系统提示词会非常长，岂不是很消耗Token？如何缩小或精确MCP Server和MCP Tool的范围？

• 如果你有几十个或更多 MCP Server，那么就有可能有上百个或更多 MCP Tool，所有的信息描述下来放在系统提示词后，这个提示词模板会非常大，显而易见的对 Token 消耗非常大，变相的就是成本高。应该需要一套机制，基于用户的问题，预圈选 MCP Server 和 MCP Tool 的范围，减少 Token，提高效率，很类似联网搜索里的意图识别。

AI Agent(MCP Client)与 MCP Server 之间协同关系的挑战

• 负责做协同的是 MCP Client，但目前 MCP Client 很少，比如 Cline， Claude，Cursor 等，而且都是 C/S 工具，支持的都是 SSE 协议，企业级的 AI 应用该如何结合？能不能结合？

• 基本上目前市面中的 MCP Client 都无法和企业级的AI应用做结合，SSE 这种有状态的协议有很多弊端，比如不支持可恢复性，服务器需要维持长期连接，仅支持服务器 → 客户端消息，无法灵活进行双向通信等。

• 现存的传统业务能快速转成 MCP Server 吗？能 0 代码改动的转换吗？

• 开发一个 MCP Server 是强依赖各语言的 MCP SDK 的，目前只支持 Python、Java、TS、Kotlin、C#。那如果是 Go 或者 PHP 技术栈的企业怎么办？并且那么多现存的业务全部用 MCP SDK 重构一遍，工作量巨大，也很不现实。

• MCP Server 会很多，如何统一管理？

• 有自己开发的 MCP Server，有三方的 MCP Server，还有大量通过某种神秘机制将传统业务转换而来的 MCP Server。这些都应该有一个类似 MCP Hub 或 MCP 市场的东西统一管理起来，方便 MCP Client 去使用。

• 企业级 AI 应用中，身份认证、数据权限、安全这些如何做？

• 在企业级的应用中，无论哪种协议，哪种架构，哪种业务。身份认证、数据权限、安全防护这些问题都是永远绕不开的。那么在 MCP 这种协同方式下如何实现。

Anthropic 对 MCP Registry 的官方定义：The MCP Registry service provides a centralized repository for MCP server entries. It allows discovery and management of various MCP implementations with their associated metadata, configurations, and capabilities.

从官方的定义中可以抽象出两个核心定义：

• 一个集中式管控的 MCP 服务仓库。

• 可以动态发现和管理 MCP 服务仓库中的各种 MCP 服务。

Anthropic 公布的 MCP Registry 的特性：

• RESTful API for managing MCP registry entries (list, get, create, update, delete)

• Health check endpoint for service monitoring

• Support for various environment configurations

• Graceful shutdown handling

• MongoDB and in-memory database support

• Comprehensive API documentation

• Pagination support for listing registry entries

我们还是将 AI Agent 类比为角色扮演游戏中的角色，目前绝大多数的游戏，无论哪种类型，都有自己的一套技能系统，只是复杂度的差别而已。既然是统一的技能系统，那么意味着无论是低阶技能还是高阶技能，玩家都是在同一个地方去查看技能，游戏角色都是在同一个地方去学习、升级、管理技能，我还没见过哪个游戏学习技能要去不同的地图，在不同的 NPC 处学习。

回到 MCP 范式，目前会有 2 个问题：

• 无论 MCP 服务复杂与否，都有自己的 Endpoint，如果你要对接 10 个 MCP 服务，需要配置 10 个 Endpoint，也就意味着你的 AI Agent 无法自动学习技能，并且学习技能的方式成本较高，维护成本也比较高。

• 你该去哪找你需要的 MCP 服务？有服务商自己发布在自己的平台的，有做 MCP 服务聚合市场的，还有企业内部的私有 MCP 服务市场。也就是 MCP 服务的来源繁杂，并且每个 MCP 服务都没有统一的管理方式，尤其是鉴权认证方式，所以进一步提升了 AI Agent 学习技能的复杂度，降低了 AI Agent 快速学习技能的可能性。

所以 Anthropic 定义了 MCP Registry，目的是就期望解决以上两个问题，从而让 AI Agent 在获取 MCP 时，只需要从一个地方找 MCP 服务即可。

从我们和 Anthropic MCP 团队的沟通交流来看，他们的野心是想构建一个类似 Maven 一样的大中心 MCP Registry。

但 Anthropic 在定义 MCP Registry 时又忽略了一些企业级的能力，所以这是需要 MSE Nacos 来补足的，也是 MSE Nacos 作为 MCP Registry 的核心优势。

MSE Nacos 3.0 MCP Registry 的优势

我们团队是中间件开源最多的团队，比如 Nacos，Higress，Sentinel，RocketMQ，Seata 等，并且还维护着 Spring Cloud Alibaba，Spring AI Alibaba，Dubbo 等这些开源开发框架，在微服务架构领域有着丰富的经验。所以在 MCP Server 和 MCP 提示词统一管理这个点上，天然的就想到了微服务领域里基于 Nacos 做服务注册发现和配置统一管理的模式，我们将其转嫁到了 MCP 范式，大家可以想一下以下这些对应关系：

• SpringCloud 服务/Dubbo 服务/Go 服务 -> 各类 MCP Server

• SpringCloud 服务/Dubbo 服务/Go 服务暴露的接口 -> 各类 MCP Server 提供的 MCP Tool

• SpringCloud 服务/Dubbo 服务/Go 服务暴露的接口描述 -> 各类 MCP Server提供的 MCP Tool 的描述

• SpringCloud 服务/Dubbo 服务/Go 服务的配置文件 -> 各类 MCP Server 的系统提示词

我们拿 MSE Nacos 现有的的功能和 Anthropic 对 MCP Registry 的定义做一下对照：

• MSE Nacos 本身支持完善的 OpenAPI，可对注册在 MSE Nacos 中的服务做增删改查等操作。

• MSE Nacos 支持服务健康检查，上下线状态检查。

• MSE Nacos 作为微服务架构中首选的配置中心，有完善的服务配置相关功能。

• MSE Nacos 支持服务推空保护。

• MSE Nacos 底层基于 Mysql 存储。

MSE Nacos 的现有能力 和 Anthropic 对 MCP Registry 的定义几乎完全一致。除此以外，MSE Nacos 作为 MCP Registry 还有其他更贴近企业级的增量价值：

• 现有功能：

• MCP Server/Tool Prompt 安全管理。

• 集合KMS做加密管理。

• MCP Server/Tool Prompt 多种发布方式。

• 全量发布、基于 IP 灰度发布、基于标签灰度发布。

• MCP Server/Tool Prompt 多版本管理。

• 历史版本查看，版本对比，回滚。

• MCP Registry 整体可观测。

• MCP Registry 安全管控。

• 实例级别鉴权，命名空间级别鉴权。

• 规划中的功能：

• MCP Server/Tool Prompt 安全性校验。

• MCP Server/Tool Prompt 调试功能。

• MCP Server/Tool Prompt 准确度校验体系。

所以在 MSE Nacos 这个产品中，我们做了一系列增强 MCP 的能力，使 MSE Nacos 成为统一管理 MCP Server 的 MCP Register（MCP Server 注册/配置中心），是 AI Agent 技能池的的核心组件。

MSE Nacos 3.0 定义 MCP Registry 超集（企业级 MCP Registry）

Anthropic 对 MCP Registry 虽然有标准，但目前核心只关注在统一公共数据源和定义 MCP 服务元数据规范这两点。官方也明确了有一些问题是不会去解决的，比如：

• 私有化 MCP Registry。

• 基于 MCP 服务名称以外的高级检索能力。

• MCP 服务 Prompt 的安全管控问题。

所以 MSE Nacos 3.0 带来的 MCP Registry 是官方 MCPRegistry 的一个超集，除了兼容官方定义的 MCP 元数据格式、和 API 外，MSE Nacos 3.0 同时提供了结合AI网关，HTTP 转换 MCP 的能力，结合阿里云 KMS 提供 MCP 服务敏感数据加密的能力，同时结合目前开源的 Nacos router 也可以实现智能路由检索的能力，解决多 MCP 服务检索 token 消耗量大的问题。

AI 网关 + MSE Nacos MCP Registry 构建 AI Agent 技能池的优势

• MSE Nacos 作为 MCP Registry 可对 MCP 服务统一安全管理：

• 传统服务转换 MCP 服务，原生 MCP 服务都可以在一个地方闭环管理。

• MCP 服务工具的 Prompt 具备版本管理和加密管理。

• MCP Registry 自身具备高性能、高稳定性。（被社区，各类外部企业，阿里集团各业务充分验证和打磨）

• AI 网关统一代理 MCP 服务增强 MCP 服务的管控和扩展：

• 针对 MCP 服务配置策略，或通过插件机制配置贴合业务的策略。比如限流降级、各类型的鉴权认证等。

• 使 MCP 服务同时支持 SSE 和 Streamable HTTP 两种传输协议。降低 AI Agent 与 MCP 服务交互的开发成本。（可无需单独开发支持 SSE 的方式）

• 针对 MCP 服务的工具粒度，重新组装 MCP 服务。你可以让一个重新组装后的 MCP 服务（一个 Endpoint）包含所有各种类型的工具，比如将高德 MCP 服务和企业内部 HTTP 服务转换的 MCP 服务的能力在AI网关层面聚合在一个 MCP 服务里，这样对 AI Agent 来说，只需要配置一个 MCP 服务的 Endpoint，就可以获取到各类型的 MCP 服务工具（消费者授权范围内的）。当然你可以按照不同的领域来组装 MCP 服务，类似前后端分离的BFF的逻辑。这样你就可以灵活构建你的 AI Agent 技能池系统。

通过这种方式构建的技能池，当需要 AI Agent 学习新技能时，不需要 AI Agent 做任何改动，你只需要在 MSE Nacos 中创建新的 MCP 服务，通过 AI 网关同步，编辑组装后的逻辑 MCP 服务，添加新的工具，然后向 AI Agent 对应的消费者里增加新工具的授权。然后你的 AI Agent 就自动学会了新的技能。

Streamable HTTP 的优势

MCP 范式默认的传输协议是 SSE（Server Sent Event），本质上是一种长连接，有状态的传输协议。这种协议在企业级应用中有很多弊端：

• 不支持可恢复性（Resumability）：连接断开后，客户端必须重新开始整个会话。

• 服务器需要维持长期连接（High Availability Requirement）：服务器必须保持高可用性，以支持持续的 SSE 连接。

• SSE 仅支持服务器 → 客户端消息，无法灵活进行双向通信。

• 目前只有少数几个 C/S 架构的客户端和 MCP 提供的用于测试验证的 Web 客户端支持 MCP 范式和 SSE 协议。无法用在企业级的生产应用中。

好在 MCP 官方也意识到了该问题，所以在 3 月下旬，发布了新的 Streamable HTTP 协议。Streamable HTTP 改变了 MCP 的数据传输方式，让协议变得更灵活、更易用、更兼容：

• 更灵活：支持流式传输，但不强制。

• 更易用：支持无状态服务器。

• 更兼容：适用于标准 HTTP 基础设施。

简单来说，原来的 MCP 传输方式就像是你和客服通话时必须一直保持在线（SSE 需要长连接），而新的方式更像是你随时可以发消息，然后等回复（普通 HTTP 请求，但可以流式传输）。

这里大家可以思考一下：

• Streamable HTTP 打破了目前几个 C 端 MCP Client 的壁垒。也就意味着任何请求方（甚至就是一段简单的 HTTP Request 代码），都可以像请求标准 HTTP API 的方式一样和 MCP Server 交互。

• 换句话说，当可以使用标准 HTTP API 的方式和 MCP Server 交互后，是不是就不存在所谓的 MCP Client 了？

所以 Streamable HTTP 传输协议是 MCP 服务赋能 AI Agent 的基石。而在上文中，大家应该不难发现，无论是 AI 网关直接转换，还是基于 MSE Nacos MCP Registry 转换，都是支持 Streamable HTTP 的，甚至可以让一个不支持 Streamable HTTP 传输协议的三方 MCP 服务具备 Streamable HTTP 的能力。

对 MCP 服务做灵活的策略管控

AI 网关侧对 MCP 服务的代理，无论是原生 MCP 服务的代理，还是 HTTP 服务转换而来的 MCP 服务，都可以复用 AI 网关内核的插件机制，可以对 MCP 服务灵活的设置预置策略或插件，如果有更贴近业务的需求，还可以开发自定义插件来实现。通常企业会使用插件机制实现 MCP 服务的限流降级，一方面做后端服务安全保障，另一方面是实现 MCP 服务的成本管控（三方原生 MCP 服务）。

MCP 范式下的身份认证和权限管控

身份认证和权限管控在任何架构，任何业务场景下都是刚需，在 MCP 范式下也不例外，这里有三个层面的权限管控：

• AI Agent（Client）有权使用哪些 MCP 服务。有权使用某 MCP 服务里的哪些工具。

• AI Agent（Client）调用 MCP 工具时，MCP 服务的鉴权认证。

• AI Agent（Client）调用 MCP 工具时，通过 MCP 服务鉴权认证后，进一步的的数据权限。

大家设想一下，当传统业务可以 0 代码转换为 MCP 服务后，注册在 Nacos 中的 MCP 服务和工具肯定会有很多，从业务领域来说，可能有和财务相关的 MCP 服务，有和销售相关的 MCP 服务，有和售后服务相关的 MCP 服务。在返回 MCP 服务和工具信息时不可能将所有信息都返回，肯定只能返回 AI Agent（Client）身份有权使用的 MCP 服务信息。

目前 MCP 服务和工具的数量管控，主要通过AI网关的消费者认证体系来实现，每个消费者可以授权 MCP 服务及工具，然后将消费者分配给某 AI Agent（既 AI Agent 从 AI 网关请求 MCP 服务信息时 Header 里需要带着消费者的 API Key），那么该 AI Agent 能获取到哪些 MCP 服务和工具的信息就可以被灵活的管控和配置了。

MCP 服务自身的鉴权认证同样分原生 MCP 服务和 HTTP 服务转 MCP 服务两种类型来说：

• 原生 MCP 服务：官方定义的 MCP 服务认证方式是 Header 里传 API Key 的方式，目前市面上绝大部分三方原生 MCP 服务的鉴权认证都支持的是这种方式。但也有少数三方 MCP 支持的是 URL 的参数中传 Key 的方式，比如高德 MCP 服务。

• AI 网关和 MSE Nacos MCP Registry 都支持。

• HTTP 服务转 MCP 服务：这种类型的 MCP 服务的鉴权认证方式取决于传统 HTTP 服务的鉴权方式，比如 API Key，JWT，HMAC，OAuth2.0 等。

• 如果是 API Key 的方式，AI 网关和 MSE Nacos MCP Registry 都支持。

• 如果是非 API Key 的方式，可以通过 AI 网关的各类认证插件来实现。

当 MCP 服务是数据类服务时会比较常见，比如 Mysql MCP Server，Redis MCP Server 等。权限会下探到库级别，表级别。在这种场景下，AI 网关可以通过插件机制，改写或增加 Request Header 的值，结合 MSE 治理将 Header 的值透传下去，然后在服务内部进一步做数据权限管控。

我举例一个通过这种方式实现的数据库读写分离的场景：

Anthropic 提供了各编程语言的 MCP SDK，目前支持 C#，Java，Kotlin，Python，Ruby，Swift，TypeScript 这 7 种语言。如果是一个初创公司，没有基础服务的积累，那么使用 MCP SDK 开发新的 MCP 服务是合理的。但是如果是一个存在了几年甚至十几年的公司，已经积累了很多业务服务，希望这些业务服务的能力能作为 AI Agent 的左膀右臂，那么使用 MCP SDK 将这么多的存量业务重新开发一遍，显然是不可能的，况且 MCP SDK 现在还没有支持 Go 语言。

所以 MCP 服务的类型，从构建的角度，可以分为两类：

• 原生 MCP 服务：即使用 MCP SDK 新开发的 MCP 服务。

• HTTP 转 MCP 服务：既通过各种方式，将存量的传统服务转换为 MCP 服务。

基于函数计算 FC 构建原生 MCP 服务

众所周知，AI Agent 里涉及到 LLM 推理的场景，相比传统业务，其实是相对稀疏调用的场景。所以这里可以延伸出两个问题：

• 在稀疏调用的场景下，运行 MCP 服务的计算资源如何优化资源利用率，说的再直白一些就是如何能做到成本最优。

• 在新的业务中，如何快速构建 MCP 服务。

在所有的计算产品中，函数计算 FC 这种 Serverless FaaS 类型的计算产品，在资源粒度、弹性策略、弹性效率方面都是最适合稀疏调用场景的。和上文中作为 AI Agent 的运行时的逻辑是一致的。

函数计算 FC 目前支持了 Python、NodeJS 和 Java 三种语言的 MCP 运行环境（其他语言的 MCP 运行环境也马上会支持）。用户选择 MCP 运行环境创建函数后，只需要编写 MCP 工具的业务逻辑即可，不需要考虑如何使用 MCP SDK。并且 AI 网关和函数计算 FC 有深度集成，可以天然适配 AI Agent 开发的新范式。

阿里云百炼平台的 MCP 服务，底层运行时使用的就是函数计算 FC。

在 FunctionAI 的项目中，可以直接创建 MCP 服务。

这里创建的 MCP 服务底层就是基于函数计算 FC 实现的，所以除了 MCP 需要的传输协议类型、认证、语言（目前支持 Java、Python、NodeJS）外，还可以灵活的设置运行该 MCP 服务的资源规格大小，以及弹性策略、网络配置等。

创建好 MCP 服务后，我们只需要填写业务代码即可。

函数计算 FC 构建 MCP 服务的成本优势

基于函数计算 FC 构建的 MCP 服务在弹性效率方面可以从两个维度来看：

• 资源规格细粒度管控。

• 完全按请求弹性。

函数计算 FC 的实例规格从 0.05C 128MB 到 16C 32GB 不等（也可以支持更大的规格），有几十种规格的组合方式，可以灵活根据不同 MCP 服务承载的业务选择合适的资源规格。另外，在 AI 应用中，尤其是流程式构建的模式中，除了带有 Palnning 的 AI Agent 外，大多数 AI Agent 的职责都相对单一，计算逻辑都不复杂，所以都可以用较小资源规格的函数承载。资源规格小，在资源调度，弹性效率方面自然就会有优势。

再看函数计算 FC 的弹性机制，它是完全按照请求弹性的，有多少 QPS，就拉起对应数量的实例，并且实例可以复用，当 QPS 降下来后，空闲的实例会自动释放，整个过程完全不需要用户介入参与。在默认按请求弹性的基础上，用户还可以自行设置按照时间定时弹，或按照指标阈值扩容的策略，进一步满足复杂多变的业务场景，做到资源成本最优。

除此以外，Serverless 计算产品，不需要用户关注底层 IaaS 资源，几乎没有运维的接入，由研发就可以快速创建函数拉起资源做业务开发和测试，所以大幅度提升了研发运维的效率，映射到成本方面，虽然不好量化，但是人力成本，时间成本也是不容忽视的。

函数计算 FC 构建 MCP 服务的可观测体系

函数计算 FC 有完善的可观测体系，也就意味着，基于函数计算 FC 构建的 MCP 服务同样具备指标、链路、日志三个维度的可观测能力。

通过这套可观测体系，用户可以清晰地了解每个 MCP 服务的各类运行状态。

HTTP 服务转 MCP 服务

在这段时间我们和企业客户的交流来看，几乎所有的企业都认为最有价值的是使用 AI 增强、提升现存业务，使其变成一个 AI 应用或 AI 加持的业务，而不是完全新开发一套 AI 应用。所以开发一个 AI 应用或者做现存业务的 AI 增强，AI Agent 是需要和大量现存业务做交互的，MCP 虽然是统一的协议，但将现存业务重构为 MCP 服务的成本是非常高的，并且目前支持的开发语言有限，像 Go，PHP 都没有对应的 MCP SDK，所以会让很多企业想拥抱 MCP，但又无从下手。

网关最擅长做的事情就是协议转换，所以 AI 网关的第二个核心功能就是 MCP 服务管理，包括：

• 代理原生 MCP 服务。

• HTTP 服务转 MCP 服务。

• AI 网关直接转换。

• 由 MSE Nacos MCP Reristry 转换，AI 网关动态发现。

• MCP 服务能力组装。

在这个章节，我们主要讨论如何将普通的 HTTP 服务 0 代码改造的转为 MCP 服务，这种转换有两种方式。

AI 网关直接转换

AI 网关支持所有主流的服务来源发现方式，可以将部署在各种计算资源上的传统服务接入进 AI 网关：

• 容器服务：AI 网关和 ACK 做了深度集成，直接选择 ACK 中对应 Namespace 下的 Service 即可。

• Serverless 应用引擎 SAE：AI 网关和 SAE 做了深度集成，直接选择 SAE 中对应 Namespace 下的 Service 即可。

• 函数计算 FC：AI 网关和 FC 做了深度集成，直接选择对应别名/版本的函数即可。

• 固定 IP：适用于接入部署在 ECS，IDC 服务器上的服务。

• DNS 域名：适用于企业使用域名方式请求服务的场景，比如企业的自定义域名解析到了 ECS ID，或者 IDC 服务 IP，或者是一个三方提供的服务地址。

• MSE Nacos：AI 网关和 MSE Nacos 做了深度集成，直接选择 Nacos 中对应 Namespace 下的服务即可。

当后端服务接入 AI 网关后，便可以在 MCP 管理中创建 MCP 服务，选择接入的后端服务。

创建好 MCP 服务后，因为普通服务中有的是各个接口或方法，没有工具的概念，所以第二步是需要对该 MCP 服务创建工具，也就是将该 MCP 服务的工具和代理的普通服务的接口做映射关系。

• 编辑方式：目前支持手动编写 Yaml 文件和上传 Swagger 文件两种方式。

• 上传 Swagger 后会自动生成 Yaml，但是质量取决于 Swagger 文件内容的质量，所以通常还需要人工校验。

• 后端服务认证：我们代理的后端服务需要认证是很常见的事，目前我们提供 API Key，Basic，Bearer 三种方式。

• Yaml 规范：Yaml 里描述的信息本质就是将普通服务的接口和接口需要的参数都映射为 MCP 服务中的工具，将接口和入参的作用描述清楚，这个就是上文中解释 MCP 机制里的 MCP 工具提示词。

• Yaml 规范的详细说明参见：https://higress.cn/ai/mcp-server/

配置好工具后，这个 MCP 服务其实就已经是可用状态了，用户可以通过调试功能对该 MCP 服务做测试。AI 网关负责做普通服务接口和 MCP 服务工具映射关系的协同和转换，并且同时提供 SSE 和 Streamable HTTP 两种传输协议。

除此以外，用户可以基于业务需求对该 MCP 服务添加更丰富的插件和策略，比如对 MCP 服务做限流降级保护、设置超时策略、设置 IP 黑白名单、数据脱敏等等。如果我们预置的策略和插件依然不满足用户需求，那么用户可以开发自定义插件上传到 AI 网关使用。所以，整体灵活性和可扩展性是非常强的。

从整个流程大家应该不难看出，通过AI网关将一个传统的现存服务转换为 MCP 服务不需要修改任何业务代码，只需要在控制台白屏化的操作即可，唯一的工作量就是编写接口和工具映射的那个 Yaml 文件。针对这一唯一工作量，我们也还在持续探索，找到更好的帮用户自动生成 Yaml 的方案。

由 MSE Nacos MCP Reristry 转换，AI 网关动态发现

另一种更加推荐的企业级 HTTP 服务转换 MCP 服务的方式是引入 MSE Nacos 作为 MCP Registry，无论是原生 MCP 服务还是普通服务，都由 MSE Nacos 作为 MCP 注册中心统一管理。普通服务和 MCP 服务之间的映射关系由 MSE Nacos 完成，AI 网关和 MSE Nacos 深度集成，动态发现注册在 MSE Nacos 中的 MCP 服务，然后代理暴露出去。

将服务注册进 Nacos 有两种方式：

• 使用 Nacos SDK 实现自动注册：这种方式在微服务时代应该是家喻户晓的方式，支持 Java、Python、Go。

• 在我们交流的过程中，有很多 Java 微服务体系的企业，本身服务就注册在 Nacos 中，相当于天然就具备一个 MCP 服务技能池，只需要简单的转换即可。

• 通过 DNS 域名或 IP 手动注册：这种方式适合非 Java 微服务体系，或者之前也没有使用 Nacos 作为注册中心的场景，或者使用像函数计算 FC 这种 Serverless 计算产品部署的服务。

我们来看看白屏化手动注册的方式，相对比较直观。注册服务这部分和之前使用 Nacos 的方式一样，创建服务，然后在服务中创建实例。

注意：上图的 IP 字段可以填写 IP，也可以填写域名。

后端服务注册好之后，在 MCP Registry 功能中创建 MCP 服务，这里同样支持 HTTP 服务转 MCP 服务，和直接创建原生 MCP 服务。

选择 HTTP 转化 MCP 服务后，展现出来的基本信息和使用 AI 网关比较类似，MCP 服务的核心元素都一样，但唯一的一个区别是多了服务版本，这就是上文中我说的企业级的特性之一。

然后是给该 MCP 服务添加工具，工具和参数的基本信息做了白屏化的配置方式，工具和后端服务接口的映射关系（requestTemplate）配置还是黑屏化的方式，如上图所示。

至此一个简单的 MCP 服务在 MSE Nacos MCP Registry 中就创建完成了，我们可以回到 Nacos 的配置管理/配置列表模块，可以看到每个 MCP 服务都有三个对应的配置信息。

Nacos 作为主流的注册配置中心，配置信息是支持加密的，所以这也就意味着 MCP 服务工具的 Prompt 也都是加密存储的，这也企业级的特性之一。

在我们和企业客户的交流过程中，几乎和所有的客户都能达成一个一致的观点，那就是在 MCP 范式下，发布一个 MCP 服务的新版本，不一定要修改该 MCP 服务后端服务的代码，而大概率只需要调整 MCP 服务工具的描述（Prompt）即可，因为同一个 MCP 服务工具的同一个参数，修改了描述后，对于 LLM 来说，可能就已经变成了服务于另一个领域的 MCP 工具了。并且在我们协助客户的落地过程中，调整测试 MCP 服务工具的描述（Prompt）本质上就是一个 PE 工程，所以 MCP 服务的版本管理至关重要。

我们编辑刚才创建的 MCP 服务，修改其版本号。

然后修改工具参数的描述，将“风控根据项目 wbs 查询开工项目信息，成本跟踪人员信息”，改为“风控根据项目 orderId 查询开工项目信息,成本跟踪人员信息”。

此时，该 MCP 服务就出现了多个版本，可以灵活切换不同的版本。无论是做 MCP 服务的灰度，还是在调试测试阶段都是非常有用的。

MSE Nacos 作为 MCP Registry 的核心能力是 MCP 服务的统一管理，包括 MCP 服务版本管理和工具 Prompt 加密管理，对外暴露 MCP 服务和针对 MCP 服务添加策略/插件、消费者认证等还是需要通过 AI 网关，所以 AI 网关和 MSE Nacos 做了深度集成来实现这一企业级的链路。

首先在 AI 网关中，需要将 MSE Nacos 对应实例作为服务来源。

然后在 MCP 管理模块中，同步 Nacos MCP 服务。

在 MCP 管理列表中会有明确的标识，方便用户识别每个 MCP 服务的构建方式。

AI 网关中，从 MSE Nacos MCP Retistry 动态发现的 MCP 服务，同样可以对其设置各类策略和配置各种插件、支持 SSE/Streamable HTTP 两种传输协议、消费者认证、查看日志等功能。

构建 MCP 服务总结

综上所述，构建 MCP 服务有两种方式：

• 基于 MCP SDK 开发原生 MCP 服务。

• 适用场景：初创公司，完全独立的新业务，相对简单、逻辑单一的服务。

• 推荐方式：使用 FunctionAI 平台，基于函数计算 FC 构建原生 MCP 服务。

• 弊端：

• MCP SDK 支持的语言不全。

• 成熟公司不会花费大量时间重构现存业务。

• 工具 Prompt 写在代码里不便管理（版本管理、安全管理等）。

• HTTP 服务现存服务转换为 MCP 服务。

• 适用场景：绝大多数公司，对现存业务做AI赋能，将现存业务作为 AI Agent 技能池。

• 推荐方式：AI 网关 + MSE Nacos MCP Registry

• 优势：

• 0 代码改造转换传统 HTTP 服务。

• 各类 MCP 服务可以一个地方集中管理。

• MCP 服务实现版本管理。

• MCP 工具 Prompt 实现加密管理。

• 使用 Java 微服务架构或原本就使用 Nacos 的用户，上手成本极低。

在 AI 时代，随着模型和应用侧的快速演化，对于推理过程，成本和性能显得尤为重要，而端到端的 AI 可观测是其中至关重要的一环，下一篇，我们会聊聊 AI 应用可观测体系的建设。