1. 一个熟悉的困境

如果你做过 AI Agent，下面这段经历大概率不陌生：

  • 先为 Claude 写了一套工具定义
  • 换到 GPT，发现参数格式要重写
  • 再支持一下国内模型，又是一套
  • 每个 Agent 框架（LangChain、AutoGen、CrewAI）又各有各的封装
  • 想把同一个数据库查询能力复用到三个 Agent 上？复制粘贴吧

工具调用的能力模型各异、集成方式各异、复用性极差，这是 2024 年 AI 应用开发中最典型的「重复造轮子」。

2024 年 11 月，Anthropic 开源了 Model Context Protocol（MCP），试图解决这个问题。业内普遍把它比作「AI 界的 USB-C」：一个统一的接口标准，让任何模型都能连接任何工具或数据源。

2. MCP 是什么

MCP 是一个开放协议，定义了 AI 应用（Client） 与 外部能力提供方（Server） 之间的通信方式。

它基于 JSON-RPC 2.0，支持三种传输方式：

  • stdio：通过标准输入输出通信，适合本地进程（如本地文件系统、CLI 工具）
  • HTTP + SSE（旧版）：通过 HTTP 长连接实现服务端推送
  • Streamable HTTP（2025 年新版）：更简洁的 HTTP 流式传输，支持无状态部署

一个典型的 MCP 架构包含三个角色：

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│  MCP Client │ ◄─────► │  MCP Server │ ◄─────► │  外部资源   │
│  (AI App)   │  JSON   │  (Adapter)  │  原生   │  DB/API/FS  │
└─────────────┘   RPC   └─────────────┘  协议   └─────────────┘
  • Host：运行 AI 应用的宿主环境（如 Claude Desktop、IDE 插件）
  • Client：Host 内部与单个 Server 建立的连接
  • Server：暴露工具、资源、提示词模板的服务

3. MCP 的三大核心原语

MCP 不只是「工具调用」，它定义了三种核心原语，分别对应 Agent 需要的三类能力：

3.1 Tools（工具）

模型可以主动调用的函数。例如「查询数据库」「发送邮件」「创建工单」。

这是最常见也最重要的一类。每个 Tool 都包含名称、描述、参数 JSON Schema，和 Function Calling 的定义很相似，但标准化了发现机制：Client 可以通过 tools/list 动态获取可用工具，而不需要硬编码。

3.2 Resources（资源）

由 Server 提供的只读数据，类似「文件」或「文档」。例如「项目 README」「数据库 Schema」「当前配置文件」。

Resources 与 Tools 的区别在于：Resources 是被动的数据，Tools 是主动的操作。Client 可以列出资源、读取资源，但不需要模型自己发起函数调用。

3.3 Prompts（提示词模板）

Server 可以提供预定义的提示词模板，用于引导用户完成特定任务。例如「代码审查」「生成周报」等。

这个原语在实际落地中用得相对少，但它的价值在于：把最佳实践封装在服务端，让用户开箱即用。

4. 相比 Function Calling 的改进

MCP 并不是要取代 Function Calling，而是在其之上解决「集成与复用」问题。

能力原生 Function CallingMCP
工具定义每个模型/框架自己定义统一协议，一次定义到处用
工具发现硬编码在应用里动态 tools/list
传输方式各家自定stdio / HTTP 标准化
复用性复制粘贴一个 Server 可被多个 Client 使用
生态各自为战已有官方与社区 Server 生态

一个直观的收益是：如果有一个团队维护了「公司内部知识库」的 MCP Server，那么 Claude Desktop、Cursor、自研 Agent 都可以直接接入，而不需要为每个客户端重新实现一遍。

5. 落地时的真实问题

MCP 的理念很清晰，但在实际使用中仍有几个坑需要提前知道。

5.1 工具数量与上下文压力

当 Client 接入十几个 Server，每个 Server 又暴露十几个工具时，工具定义本身就会占用大量上下文。这与「上下文工程」的取舍问题直接相关——不是接入越多越好，而是接入当前任务真正需要的。

社区正在探索的解决方案包括：工具按需加载、分层工具目录、动态筛选等。

5.2 安全边界

MCP Server 拥有访问外部系统的能力。一个配置不当的 Server 可能带来严重的安全风险：

  • 本地文件系统 Server 如果配置了过宽的访问路径，可能泄露敏感文件
  • 数据库 Server 如果权限过大，可能被恶意提示词诱导执行危险操作
  • 第三方 Server 的供应链安全需要审查

原则：最小权限、显式授权、隔离运行。 生产环境不建议直接把高权限 Server 暴露给不可信的 Agent。

5.3 调试与可观测性

MCP 通信是 JSON-RPC，出问题时排查链路比较长。建议：

  • 保留完整的请求/响应日志（注意脱敏）
  • 使用官方 Inspector 工具调试 Server
  • 对工具调用做超时与重试控制

5.4 状态管理

MCP 本身是无状态协议（Streamable HTTP 引入了 session 概念，但整体偏无状态）。对于需要长任务的场景，状态管理仍需应用层自己处理。

6. 小结

MCP 的出现，标志着 AI Agent 的工具生态正在从「野蛮生长」走向「标准化」。它的意义不在于协议本身有多复杂，而在于：

  • 降低了集成成本：一次实现，多处复用
  • 催生了生态：Server 市场开始出现
  • 推动了标准化：其他厂商也在跟进类似的开放协议

当然，标准化的另一面是「标准本身的成熟需要时间」。目前的 MCP 仍在快速演进，安全性、可观测性、性能优化等方面都还有不少空间。

如果你的团队正在构建 Agent 基础设施，现在开始关注 MCP 是一个不错的时机。但也要清楚：协议解决的是连接问题，不解决「该连接什么」的问题。选对工具、控制好上下文，依然是应用层的核心功课。