MCP 模型上下文协议
Function Calling 解决了「模型怎么决策调用」，却留下一个更麻烦的问题：每个工具都要为每个 AI 应用单独接线——同样的数据库工具，ChatGPT 接一遍、Claude 接一遍、自己的应用再接一遍，接口各写…
Function Calling 解决了「模型怎么决策调用」，却留下一个更麻烦的问题：每个工具都要为每个 AI 应用单独接线——同样的数据库工具，ChatGPT 接一遍、Claude 接一遍、自己的应用再接一遍，接口各写各的，形成工具孤岛。MCP（Model Context Protocol，模型上下文协议）在 2024 年 11 月由 Anthropic 开源，目标就是做「工具的 USB 接口」：用统一的方式让大模型连接外部工具、数据源和服务。它最重要的贡献，是让工具可以跨 AI 应用复用，推动社区生态发展。这一章讲清楚 MCP 解决什么、架构怎么设计、以及它在 2026 年的生态位置。完整的工程实践见 Agent 核心 11 · MCP 全景。
1. 演进脉络：从工具孤岛到统一协议
1.1 痛点（2023-2024）：N×M 的连接噩梦
随着 Function Calling 普及，每个 AI 应用都要实现自己的工具接入层：应用 A 的数据库连接器、应用 B 的数据库连接器、应用 C 的……工具开发者要为每个平台各写一遍适配；应用开发者每接入一个工具，都要处理一套新协议。生态被割裂成一个个孤岛——这就是经典的 N×M 集成问题（N 个应用 × M 个工具）。
一个典型画面：A 团队做「异常请求 AI 归因」，B 团队做「异常指标自动告警」，两边都需要同一个能力——查日志并让模型分析。没有统一协议时，同样的日志工具每个团队都要各接一遍、各写一遍提示词。MCP 要消灭的，正是这种「同一个工具反复接线」的重复开发。
1.2 标准化（2024.11）：MCP 开源
2024 年 11 月 25 日，Anthropic 发布 MCP 并开源，提出一个类比：MCP 之于 AI 应用，如同 USB 之于外设——一个通用接口，插上就能用。
核心设计（与 Function Calling 的分工）：
┌─────────────────────────────────────────────┐
│ AI 应用（Host：Claude Desktop、IDE、自研应用…） │
│ ┌─────────────┐ MCP Client ┌────────┐ │
│ │ LLM + 提示词 │ ◄───────────────► │ MCP │ │
│ │ + Function │ 协议 │ Server │ │
│ │ Calling │ └───┬────┘ │
│ └─────────────┘ │ │
└─────────────────────────────────────┼────────┘
▼
工具/数据源/服务
（数据库、文件、API、浏览器…）
- Host：承载 AI 应用的主体（Claude Desktop、Cursor、自研 Agent 等）
- Client：Host 内置的协议客户端，负责与 Server 连接
- Server：工具/数据源的适配层——把任意工具包装成统一协议暴露给模型
1.3 生态爆发（2025-2026）：事实标准的形成
MCP 开源后迅速成为事实标准，关键节点：
- 2025 年 3 月，OpenAI 宣布官方支持 MCP；Google 也加入
- 主流框架（LangChain、LangGraph）与开发工具（IDE、CI）纷纷原生支持
- MCP 生态形成：官方 Registry、数千个社区 Server、各语言的 SDK 齐全
- 「MCP Server」成为工具接入的新单位——写一次，处处可用
2. 核心概念：MCP 在协议栈中的位置
把 2026 年的 Agent 工具体系看成四层，MCP 的位置一目了然：
| 层 | 回答的问题 | 代表 |
|---|---|---|
| 决策层 | 模型什么时候调用、传什么参数 | Function Calling（第 05 章） |
| 连接层 | 工具如何统一接入、跨应用复用 | MCP（本章） |
| 封装层 | 一整套能力如何打包复用 | Agent Skill（第 10 章） |
| 编排层 | 多个能力如何协同完成长任务 | Agent / Harness（第 07/12 章） |
MCP 的三个设计亮点：
- 传输无关：本地走 stdio，远程走 HTTP/SSE，同一套协议抽象
- 能力三件套：Tools（可执行操作）、Resources（可读数据）、Prompts（可复用模板），覆盖工具接入的主要形态
- 权限可控：Server 可声明所需权限，Host 侧做授权管理，为安全边界留出工程空间
3. 关键认知：MCP 为什么重要
- 生态正反馈：写一个 MCP Server，Claude、Cursor、自研 Agent 全都能用——工具开发者的投入回报变大了，生态因此爆发。这是「标准协议」最核心的价值
- 解耦了工具与模型：工具不再绑定某个模型厂商的私有协议。换模型不换工具，换工具不换应用
- 下沉为基础设施：2026 年「MCP 兼容」已是工具类产品的默认卖点，如同当年的「支持 REST API」
注意事项（常被低估的部分）： MCP 是传输与接入标准，不负责安全——模型对工具的访问权限、敏感数据的暴露边界，仍需应用层设计（第 12 章 Harness 的职责之一）。
4. 现状与趋势（2026）
- MCP Registry 成为工具分发渠道：发现、安装、版本管理一体化
- MCP + Skill 的组合：Skill 描述「能力包」、MCP 提供「执行通道」，是 Agent 能力复用的主流组合（第 10 章）
- 多 Host 管理工具：同一组 Server 被多个应用共享，权限与审计成为企业部署的焦点
- 协议竞争基本结束：2026 年讨论的不是「MCP 会不会赢」，而是「MCP 的边界画在哪里」
5. MCP vs A2A：两个容易混淆的协议
2025 年起，与 MCP 一起频繁出现的新缩写是 A2A（Agent2Agent，智能体间通信协议）。两者名字都带「协议」，但解决的问题完全不同——MCP 连的是「Agent ↔ 工具」，A2A 连的是「Agent ↔ Agent」：
| 维度 | MCP（本章） | A2A |
|---|---|---|
| 连接对象 | Agent 与工具/数据源 | Agent 与 Agent |
| 类比 | USB（外设接口） | 电话簿 + 电话（人与人通信） |
| 解决 | 工具接入孤岛（N×M 问题） | 跨系统 Agent 协作发现与调用 |
| 提出方 | Anthropic（2024.11 开源） | Google（2025.04 提出，后移交 Linux 基金会） |
| 典型场景 | Claude 接数据库、IDE 接浏览器 | 甲公司的客服 Agent 调用乙公司的订单 Agent |
理解两者的关系：先有 MCP 让 Agent「有手」，再有 A2A 让 Agent「有同事」。工程上两者互补而非竞争——一个系统可以同时用 MCP 接工具、用 A2A 对接外部 Agent。
延伸阅读
- 官方文档：《Model Context Protocol 介绍》——协议定义与快速上手
- 深度版：Agent 核心 11 · MCP 全景（Server/Client/Agent 接入的完整工程）
- 关联章节：Agent 核心 12 · 多 Agent 与选型策略（Skill vs MCP 的选型）