MCP协议详解：取代Function Calling的智能体通信新标准

为什么Function Calling已经不够用了？

在智能体（Agent）开发的早期阶段，大模型调用外部工具的标准方式是 Function Calling。Function Calling（函数调用）是OpenAI于2023年6月在GPT-3.5和GPT-4中率先引入的能力，允许开发者以JSON Schema格式描述函数签名，让模型在生成回复时决定是否调用某个函数并输出结构化参数。这一机制本质上是一种「意图识别+参数提取」的过程——模型并不真正执行函数，而是输出一段JSON，由外部代码负责实际调用。

然而，这种方式正在被逐步淘汰，原因主要有两个：

第一，缺乏统一标准。 Anthropic随后在Claude中推出了Tool Use，Google在Gemini中提供了类似能力，但三者的请求格式、错误处理和流式响应方式均存在差异。不同模型提供商（OpenAI、Anthropic、智谱等）的 Function Calling 接口和格式各有差异，开发者需要针对不同平台编写不同的适配代码，在多模型场景下需要维护大量适配层代码。

第二，工具执行依赖外部框架。 真正的工具执行由外部框架完成，但市面上并没有一个统一的外部框架标准。这意味着切换模型供应商或第三方框架时，代码都需要做相应修改。

简而言之，如果你现在还在使用 Function Calling 来开发智能体，那你的技术栈可能已经落后了。MCP（Model Context Protocol） 正是为了解决这些痛点而诞生的。

MCP协议是什么？一个通俗的解释

MCP 的全称是 Model Context Protocol，即「模型上下文协议」。虽然中文翻译看起来每个字都认识，但组合在一起却不太好理解。

用一句话来概括：MCP 就是大模型和外部工具之间的一个通信协议。

它由 Anthropic 于2024年11月底推出，是一种开放标准，目的是统一大语言模型与外部数据源、工具之间的通信方式。

MCP的技术架构

MCP在架构上采用了经典的客户端-服务端模型（Client-Server Architecture），并在此基础上引入了「Host」层的概念。Host是运行大模型的宿主应用（如Claude Desktop、IDE插件等），Client是Host内部负责与MCP Server通信的模块，Server则是对外暴露工具、资源和提示词模板的独立进程或服务。这种三层架构实现了关注点分离：模型只需与Client交互，Client负责协议转换，Server专注于业务逻辑。MCP底层使用JSON-RPC 2.0作为消息格式，这是一种轻量级的远程过程调用协议，具有良好的语言无关性和可读性。

为什么需要MCP协议？

回顾传统的智能体开发方式：创建一个 Agent 时，我们会把工具函数直接写在同一个项目中，运行时工具和智能体在同一个进程里执行。这种方式存在明显的局限性——

假设某个部门已经开发了一套通用工具，你想让多个智能体都能调用它。难道要把代码一个一个拷贝到每个智能体项目中吗？显然不合适。

我们需要的是一种支持远程调用、基于网络协议的方式，让智能体和外部工具（包括其他部门甚至其他公司提供的工具）能够无缝整合。这就是 MCP 要解决的核心问题。

MCP服务端不只有工具

有意思的是，MCP 服务端不仅可以定义工具（Tools），还可以定义数据源（Resources）。也就是说，外部的静态数据和动态数据都可以通过 MCP 协议暴露给智能体使用。不过在实际开发中，工具调用仍然是最主要的使用场景。

MCP支持的三种通信机制

MCP 协议支持三种通信机制，理解它们的区别对实际开发至关重要：

1. Stdio（标准输入输出）

Stdio 是 MCP 最早支持的通信方式，通过操作系统的标准输入输出实现通信。这种方式本质上是本地通信，工具和智能体运行在同一台机器上。

但在真实的企业开发中，几乎不会使用 Stdio 来调用本地工具。原因很简单：如果工具就在本地，直接在同一个进程中调用就行了，何必多此一举经过标准输入输出的协议层？这反而会降低调用速度。

2. SSE（Server-Sent Events）

SSE（Server-Sent Events）是HTML5规范中定义的一种服务器推送技术，基于HTTP长连接实现服务端到客户端的单向数据流。在早期MCP实现中，SSE被用于服务端向客户端推送工具执行结果，而客户端向服务端发送请求则通过独立的HTTP POST完成，形成一种「双通道」通信模式。这种方式的局限在于连接管理复杂、不支持双向流式传输，且在负载均衡和反向代理场景下容易出现连接断开问题。虽然可用，但已逐渐被更新的方案取代。

3. Streamable HTTP（推荐方案）

2025年3月底，MCP 新增了 Streamable HTTP 通信机制。这是目前的主流方案，也是未来的发展方向。相比SSE，Streamable HTTP通过单一HTTP连接同时支持请求和响应的流式传输，并兼容标准的HTTP基础设施，大幅降低了部署复杂度。它既适用于简单的请求-响应场景，也能处理长时间运行的任务。

新项目应优先采用 Streamable HTTP 作为通信方式。

MCP的生态现状与发展潜力

国内外众多大公司已经对外发布了自己的 MCP 服务接口：

• 腾讯：已发布对外的 MCP 工具接口
• 阿里巴巴：已发布公网可访问的 MCP 服务
• 智谱：同样提供了对外的 MCP 工具

这些公网暴露的 MCP 接口通常需要认证机制（如 JWT Token）以确保安全性。JWT（JSON Web Token）是一种开放标准（RFC 7519），通过数字签名将用户身份信息编码为紧凑的字符串，服务端无需查询数据库即可验证令牌有效性，非常适合分布式系统。在MCP的OAuth 2.0授权框架中，客户端首先向授权服务器获取访问令牌，再将令牌附加在每次MCP请求的HTTP Header中。MCP规范还定义了工具级别的权限控制，允许服务端声明每个工具所需的最小权限范围，遵循最小权限原则，防止智能体越权访问敏感资源。而公司内部的 MCP 服务为了追求速度，往往不需要额外认证。

MCP带来的变革

可以这样理解 MCP 的潜力：

• 没有 MCP 之前：每个智能体就像一台孤立的个人电脑，各自为战
• 有了 MCP 之后：公司内部各部门的智能体可以互联互通，甚至全球范围内，只要企业愿意对公网暴露 MCP 接口，所有公司的智能体开发部门都可以相互连接

这意味着你的智能体可以整合全球范围内的工具和数据资源，功能将变得极其强大和灵活。

开发者需要关注的技术栈更新

对于正在学习或使用 MCP 的开发者，以下几个更新值得重点关注：

1. MCP 服务端 SDK 升级到 2.0：接口和用法有较大变化，旧版代码需要迁移
2. LangChain MCP Adapters 库更新：2025年6月底进行了更新，客户端代码需要相应调整
3. Streamable HTTP 成为主流：新项目应优先采用这种通信机制
4. LangChain 和 LangGraph 客户端：LangChain适合构建相对线性的AI工作流，提供链式调用、记忆管理、向量检索等核心能力；LangGraph则是基于有向图（Directed Graph）的计算框架，每个节点代表一个处理步骤，天然支持循环、分支和并行执行，更适合构建需要动态决策、多轮工具调用的复杂智能体场景。两者都可以作为 MCP 客户端使用，按需选择即可。

总结：MCP是智能体开发的必修课

MCP 协议正在成为智能体开发的基础设施。它解决了 Function Calling 时代的碎片化问题，提供了统一的、安全的、可扩展的工具调用标准。随着越来越多的企业发布公网 MCP 服务，智能体的能力边界将被极大拓展。

对于开发者而言，掌握 MCP 不再是可选项，而是必修课。现在正是学习和实践的最佳时机——从搭建一个简单的 MCP 服务端开始，逐步将它融入你的智能体项目中。

核心要点

• MCP（Model Context Protocol）是由Anthropic推出的开放标准，底层基于JSON-RPC 2.0协议，统一了大模型与外部工具和数据源之间的通信协议，正在取代传统的Function Calling
• MCP支持三种通信机制：Stdio（本地）、SSE和Streamable HTTP，其中Streamable HTTP是2025年新增的主流方案，通过单一HTTP连接支持双向流式传输
• 腾讯、阿里巴巴、智谱等国内外大公司已发布公网MCP服务接口，通常采用JWT Token和OAuth 2.0进行安全认证，MCP生态正在快速成熟
• MCP服务端SDK已升级到2.0，LangChain MCP Adapters也在2025年6月进行了更新，开发者需要关注技术栈变化
• MCP的核心价值在于实现智能体与工具的完全解耦，支持跨部门、跨公司的远程工具调用，极大提升了智能体的灵活性和扩展性