第 5 章：AI 工具

本章系统梳理了 AI 工具在智能应用中的关键角色，深入解析 Function Calling 的局限、MCP 协议的优势与挑战，并总结 AI 工具标准化与工程实践路径，助力构建可扩展、可治理的智能应用生态。

AI 工具简介

大模型虽然越来越聪明，但是缺少工具向物理世界进行延伸，它对物理世界既不可读也不可写。因此，业界才通过工具调用（Function Calling）、检索增强（RAG）、以及具备计划与执行能力的代理式工作流（Workflow）来弥补模型与现实世界之间的鸿沟，把智能从会说推进到能做。

从原理上看，通用大模型善于在给定上下文中生成连贯文本，但它并不具备内建的 I/O 与状态管理，也无法直接访问数据库、API、知识库或执行系统命令。为了让模型“办成事”，我们通常要让它做三件事：通过 RAG 读取外部知识、通过工具调用触发外部动作、通过代理式规划协调多步流程。这些机制把世界的读写权以受控的方式暴露给模型，让其在安全边界内发挥效能。

然而，Function Calling 方案在工程落地上暴露出大量痛点，阻碍了规模化与治理化的推进。随着 MCP（Model Context Protocol）协议的提出并迅速获得关注，行业看到了以通用协议重塑模型&外部能力接口层的可能。

Function Calling

Function Calling（函数调用）是一种允许 LLM 根据用户输入识别它需要的工具并决定何时调用该工具的机制。

下图展示了一轮完整的 Function Calling 流程：

如下是阿里云百炼平台 Function Calling 的方法：

从上面步骤中可以看出来，Function Calling 使用起来非常不方便，需要编写代码，因为是自定义的调用方式，因此很难在不同的平台复用。

总结来说，Function Calling 存在如下 4 部分问题：

• 规格碎片化。不同厂商对工具的描述方式、类型系统与 JSON Schema 兼容度、调用时序、错误语义、流式行为都各不相同。即使是类似的功能，在 A 厂商上表现为同步调用、在 B 厂商上却需要异步轮询；有的支持严格校验与参数默认值，有的则完全凭提示工程“约法三章”。这使跨厂商、跨模型的适配成本居高不下。

• 可靠性挑战。模型常常会错误地选择工具或以错误顺序调用。即便选对了工具，也可能生成不满足约束的参数，出现结构缺失、类型错误、边界值越界，甚至编造参数。多步或并行调用尤为脆弱：中途失败无法优雅回滚，调用结果彼此覆盖，流式响应时序相互干扰，最终让上层业务出现不可预测的行为。

• 工程治理缺位。大多数团队缺少集中式的工具目录与自描述元数据，更谈不上版本与依赖管理、权限分级、调用审计、成本归集。工具的定义散落在各个微服务与提示模板里，难以复用、难以维护、无法衡量 ROI，也难以符合企业的合规与安全要求。

• 厂商锁定与迁移成本高。由于工具适配逻辑深度绑定在某一家模型供应商的接口与语义上，想要在多模型、多云之间切换就需要重复实现同一套工具封装，迁移周期长、风险大，阻碍了

“按需选模、按价择模”的策略。

MCP

MCP（Model Context Protocol）协议由 Anthropic 于 2024 年提出，旨在为 AI 助手与数据系统之间建立统一的开放标准。

下图展示了 MCP 协议的核心理念：

图片来源： Sequoia Capital - ai-ascent-2025

MCP 的核心理念是把模型可用的上下文与外部能力协议化，形成独立于模型供应商的标准接口层。它把工具（Tools）、资源（Resources/用于检索与长上下文读写）、提示（Prompts）、会话（Sessions）、取样/推理（Sampling）等能力统一纳入协议语义，并标准化“枚举 - 描述 - 请求 - 响应 - 权限 - 审计”的全链路。传输层上，MCP 不限定具体载体，既可通过 HTTP/WebSocket，也可通过 stdio 等方式交换消息，使之既能嵌入云端推理服务，也能运行在本地或边缘环境。

MCP 可以看作是 AI 应用程序的"USB- C 端口"。就像 USB- C 为连接设备与各种外设提供了标准化方式，MCP 为 AI 模型连接不同数据源和工具提供了标准化方法。

MCP 就足够了吗？

MCP 的价值在于用统一协议取代碎片化集成，把大模型获取外部数据与工具的方式从 N\times N 适配转为“一次对接、处处可用”，显著简化并提升可靠性。它定义了代理可用的工具与上下文提供机制，既可本地运行也可通过远程服务器在云端共享能力，适合规模化分发与复用。MCP 在这个过程中定义了标准的协议，并且得到了业界的认可，我们看到大量的生态在短时间内支持了 MCP 协议，诸如 Cursor、Windsurf、Cline 等已开始引入 MCP，带动开发者与经典在线应用联动，甚至出现如 BlenderMCP 这类将自然语言接入专业软件的场景，在这种趋势下，MCP 网关也如雨后春笋般出现，随着 MCP 相关的基础组件的出现与完善，MCP 被视为潜在的“AI 原生基础设施”。

当然归根结底来说，无论是 RAG、FunctionCall 还是 MCP，其实都是为了让模型获取更多知识、调用更多工具来完成更复杂的事情。从技术演进看，MCP 承接了 RAG 与 FunctionCall 的路径，主打跨模型兼容与统一标准，尽管仍处早期，但具备形成事实标准的“滚雪球”机会。同时，MCP 也被比喻为“AI 扩展坞”，通过协议化自描述终结工具调用碎片化，降低对接复杂度。

但 MCP 不是“万能药”，其普及仍取决于生态成熟度、落地实用性与产业响应，短期内存在不确定性与不同声音，且国内是否成为事实标准亦未定。不少批评者指出，仅有协议难以补齐当前模型与 Agent 的能力与可靠性缺口，推广仍需时间验证与配套工程实践。随着远程 MCP 服务器在云上共享工具，安全与治理（身份、授权、审计）要作为一等公民纳入平台设计，而不仅是通信层面的规范。尽管 MCP 在密钥暴露最小化、访问校验与传输加密等方面具备先天优势，真正安全可控仍依赖平台级策略与治理体系完善落地。

因此，更现实的结论是：以 MCP 为协议底座，叠加 AI 工具接入的最佳实践与企业级安全治理，才能把“可接入”变成“可规模、可移植、可审计”的 Agent 能力。

AI 工具标准化

登高而招，臂非加长也，而见者远。

登高而招，臂非加长也，而见者远。在 AI 工具篇章的首节对 MCP 协议的技术定位与生态价值进行全景式剖析后，我们已然认识到这一协议在重塑 AI 应用架构中的战略意义。然而，任何技术标准的真正生命力都需在工程实践中验证。本节将从协议架构的微观实现出发，深入探讨 MCP 在工程化落地中的核心优势、现实困境及其破局之道。

MCP 协议介绍

MCP（Model Context Protocol，模型上下文协议，下文中简称 MCP）是一个开放协议，旨在为模型服务提供标准化的接口，使其能够连接外部数据源和工具。

下图展示了 MCP 架构的主要组成部分：

MCP 协议采用 JSON-RPC 2.0 作为通信规范，所有消息均使用 JSON 格式进行序列化，确保跨语言和跨平台的兼容性。

下图为获取工具列表的请求和响应示例：

下图为 AI 应用程序与 MCP Server 交互的整体流程：

协议初始化：AI 应用程序启用 MCPClient，MCPClient 向 MCPServer 发起初始化请求，附带 MCP 协议版本和基础上下文等信息。MCPServer 返回初始化响应，包含 MCPServer 名称、版本以及功能概览。

能力发现：MCPClient 查询 MCPServer 的工具/资源文件/提示词模板列表，不同类型的标准方法如下：

• tools/list：获取可调用的工具列表；- resources/list：获取可用的资源列表；- prompts/list：获取可用的提示词模版列表。

功能调用：MCPClient 根据业务需要动态请求工具调用/资源文件/提示词模版，MCPServer 返回具体的响应内容。

• 会话终止：交互完成后，MCPClient 和 MCPServer 均可以主动关闭连接。

MCP 的核心优势

MCP 重新定义了模型与外部世界的交互方式，解决了 AI 应用开发中模型与工具结合所面临的诸多痛点，它的核心优势主要体现在以下几个方面。

标准化模型与工具的连接方式

MCP 为模型与外部数据源、服务之间提供了标准的通信方式，它就像 AI 领域的“USB- C”，模型可通过 MCP 协议适配多种工具。Function Calling 虽然实现了工具调用从手动到自动化的跃迁，但它需要用户为不同模型和服务开发适配逻辑的工作，开发和维护的成本较高。MCP 定义了统一的通信规范和数据格式，用户只需遵循 MCP 协议定义接口，就可以让模型与外部世界通信。这种标准化解耦了模型与工具开发，让开发人员更专注于工具本身的能力，降低了运维复杂度。

灵活的资源调度方式

MCP 支持 STDIO、SSE、StreamableHTTP 三种连接模式，STDIO 可通过进程间通信访问本地的文件系统、数据库等资源，而 SSE、StreamableHTTP 能够支持对远程服务的调用。一个 AI 应用程序可以同时使用本地和远程两种方式调用工具，这种灵活性使得 AI 应用程序能够在分布式环境中自由、按需的调度资源，实现跨网络的数据交互。

支持双向、异步通信

MCP 协议能够实现双向交互的能力，AI 应用程序可同时作为 MCP 客户端和 MCP 服务端，既能主动访问外部的 MCP 服务，又能将自身的能力封装为 MCP 服务供其他客户端使用。MCP 也

支持异步通信模式，MCP 客户端在请求完成后可不用等待服务端的响应，当任务完成后由服务端主动推送异步事件，这种设计能够适配一些处理耗时较长的复杂任务，如视频解析等。

支持能力共享

MCP 协议能够实现双向交互的能力，AI 应用程序可同时作为 MCP 客户端和 MCP 服务端，既能主动访问外部的 MCP 服务，又能将自身的能力封装为 MCP 服务供其他客户端使用。MCP 也支持异步通信模式，MCP 客户端在请求完成后可不用等待服务端的响应，当任务完成后由服务端主动推送异步事件，这种设计能够适配一些处理耗时较长的复杂任务，如视频解析等。

构建方式便捷

MCP 服务本身是一个轻量程序，开发门槛低，社区提供了像 MCP-Framework、Spring AI MCP 等 MCP 开发框架，简化了用户开发流程，如果结合 AIDE 等工具，可进一步提高开发效率。将一个已有的服务升级为 MCP 服务所需的政治也非常小，通过 Higress 网关与 Nacos 等中间件，存量应用可以在不修改代码的前提下被封装为 MCP 服务，只需配置工具描述、参数定义等元信息即可。

MCP 面临的挑战

尽管 MCP 在技术愿景和生态共建上展现出巨大潜力，但企业在实际落地 MCP 应用的过程中也遇到了诸多问题。

安全问题

MCP 协议的身份认证体系尚不完善，虽然官方已引入了基于 OAuth2.1 的授权方案，提升了协议的安全性，但 Qauth 授权流程仍依赖开发者自行实现，且不同语言对 Qauth 功能的支持也存在差异，这无疑增大了开发复杂度和集成门槛。此外，提示词注入和工具投毒攻击等都是 MCP 服务中常见的高危风险，MCP 将大量系统提示词、工具描述等上下文信息直接添加到模型输入中，而模型本身无法识别信息的合法性，因此无法感知到上下文是否被恶意墓改。攻击者可利用这个漏洞，在工具的描述信息或返回数据中嵌入恶意指令，诱导模型执行非预期行为。

大规模应用问题

当 MCP 服务或工具的数量过多时，模型可能会出现选择困难症，因为大量的上下文输入让模型难以区分和回忆每个工具的能力，也就无法有效的选择与目标问题关联度最高的工具。而且，由于模型在每次对话中都需要接收全量的工具描述信息，对话内容很容易超出模型支持的上下文窗口的长度限制。更关键的是，过长的提示词信息也会加剧 Token 的消耗速度，尤其是在多轮对话中，工具列表被重复传递，造成 Token 资源的浪费，拉高调用成本。

集中管理问题

集中管理问题 MCP 的通用性使得开放、共享 MCP 服务变得流行，用户通常会同时使用来自于不同平台的 MCP 服务，这种共享模式促进了 MCP 生态的发展，让开发人员避免了重复造轮子，但也带来了不少管理难题。不同平台 MCP 服务的管理方式不统一，调用关系错综复杂，人工维护、治理成本非常高，而且全局视角下的可观测能力、统一的计量计费能力等均因为跨平台问题而难以实现。

可行的解决方案

1、AI 网关解决 MCP 安全问题

下图展示了 AI 网关在 MCP 安全防护中的作用：

阿里云 A1 网关提供的 AI 网关能力支持 MCP 服务的流量代理，且能够在零代码改造的基础上将已有的 HTTP 服务转化为 MCP 服务。所有流经 MCP 服务的请求均由 AI 网关统一接入和处理，安全防护、流量管理、可观测等能力全部收敛在网关侧，让开发者能够专注于核心业务逻辑的实现。

在身份认证方面，AI 网关提供细粒度的消费者鉴权功能，网关会验证所有请求的合法性，它支持 APIKey、JWT 等多种业界标准的认证方式，实现了从 MCP 服务到具体工具级别的权限控制。管理员可以为调用方分配专属的消费者凭证，结合网关的 AI 观测能力，可有效追溯每次工具的调用行为。对于安全需求更高的企业级场景，AI 网关还提供插件拓展能力，支持对接企业内部的认证服务或实现自定义的认证协议。对于密钥的安全管理，AI 网关与阿里云 KMS 服务深度集成，为企业提供安全可靠的密钥存储方案。

在内容安全防护方面，AI 网关集成了阿里云内容安全服务，可对请求和响应内容进行合规检测和敏感信息过滤，有效防御提示词攻击等恶意行为。在 MCP 应用中，网关会对传递给模型的所有上下文信息（包括 MCP 服务的配置、描述等）执行内容安全检测，筑起一道针对恶意指令的“免疫防线”，确保模型得到的提示词未受到“污染”。

在流量安全防护方面，AI 网关的 IP 访问控制可以在网络层阻断非法客户端的接入，限流、熔断、缓存等能力可以保障 MCP 服务的安全水位。AI 还网关集成了 Web 应用防火墙和 DDoS 防护等安全组件，可有效识别和阻断恶意攻击流量，确保 MCP 服务的稳定运行。

2、工具优选和语义检索提升批量 MCP 的调用质量、降低调用耗时

下图展示了 Qwen3Embedding 在工具优选中的应用：

下图展示了 Qwen3Reranker 在工具精排中的应用：

下图为 Higress 网关统一 MCP 服务入口及语义检索架构：

工具优选和语义检索是提升批量 MCP 调用质量的两种不同的技术实现方式。

工具优选是指当模型请求在经过网关调用 LLM 时，携带含有大量工具的 tool_calls 数组时，网关侧基于 Qwen3Embedding 和 Qwen3Reranker 的方案，提供工具的精选能力，将 tool_calls 的数量压缩至目标数量，以提升模型响应速度与工具选择精确性。

Qwen3Embedding：它的主要任务是将非结构化的文本转换成能够捕捉其语义信息的数值向量（即“嵌入”）。这些向量使得机器能够度量文本之间的相似性，从而可以快速地从大规模文档库中检索出与用户查询在语义上相关的候选文档。这个过程侧重于效率和广度（召回率），目标是在短时间内捞出所有可能相关的结果。

Qwen3Reranker：它的核心功能是优化和重排序一个已经经过初步筛选的文档列表。它会更精细地评估每个“查询 - 文档”对的相关性，并给出一个更准确的相关度分数，然后根据这个分数对文档进行重新排序，将最相关的结果排在最前面。这个过程侧重于准确性（精确率），目标是提升顶部搜索结果的质量。

语义检索则是基于 Higress 网关的 WASM 插件机制，通过创建一个"All- in- One"的 MCP Server，将用户在网关实例中注册的所有 MCP 工具进行统一聚合和管理，并提供智能的语义化检索能力。

统一入口设计：通过 Higress 网关创建统一的 MCP 服务入口，所有 Agent 通过单一端点即可访问网关实例中的全部 MCP 工具，避免了分散管理多个 MCP Server 的复杂性。

智能工具发现：内置 x_higress_tool_search 语义搜索工具，基于 Dash Vector 向量数据库和 Qwen 系列模型，提供精准的工具推荐能力。Agent 可以通过自然语言描述快速找到最相关的工具，而无需了解具体的工具名称。

双重检索保障：采用"Embedding 粗召回 + Rerank 精排"的双重检索机制。首先通过 QwenEmbedding 模型进行向量相似度检索，获取候选工具集合；然后可选择性地使用 QwenRerank 模型进行精确排序，确保返回给 Agent 的工具列表质量最优。

实时数据同步：建立完善的 MCP 工具生命周期管理机制，当用户在控制台中新增、修改或删除 MCP Server 时，系统自动进行工具元信息的采集、向量化和存储，确保向量数据库与实际 MCP 服务保持实时同步。

控制台一体化：用户只需在控制台中开启语义搜索的开关，系统即可自动完成 DashVector 集合创建、模型配置、路由下发、数据同步等全流程操作，提供开箱即用的用户体验。

3、Nacos 解决“MCP 爆炸”问题

下图展示了 Nacos MCP Registry 与 Router 的整体架构：

当 MCP 服务、工具的数量过多时，模型容易产生“工具幻觉”，针对这个问题，Nacos3.0 提供了 MCP Registry 和 MCP Router（下面简称 Router）的能力。MCP Registry 允许用户将已有的 MCP 服务统一注册到 Nacos 上，Router 则可以根据用户任务的语义描述和关键词，从 MCP Registry 中筛选出最匹配的 MCP 服务，然后将这些服务提供给模型进行决策。

Router 是一个标准的 MCP 服务，引入 Router 后，用户不再需要手动的为不同任务配置不同的 MCP 服务，而是只需接入 Router 这一个 MCP 服务即可，极大的简化了配置的复杂度。更重要的是，Router 显著优化了 Token 使用效率。初始阶段，AI 应用程序仅需向大模型传递 Router 自身的轻量级工具描述，避免了全量工具信息的冗余传输。在实际执行过程中，Router 会动态匹配并仅返回与当前任务相关的 MCP 工具描述，从而大幅减少上下文长度，有效缓解因工具描述过多导致的 Token 消耗问题，降低推理成本，提升响应速度。

4、HiMarket 解决 MCP 管理问题

下图展示了 HiMarket 平台的集中化管理能力：

HiMarket 是一个开箱即用的 AI 开放平台，可用于帮助用户实现 MCP 服务的集中化管理。作为一个统一的管控面，HiMarket 能够纳管来自于不同系统的 MCP 服务。平台底层集成了各个系统的配置管理能力，且屏蔽了具体的操作差异。用户可以以一套管理方式在 HiMarket 上完成 MCP 服务的配置、发布、开放、运营等工作，将所有的管控操作收敛在一个平台，解决服务分散、管理混乱的问题。

HiMarket 与 AI 网关深度集成，可为 MCP 服务提供安全管控能力。用户可以在 HiMarket 上为 MCP 服务统一配置身份认证、设置流控策略、管理订阅授权等。平台提供了多维度的业务观测能力，支持从全局视角查看 MCP 服务的调用情况，便于用户定位问题以及分析系统的性能瓶颈。

HiMarket 还支持用户构建私有的 MCP 市场，实现 AI 能力的产品化运营。用户可以创建定制化的 MCP 门户，并将 MCP 服务封装成标准的产品，搭配上使用文档、安全防护策略，最后发布到门户上，供企业内外的开发者使用，促进业务创新。在能力变现方面，HiMarket 提供了灵活的计量计费规则，帮助用户实现 MCP 服务的货币化。

MCP 实践

纸上得来终觉浅，绝知此事要躬行。

在大多数成熟的企业中，许多有价值的信息并非存在于公开的互联网，而是沉淀在企业内部，包括数据库里的业务数据、API 背后的服务能力、文档库中的规章制度与知识沉淀…这些资源构成了企业运营的数字基石。

那么，如何打破 AI 与企业内部数字世界之间的壁垒呢？答案在于通过标准化的协议（如 MCP）实现资源的统一接入与智能化封装。本节将以 MCP 为主线，探讨把传统资源改造为可供 LLM 实时调用、理解和利用的动态知识与能力。这不仅是技术的升级，更是企业迈向深度智能化，让 AI 真正融入业务流程、赋能决策的关键一步。

构建 MCP 的实践

理论付诸实践，企业可以通过多种路径构建 MCP Server，以实现对内部资源的智能化封装。以下我们将介绍从零构建和基于存量资源改造这两种实践路径。

1、从零快速构建 MCP Server

基础环境与技术选型

技术选型上，TypeScript/Python/Java/Kotlin/C#作为主流开发语言，均拥有官方/社区SDK支持；开发框架上，为避免重复造轮子，社区涌现了众多优秀的开源MCP Server 框架，它们极大地简化了开发流程。

MCP-Framework (TypeScript)：一个专门为 Claude MCP 协议设计的开发框架，提供了自动化工具、资源和提示加载等功能，是快速搭建 Node.js 环境 MCP Server 的利器。

Spring AI MCP (Java)：作为 Spring 生态的一部分，它与 Spring Boot 无缝集成，允许开发者通过注解驱动的方式，轻松地将现有 Java 服务器露为 MCP 工具。

FastMCP (Python)：基于 Python 的 MCP 框架，用于快速构建 MCP 服务器和客户端，旨在简化 MCP 协议的实现，提供高效、简洁的开发体验。

核心逻辑实现

核心功能上，重点聚焦 Tool 的实现。一个 Tool 本质上是一个可被 LLM 调用的函数，它必须包含清晰的名称、描述以及参数定义。以下是利用不同框架构建一个“查询天气”工具的示例：

MCP- Framework (TypeScript) 示例通过声明式对象来定义一个 Tool，结构清晰，语义明确。

Spring AI MCP（Java）示例

支持注解驱动，利用@Tool 注解，将一个普通的 Java 方法转化为 AI 可用的工具。

FastMCP（Python）示例

FastMCP 提供了一个 @mcp.tool() 装饰器对实现函数进行装饰即可，函数名称作为工具名称，参数作为工具参数，并通过注释来描述工具与参数以及返回值。

LLM：除了利用以上开源框架外，开发者也可以借助 Claude 等强大的 LLM 来辅助生成 MCPServer 框架代码，进一步提升开发效率，具体可参考 MCP 官方提供的教程示例：

https://mcp-docs.cn/tutorials/building-mcp-with-tmls

传输协议实现

传输协议上，MCP 支持两种通信方式。

stdio（标准输入/输出）：适用于本地开发和调试。MCPServer 作为一个子进程运行，通过标准 I/O 与客户端（如本地的 VSCode 插件）通信。这种方式简单直接，但无法被网络上的其他服务调用。

SSE(Server- SentEvents)：基于 HTTP 长连接实现，是生产环境的推荐方式。它将 MCPServer 暴露为一个标准的 HTTP 服务，可以部署在服务器上，供远程的 AIAgent、应用后端等进行访问和调用，具备良好的扩展性和通用性。

调试与部署

开发完成后，可使用 MCPInspector 或者集成了 MCP 客户端功能的 IDE 插件或应用（ClaudeDestop、VSCode 等）进行功能调测，验证 Tool 的描述是否清晰、参数是否正确、返回是否符合预期。最后，将构建好的 MCPServer 部署到本地环境或服务器环境。

2、基于存量 OpenAPI 构建 MCPServer

对于拥有大量存量 OpenAPI 的企业而言，逐一重启业务逻辑是不现实的。更高效的策略是构建一个“适配层”，将现有的 OpenAPI 能力自动或半自动地转化为 MCPServer。这种方式无需从头开发业务逻辑，只需要构建一个中间转转换层，将 MCP 协议的请求转换为对现有 OpenAPI 的调用，并将 API 的响应转换为 MCP 协议的格式，其常规步骤包括：

OpenAPI 解析：读取并解析存量 OpenAPI 规范文档，自动提取 API 路径、请求方法、请求参数、响应格式和认证方式等元数据。

MCP 映射与定义：根据解析出的元数据，按照 MCP 规范自动生成 MCP 中新的描述。例如，将 API 中执行类操作，例如获取天气、操作网页等，定义为 MCP 的 Tool；将 API 中返回的数据/可复用或频繁读取的数据，例如定位信息，映射为 MCP 的 Resource。

请求/响应转化

解析 MCP 调用：监听并解析来自 MCP 客户端的 tool/callJSON- RPC2.0 请求。构建调用 API：通过配置好的参数映射信息、路径、后端地址等信息，匹配到对应的 OpenAPI 定义，动态构建 HTTP 请求（包括 URL、Header、Body），并调用真实的后端 API 服务。封装 MCP 响应：将 API 返回的响应数据包装为 MCP 协议要求的标准 tool/call 结果格式，返回给客户端。

然而，通过上述方式手动将批量 OpenAPI 转化为 MCPServer 是一个需要时间和人力的繁重体力活。幸运的是，为提高生产和转化效率，成熟的 API 网关和开源工具为此提供了自动化解决方案。

利用 HigressAI 网关实现零代码接入

Higress 作为云原生 API 网关，提供了强大的 AI 能力支持，其 openapi- to- mcp 工具是实现存量 API 快速接入的典范。该工具可将存量 OpenAPI 自动转化为 MCPServer，输入一个 JSON，得到一个标准的 MCP 配置，由此支持开发者无需从零开始，即可快速高效构建 MCPServer。其优势在于：

• 零代码改造，接入便利：开发者无需编写一行代码，即可将 OpenAPI 定义文件直接转换为 Higress 可识别的 MCP Server 配置。

• 白屏化操作，维护便利：生成的配置可以导入 Higress 控制台，通过图形化界面进行修改和管理，极大降低了维护成本。

• 无需提供 MCP 运行时，运维便利：Higress 自身承担了 MCP Server 的运行时角色，负责协议转换和请求路由，业务团队无需关心 MCP Server 的部署和运维。

借助 Higress 这一特性，业务可以将重心放在 MCP 工具的描述与 Agent 如何更好地协作上，而不是如何编写 MCP Server 的代码实现上，从而帮助业务智能化进程提效。具体可参考以下示例进行安装和使用：

将生成的 mcp- config.yaml 文件导入 Higress，即可完成路由配置。此时，Higress 即优雅地实现了将 AIGent 的调用请求转发至后端 OpenAPI 服务。

此外，Higress 还支持将数据库（MySQL、PostgreSQL、Clickhouse 等）直接暴露为 MCP Server，只需提供数据库连接信息（用户名、密码、域名/IP、端口），即可自动生成用于数据查询和操作的 Tool，进一步拓宽了数据智能化的边界。

结合 Nacos 提供 MCP Registry 能力

当 MCP Server 数量增多时，如何统一管理和动态更新这些 Tool 的元信息成为新的挑战。Nacos 提供了 MCP Registry 的能力，可以帮助更好地集合 MCP 信息和管理 MCP Server 运行时。同样，Nacos 也支持将存量 API 服务转换为 MCP 可调用的工具服务，其直接通过 Nacos 配置进行实现，而无需对任何业务代码进行修改，并可同时结合 Higress 实现 MCP 协议和存量协议的转换。通过将 Higress 与 Nacos 服务注册与发现中心结合，可以构建一个更为强大和灵活的 MCP 服务治理体系。其具体调用流程图如下所示：

下图展示了 MCP 服务治理体系的整体流程：

在智能化改造过程中，使用 NacosMCPRegistry 的优势在于

• 存量 API 快速构建 MCP Server：通过 Nacos 和 Higress 集成，用户可以零代码快速构建 MCP Server，迅速跟进 MCP 协议，无缝对接存量 API；- 统一注册与动态发现：所有 MCP Server（包括存量 API 转换、自研、第三方的）均可以注册到 Nacos 进行统一管理；- MCP 信息动态下发实时生效：Nacos 可以帮助管理和下发 MCP 信息、Tools 及 Prompt，实现动态调整和实时生效，以达到更好的效果；- MCP 版本与灰度管理：Nacos 天然支持配置的历史版本管理和灰度发布。当需要调整 Tool 描述时，Nacos 支持灰度分批生效，可以对比不同版本描述对 AI 调用效果的影响，确保变更平稳、可控，并可在出现问题时快速回放；- MCP 服务管理及健康检查：Nacos 在 MCP 服务数量的增加下提供大规模服务管理能力，包括健康检查、实时更新和负载均衡，确保 MCP 服务的高效运行。

从第一个 MCP Server 开始

借助 MCP，企业可以将散落在各个角落的传统数字资源快速、标准化地暴露为 LLM 可安全使用的工具。从 0 到 1 的关键在于选择熟悉的 SDK、用最小面工具打通首个业务场景、以中间层适配 OpenAPI/数据库降低接入成本，并在生产阶段补齐安全、性能与治理。

MCP Server 的开发之旅，从技术上讲并不复杂，但要构建一个真正生产可用、性能卓越、智能高效的服务器，则需要在协议理解、业务封装、性能优化和安全防护等多个维度上精益求精。建议以“一个小而确定的用例”为起点，充分利用开源能力（如 Higress、Nacos、各语言 SDK）开始动手实践，在此基础上逐步优化、迭代和扩展到更复杂、更高价值的业务流程。

亲眼见证这些经过智能化改造的数字资源，如何为 AI 原生应用注入前所未有的活力与智慧，这本身就是一场激动人心的变革。

总结

本章系统梳理了 AI 工具的关键作用，深入分析了 Function Calling 的局限、MCP 协议的优势与挑战，并总结了 AI 工具标准化与工程实践路径。理解并合理运用这些技术，将为构建可扩展、可治理的智能应用生态奠定坚实基础。