引言

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

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

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

Function Calling

Function Calling（函数调用）是一种允许 LLM 根据用户输入识别它需要的工具并决定何时调用该工具的机制。LLM 接收用户的提示词，LLM 决定它需要的工具，执行方法调用，后端服务执行实际的请求给出处理结果，大语言模型根据处理结果生成最终给用户的回答。

Function Calling 使用起来非常不方便，需要编写代码，因为是自定义的调用方式，因此很难在不同的平台复用。

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

• 规格碎片化：不同厂商对工具的描述方式、类型系统与 JSON Schema 兼容度、调用时序、错误语义、流式行为都各不相同。即使是类似的功能，在 A 厂商上表现为同步调用、在 B 厂商上却需要异步轮询；有的支持严格校验与参数默认值，有的则完全凭提示工程 “约法三章”。这使跨厂商、跨模型的适配成本居高不下。
• 可靠性挑战：模型常常会错误地选择工具或以错误顺序调用。即便选对了工具，也可能生成不满足约束的参数，出现结构缺失、类型错误、边界值越界，甚至编造参数。多步或并行调用尤为脆弱：中途失败无法优雅回滚，调用结果彼此覆盖、流式响应时序相互干扰，最终让上层业务出现不可预测的行为。
• 工程治理缺位：大多数团队缺少集中式的工具目录与自描述元数据，更谈不上版本与依赖管理、权限分级、调用审计、成本归集。工具的定义散落在各个微服务与提示模板里，难以复用、难以维护、无法衡量 ROI，也难以符合企业的合规与安全要求。
• 厂商锁定与迁移成本高：由于工具适配逻辑深度绑定在某一家模型供应商的接口与语义上，想要在多模型、多云之间切换就需要重复实现同一套工具封装，迁移周期长、风险大，阻碍了 “按需选模、按价择模” 的策略。

MCP

或许是大家也看到了当前大模型应用数据源接入的混乱现状，在 2024 年 11 月初，Anthropic 提出了他们新的模型上下文协议（Model Context Protocol，简称 MCP）。旨在 “整治 LLM 数据源接入混乱现状，打通构建 Agent 的最后一公里”。MCP 是一个开放标准，帮助连接 AI 助手与数据所在的系统，包括内容存储库、业务工具和开发环境。其目标是帮助前沿模型产生更好、更相关的响应。

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

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

MCP 就足够了吗？

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

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

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

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

AI 工具标准化

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

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

MCP 协议介绍

MCP（Model Context Protocol，模型上下文协议，下文中简称 MCP）是一个开放协议，旨在为模型服务提供标准化的接口，使其能够连接外部数据源和工具。MCP 通过统一规范取代了工具的碎片化集成，从而打破数据孤岛，提升 AI 应用的动手能力。这与 USB-C 的设计理念类似：USB-C 通过统一接口连接各类物理设备，MCP 也提供了一种标准化的方式，将 AI 应用连接到不同的数据和工具。

MCP 协议遵循客户端 - 服务器（Client-Server）架构，它允许 AI 应用程序通过 MCP 客户端与多个 MCP 服务器建立连接，实现灵活的上下文传递与功能扩展。MCP 架构包含下面几个部分：

• MCP Host：协调和管理一个或多个 MCP 客户端的 AI 应用程序，如 Claude Desktop、Visual Studio Code 等，需要通过 MCP 协议访问数据。
• MCP Client：MCP 客户端，运行在 MCP Host 内部，负责与 MCP Server 建立并维护连接。MCP Host 会为每一个 MCP Server 单独创建一个 Client，Client 与 Server 保持一对一连接。
• MCP Server：MCP 服务端，轻量级程序，通过 MCP 协议公开特定功能。MCP 协议规定了 MCP Server 可为 Client 提供工具、资源文件以及提示词模板。

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

• Request：请求消息，包含方法名和参数，期望对方返回响应；
• Result：对请求的成功响应；
• Error：表示请求处理失败，包含错误码和错误信息；
• Notification：单向通知消息，无需响应。

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

1. 协议初始化：AI 应用程序启用 MCP Client，MCP Client 向 MCP Server 发起初始化请求，附带 MCP 协议版本和基础上下文等信息。MCP Server 返回初始化响应，包含 MCP Server 名称、版本以及功能概览。
2. 能力发现：MCP Client 查询 MCP Server 的工具 / 资源文件 / 提示词模板列表，不同类型的标准方法如下：

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

1. 功能调用：MCP Client 根据业务需要动态请求工具调用 / 资源文件 / 提示词模版，MCP Server 返回具体的响应内容。
2. 会话终止：交互完成后，MCP Client 和 MCP Server 均可以主动关闭连接。

MCP 的核心优势

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

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

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

灵活的资源调度方式

MCP 支持 STDIO、SSE、Streamable HTTP 三种连接模式，STDIO 可通过进程间通信访问本地的文件系统、数据库等资源，而 SSE、Streamable HTTP 能够支持对远程服务的调用。一个 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 开发框架，简化了用户开发流程，如果结合 AI IDE 等工具，可进一步提高开发效率。将一个已有的服务升级为 MCP 服务所需的改动也非常小，通过 Higress 网关与 Nacos 等中间件，存量应用可以在不修改代码的前提下被封装为 MCP 服务，只需配置工具描述、参数定义等元信息即可。

MCP 面临的挑战

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

安全问题

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

大规模应用问题

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

集中管理问题

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

可行的解决方案

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

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

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

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

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

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

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

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

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

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

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

• 统一入口设计：通过 Higress 网关创建统一的 MCP 服务入口，所有 Agent 通过单一端点即可访问网关实例中的全部 MCP 工具，避免了分散管理多个 MCP Server 的复杂性。
• 智能工具发现：内置 x_higress_tool_search 语义搜索工具，基于 Dash Vector 向量数据库和 Qwen 系列模型，提供精准的工具推荐能力。Agent 可以通过自然语言描述快速找到最相关的工具，而无需了解具体的工具名称。
• 双重检索保障：采用 “Embedding 粗召回 + Rerank 精排” 的双重检索机制。首先通过 Qwen Embedding 模型进行向量相似度检索，获取候选工具集合；然后可选择性地使用 Qwen Rerank 模型进行精确排序，确保返回给 Agent 的工具列表质量最优。
• 实时数据同步：建立完善的 MCP 工具生命周期管理机制，当用户在控制台中新增、修改或删除 MCP Server 时，系统自动进行工具元信息的采集、向量化和存储，确保向量数据库与实际 MCP 服务保持实时同步。
• 控制台一体化：用户只需在控制台中开启语义搜索的开关，系统即可自动完成 Dashvector 集合创建、模型配置、路由下发、数据同步等全流程操作，提供开箱即用的用户体验。

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

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

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

4、HiMarket 解决 MCP 管理问题

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

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

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

MCP 不仅是技术协议，也是一种生态愿景，它打破了 AI 模型与现实世界之间的壁垒，让大模型真正成为 “能看、能听、能操作” 的智能体。虽然目前在企业内大规模落地仍存在不少挑战，但这是技术迭代过程中的必经之路，也是推动技术演进的持续动力。MCP 在不断的发展和完善，其标准化、模块化、可复用的设计理念，已为 AI 应用的爆发奠定了基础。未来，随着更多开发者的加入和技术的持续创新，MCP 必将释放出更大的潜力。