MCP技术浪潮中的Agent应用开发新范式

MCP （Model Context Protocol，模型上下文协议）是一个标准化协议，定义了应用程序和 AI 模型之间交换上下文信息的方式。这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型（一个中间协议层），就像 USB-C 让不同设备能够通过相同的接口连接一样。MCP 的目标是创建一个通用标准，使 AI 应用程序的开发和集成变得更加简单和统一。

1.2 MPC 核心组件

如上图所示，在 MCP 架构体系中，包含MCP Server、MCP Client和MCP Host几个核心组件，及组件间交互协议。

MCP Server 是一个通过 MCP 协议实现对外提供服务的轻量级应用，它对外提供工具执行、资源访问、预定义 Prompt 等一系列资源。

○ 资源（Resources）：类似文件的数据，可以被客户端读取，如 API 响应或文件内容 ○ 工具（Tools）：可以被 LLM 调用的函数 ○ 提示（Prompts）：预先编写的模板，帮助用户完成特定任务

下面是一个文件系统操作的 MCP Server 示例，它提供了对文件、目录的读写操作。

在 Host 应用内部，MCP Client 与 MCP server 保持 1:1 的连接。MCP Client 充当 LLM 和 MCP Server 之间的桥梁。简单理解就是 MCP Client SDK，用于实现 Host 应用使其能够与 MCP Server 交互。

发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 或 AI 工具）。通常像Claude Desktop 和 Cursor 这类智能助手应用和IDE，它们都是 MCP Host 应用，通过 MCP client 来连接某个 MCP Server，并调用其提供的工具。

另外值得注意的是，运行 MCP Host 应用所在的主机也属于 MCP Host 的一部分，主机的文件系统、浏览器等都可能成为 MCP Server 在运行时操作的对象。

1.3 通信协议

MCP 采用 JSON-RPC 来编码消息，在 Sever 和 Client 之间通过标准输入输出和 Streamable HTTP 进行消息交换。

采用标准输入/输出流进行传输，适用于在同一台机器上运行的客户端和服务器之间的通信。

Server

Client

远程通信：利用 SSE 与 HTTP 结合，实现跨网络的实时数据传输，适用于需要访问远程资源或分布式部署的场景。

Server

Client

1.4 MCP协议带来的改变

在使用 MCP 协议之前，开发智能应用的开发者（如Cursor）如果要使用外部服务的能力，每个应用开发需要各自开发对接外部服务的程序来实现能力集成。使用 MCP 后，服务提供者（如Slack、Google Drive）会以 MCP 标准协议对外提供 MCP Server，服务的工具和资源将统一汇聚到市场上，应用以标准化的接口对接资源和工具，从而提升资源和工具的标准化和复用率。

1. MCP Client 首先从 MCP Server 获取可用的工具列表；
2. 将用户的 Query 连同工具描述通过 Function Calling 一起发送给 LLM；
3. LLM 决定是否需要使用工具以及使用哪些工具；
4. 如果需要使用工具，MCP Client 会通过 MCP Server 执行相应的工具调用；
5. 工具调用的结果会被发送回 LLM；
6. LLM 基于所有信息生成自然语言响应；
7. 最后将响应展示给用户。

2.1 Host 调用 LLM

Host 将用户 Query 和 Tools 一起发给 LLM。

2.2 Client 调用 MCP Server

大模型通过 Query 和提供的工具进行推理，确定完成用户任务需要执行的工具，如果 LLM 返回结果中如果需要执行 tool_calls，则在会话中调用 MCP Server。

2.3 返回最终处理结果

Host 将 MCP Server 执行的结果和 Message 一并发给 LLM，如果不需要再调用其他工具，那么调用 LLM 做最后润色后返回最终结果。

LLM Agents 是专为生成需要推理和执行任务的高级人工智能系统。它们能够通过推理思考、回忆过往对话，并通过调用外部工具，根据上下文和用户要求动态规划和执行任务，最终自动完成用户问题。

形象来讲，LLM 是一个强大的文本处理大脑，但其本身不具备执行任务的能力，因此需要借助工具，使其能够调用外部工具和服务，从而代理人工完成复杂任务的规划和执行。

3.2 Function Calling

OpenAI 最初通过 Function Calling 来给大模型装上“手脚”，让其能够调用外部工具和服务，从而代理人工完成复杂任务的规划和执行。

通过精妙的 Prompt 设计，可以让模型根据用户 Query 和可用的 Function 描述来进行任务分解和推理，从而选择合适的工具进行执行，并通过多次迭代完成用户任务。

3.3 MCP

Function Calling 的问题显而易见，对于 Function 的描述各厂商存在差异，模型迁移成本高；另外 Fucntion Call 存在效果不稳定、容错性低等问题。而 MCP 标准化了 Agent 与外部资源和工具交互的接口、协议及实现。从而为构建更为健壮的  Agent 应用和推动生态的协作起到了关键作用。

3.4 对比

4.1 MCP Server Marketplace

几个主要的 MCP Server Marketplace 上 Host 的 MCP Server 数量在短短20天内（2025/3/28 - 2025/4/18）有了大幅的增长。这进一步说明了其技术生态的繁荣程度。

4.2 MCP 应用程序

我们可以在 PulseMCP 上看到200多个应用支持了 MCP，你可以在上面找到适合自己的 MCP 应用。

4.3 MCP Server

以 mcp.so 上的 MCP Server 目录为例，我们看到 MCP Server 的范围已经涵盖数据、研究、云平台、数据库、Chatbot、文件系统、自动化等多个领域。

除此之外，在开发者支持方面，除了官方的 SDK 以外，FastMCP、Spring AI、mcp-agent 等技术框架也进一步降低了 MCP 的开发成本。

5.1 MCP带来的变化

正如 WebService 和 WSDL 定义了系统间服务调用的基本协议，推动了 SOA 架构的广泛发展，从此单应用系统逐渐发展成为多应用系统，企业内部的各个系统实现了数据交换和服务集成。REST 轻量级服务风格进一步降低了数据传输中的 Schema  复杂度，而之后的微服务又使得服务进一步解耦和原子化，结合容器编排技术提升了服务的治理能力。任何一种技术和协议都是在不断迭代中进行发展、升级及迭代的。

在此，我们不妨大胆预测 MCP 带来的变化：

MCP OpenAPI化

MCP 将成为软件对外开放和集成的新协议，SaaS、应用服务将会以 MCP 方式提供对外服务，MCP 将成为与 OpenAPI 类似的对外服务协议。

应用交互重构

重构应用形态，智能助手将以“搜索框”的形式成为各个应用的交互入口，支持语音及自然语言交换形式，完成复杂任务的执行。

业务 E2E 自动化

端到端理解用户意图、执行任务、容错处理将大大简化用户业务流程，一句话自动完成下单、售后、流程审批等操作将变得更为常见。

生态开放协作

支付、生活服务、内容服务等服务作为基础能力，实现你中有我、我中有你，从而更大限度拓展服务生态的协作开放。例如，一个个人助手可以完成调用获取好友列表、差旅申请、支付流程等操作，实现在一个应用中通过集成多个服务的 MCP Server 来完成复杂业务，前提是 MCP 授权及安全有保证，且 MCP 具有广泛的应用场景。

5.2 技术限制

当然，MCP 还处于发展初期，不可避免存在很多问题及缺陷，具体表现在：

应用范围受限

MCP Server 大部分以本地库方式执行，很大比例的 MCP Server 依赖于浏览器等外部工具，通常是以 Desktop App + MCP 方式执行，更适合个人 Assistant。企业应用一般在云端执行，这在一定程度限制了 MCP 的应用。

行业标准支持

当前在数据连接和交互领域有众多标准在竞争，MCP 协议只是其中之一，要想成为行业通用标准面临很大挑战。目前 MCP 主要依托 Anthropic 的 Claude 生态，缺少核心厂商的支持，但也看到像 OpenAI，以及阿里、腾讯也在积极拥抱 MCP。

对协议本质的质疑

MCP 本质上更像是 FunctionCall 与 Proxy 的组合，在这个角度上来看，MCP 只是对于 Agent 执行外部工具和访问外部资源做了规范，并未在更大范围内实现标准化。许多人质疑其是否能够称之为一个真正的协议。

安全风险

MCP Server 本地部署，被 Host 使用后将直接获得 Host OS 的访问权限，不安全的 MCP Server 将可能成为漏洞跳板。此外，不可信的 MCP Server 通过各种攻击手段也带来了诸多安全挑战。

例如：开发一个 MCP Sever 用来实现加法操作，同时在其中放入恶意的 Prompt，要求 LLM 读取用户当前的工作路径。那么在其执行时就会读取用户工作目录和文件。