稀饭

MCP：给 AI 插上 USB-C——模型上下文协议是什么、怎么工作

Anthropic 推出的开源标准 MCP 全解析：Host/Client/Server 三方架构、Tools/Resources/Prompts 三大原语、JSON-RPC 无状态数据层、从发现到执行到通知的完整交互，以及它和 LangGraph / create_agent 在 Agent 生态里的分工。

  • AI
  • Agent
  • MCP
  • 协议
  • 工具
  • 开源标准

前几篇把 LangGraph、create_agent、Deep Agents 讲了个遍—— 但那些都还停在"Agent 自己怎么组织"的层面。这篇换一个视角，讲 Agent 怎么接入外面的世界：MCP（Model Context Protocol）。 它可能是过去一两年里，对"AI 应用如何连接外部系统"影响最深的一个开源标准。

一、它是什么：给 AI 应用的 USB-C 接口

MCP 是一个开源标准，用来把 AI 应用连接到外部系统。官方定义：

MCP 是一个开源标准，用于连接 AI 应用与外部系统。

借助 MCP，像 Claude、ChatGPT 这样的 AI 应用可以连接到数据源（本地文件、数据库）、 工具（搜索引擎、计算器）和工作流（专门的提示词），从而获取关键信息并执行任务。 官方给了个极其贴切的比喻：

MCP 之于 AI 应用，就像 USB-C 之于电子设备。USB-C 提供了一种标准化的连接方式，MCP 则提供了一种标准化的、让 AI 应用连接外部系统的方式。

在 MCP 之前，每个 AI 应用接每个外部系统，都要单独写一套集成——一个点对点的"线缆"。 有了 MCP 这个统一标准，写一次，到处都能插。官方列了几个能激发想象力的例子：

  • Agent 能访问你的 Google Calendar 和 Notion，变成更懂你的私人助理；
  • Claude Code 能根据一个 Figma 设计稿，生成一整个网页应用；
  • 企业聊天机器人能连上组织内多个数据库，让用户用聊天的方式做数据分析；
  • AI 模型能在 Blender 里创建 3D 设计，并直接通过 3D 打印机打出来。

生态支持已经非常广泛：Claude、ChatGPT、Visual Studio Code、Cursor 等 AI 助手 和开发工具全都支持 MCP——"构建一次，随处集成"不是口号，是真的在发生。

二、核心架构：Host、Client、Server 三方角色

MCP 采用客户端-服务器架构，有三个关键角色：

角色是什么例子
MCP HostAI 应用本身，协调和管理一个或多个 MCP ClientClaude Code、VS Code
MCP Client与某个 MCP Server 保持连接、从中获取上下文的组件VS Code 运行时实例化的 client 对象
MCP Server向 Client 提供上下文的程序Filesystem、Sentry、GitHub 服务器

关键的理解点是：Host 每连接一个 Server，就实例化一个 Client。 比如 VS Code 连了 Sentry 服务器，就有一个 Client 对应它；再连本地文件系统服务器， 就再实例化一个 Client。每个 Client 与对应的 Server 之间是一条专用连接。

MCP Server 不在乎在哪运行——本地、远程都可以：

  • 本地服务器：用 stdio 传输，和 Host 在同一台机器上跑进程间通信，零网络开销。比如 Claude Desktop 启动的本地文件系统服务器；
  • 远程服务器：用 Streamable HTTP 传输，走 HTTP POST + Server-Sent Events 流式，一个服务器服务很多 Client。比如官方 Sentry 服务器，跑在 Sentry 平台上。

传输层之外，MCP 的核心是数据层——基于 JSON-RPC 2.0 的交换协议， 定义了消息结构、能力发现、以及最关键的三大原语（primitives）。

三、三大原语：Tools、Resources、Prompts

这是 MCP 最重要的概念。三个原语定义了 Server 能向 AI 应用提供什么，官方用一张表讲得最清楚：

原语作用由谁控制例子
ToolsLLM 可以主动调用的函数，做动作（写库、调 API、改文件）模型（自动发现并调用）查航班、发消息、建日历事件
Resources只读的数据源，作为上下文提供给 AI（文件内容、数据库结构）应用（决定何时取用）读文档、访问知识库、读日历
Prompts预构建的指令模板，引导模型配合特定工具与资源工作用户（显式触发）规划假期、总结会议、起草邮件

每个原语都有配套的协议方法：

  • Tools：tools/list 发现、tools/call 执行；
  • Resources：resources/list、resources/templates/list、resources/read；
  • Prompts：prompts/list、prompts/get。

Tools 是"动手"——每个工具是带 JSON Schema 输入校验的单一操作，模型根据对话上下文决定何时调用， 但执行前可能需要用户同意；Resources 是"读资料"——每个资源有唯一 URI（如file:///path/to/doc.md）和 MIME 类型，支持固定 URI 和带参数的模板 （如 weather://forecast/{city}/{date}）；Prompts 是"给模板"—— 参数化指令模板，用户通过斜杠命令或菜单显式触发，比如 /plan-vacation。

官方文档用了一个"旅行规划"的例子把三者串起来：用户触发 plan-vacation prompt， 传入巴塞罗那、日期、预算等参数；AI 应用读入日历、偏好、历史行程等 Resources 拿到上下文； 模型再调用查航班、查天气、订酒店、建日历事件、发确认邮件等一系列 Tools——一个跨多个 MCP 服务器、可能要花几小时的行程，几分钟就订完了。这就是 MCP 原语协作的真实形态。

四、一个完整交互：从发现到执行到通知

MCP 协议层是无状态的——每个请求都自带协议版本、能力声明和身份信息（都在 _meta 字段里）， 服务器不需要记住之前的请求就能独立处理。一次典型的客户端-服务器交互长这样：

  1. 发现（Discovery）：客户端发 server/discover，一次性拿到服务器支持的协议版本、能力和身份。响应可缓存，不用每次重发；
  2. 工具发现：客户端发 tools/list，拿到所有可用工具及其输入 schema——name、title、description、inputSchema；
  3. 工具执行：模型决定用工具时，客户端发 tools/call，带工具名和参数，服务器返回结构化结果（文本、图片、资源等可组合的 content 数组）；
  4. 实时通知：工具列表变化时，服务器通过 notifications/tools/list_changed 推送通知——但通知是opt-in 的，客户端要先发 subscriptions/listen 订阅，且服务器要声明过 "listChanged": true。

一个值得注意的细节：这版协议（2026-07-28）里，客户端原语做了一次更新换代—— 新增了 elicitation（服务器通过 elicitation/create 向用户请求更多信息或确认）， 取代了旧的 sampling（服务器向客户端的 AI 应用请求模型补全，现已标记 deprecated）。 官方建议新实现直接集成 LLM provider API，而不是走 sampling。

五、和 Agent 生态的关系：为什么它是"基础设施"

把 MCP 放进前面几篇的语境里看，它的位置很特别：

  • LangGraph / create_agent / Deep Agents 解决的是"Agent 内部怎么组织"——控制流、状态、harness；
  • MCP 解决的是"Agent 的外部接口长什么样"——任何 Agent，只要连上 MCP 服务器，就能拿到一套标准化的工具、资源和提示词。

前面几篇里那些"工具"，在 MCP 的世界里有了标准化的定义方式：工具就是带 schema 的函数， 资源就是带 URI 的数据，提示词就是带参数的模板——同一套语义，任何 Host 都能理解。 这就像之前写的 Deep Agents 内置虚拟文件系统一样，MCP 把"接入外部世界"这件事标准化了， 只是它标准化的范围更大、而且是跨厂商的。

我的收获

  1. "USB-C" 的比喻精准得可怕——MCP 解决的不是"技术问题"，而是"生态问题"：当每个 AI 应用都用同一套协议连接外部系统，工具生态才开始有复利。这和 USB-C 取代一堆专用充电线的逻辑一模一样。
  2. Tools / Resources / Prompts 的三分法，是"Agent 能力"的清晰拆解——动作用 Tools、上下文用 Resources、模板用 Prompts，对应"模型决策 / 应用取用 / 用户触发"。想清楚你的 Agent 需要什么，先想清楚这三类各是什么。
  3. "无状态 + 每请求带元数据"是个被低估的设计——MCP 每个请求都自带协议版本和能力声明，服务器无需维护会话状态，这让水平扩展和缓存都变得简单。很多协议是为"连接"设计的，MCP 是为"可扩展"设计的。
  4. 安全是 MCP 的头等议题——工具可被模型自动调用，意味着权限和审批不是可选项。MCP 的 opt-in 订阅、工具执行前的用户同意、权限规则，和之前写的 Deep Agents 文件系统权限、ECC 的 AgentShield 是同一条主线：Agent 越能动手，越要管住它。

想深入了解，官方文档在modelcontextprotocol.io/docs/2026-07-28/getting-started/intro， 架构细节看 architecture 和server concepts。 顺着这条路下去，下一站就是自己动手写一个 MCP 服务器——把你自己的数据源和工具，用标准接口暴露给所有 AI。