开放标准 // Model Context Protocol 访问官网 ↗
  • 开放标准
  • JSON-RPC 2.0
  • 客户端-服务端
  • 工具/资源/提示
  • Anthropic 发起
  • 跨模型通用

当每个 AI 应用都要为每套系统各写一遍接口时，Model Context Protocol 想把这件事变成「插上就能用」

大模型很强，但真正让它干活的是背后的数据与工具。过去每接一个数据库、每接一个 SaaS，工程团队就得重写一套私有适配；Model Context Protocol（简称 MCP）要做的，是把「AI 应用 ↔ 外部能力」这一层统一成一套开放协议，让同一条能力只需实现一次，就能被任何兼容的客户端调用。

一句话认识它：Model Context Protocol（MCP，模型上下文协议）是 Anthropic 于 2024 年 11 月 25 日开源并发布的开放标准[1]，它定义了 AI 应用（Host）如何通过统一的客户端-服务端架构，把外部工具、数据源与提示模板以标准化方式接入大语言模型；协议本身基于 JSON-RPC 2.0 消息格式，被称为「AI 领域的 USB-C 接口」[2]，目标是把原本 M×N 的点对点集成难题，收敛为 M+N 的通用连接[3]。

为什么要有 MCP：被忽视的「最后一公里」集成难题

很多人以为，给大模型接上外部工具只是「写几个函数」的事。现实要麻烦得多：在 MCP 出现之前，如果你要让 5 个 AI 应用分别连上 10 个外部系统，理论上需要编写 50 套彼此独立的私有集成，每一套都要单独处理鉴权、错误语义、数据格式与协议约定。更糟的是，这些适配几乎无法在不同模型或不同应用之间复用——给 Claude 写的 GitHub 连接器，换到 GPT 或 Gemini 上往往要重新写一遍[3]。

Anthropic 把这种局面称为 M×N 的集成问题：模型数量乘以工具数量，集成成本随之平方级膨胀。MCP 的核心主张非常朴素——把「工具如何被描述和调用」标准化，让一个 MCP 服务端（Server）只实现一次，任何兼容的 MCP 客户端（Client）都能直接发现并使用它。于是 50 条私有管道，被压缩成 5 个客户端加 10 个服务端，也就是 15 条连接[1]。这正是「USB-C 接口」比喻的由来：形状统一了，两端设备各显神通。

协议骨架：Host、Client 与 Server 各司其职

MCP 采用经典的三角色架构，把「谁在跑模型」「谁在维持会话」「谁在提供能力」彻底分开，从设计上避免不同服务端互相污染。

ROLE · 01

Host（宿主应用）

真正运行大语言模型的应用本体，例如 Claude Desktop、各类 IDE 插件、自研 Agent 运行时。Host 负责发起连接、承载对话，并为每个 Server 拉起独立的 Client 实例，让服务端彼此隔离[2]。

ROLE · 02

Client（客户端连接器）

内嵌在 Host 内部的瘦连接器，每个 Server 对应一个 Client。它负责协议握手、能力协商与消息路由，把服务端的原语翻译成宿主模型能理解的调用格式，自身不承载业务逻辑。

ROLE · 03

Server（能力服务端）

轻量级独立进程或远程服务，把某个具体系统（数据库、网盘、代码仓库、API）的能力包装成标准原语暴露出来。一个 Server 可以同时提供工具、资源与提示三类能力[3]。

为什么隔离很重要：每个 Server 独占一个 Client，意味着某个服务端的故障、权限或上下文不会泄漏到另一个服务端；这种「一服务一连接」的边界，是 MCP 能够安全承载多数据源的关键设计之一，也让平台团队可以针对单个 Server 做审计与治理。

五大核心原语：协议真正「能说的语言」

MCP 的灵魂在于它定义了若干原语（Primitives）——即客户端与服务端之间可互相提供的能力单元。按控制主体，它们被清晰地分层：哪些由模型决定、哪些由应用决定、哪些由用户触发。这种控制权的划分，直接决定了系统的安全性与可控性。

SERVER PRIMITIVE

Tools（工具）

模型控制。可被模型主动调用的可执行函数，例如查询数据库、提交工单、发送邮件。每个工具都带有名称、描述与一份定义参数的 JSON Schema，模型据此生成带参数的调用，由服务端执行并返回结构化结果[3]。

SERVER PRIMITIVE

Resources（资源）

应用控制。以 URI 标识的只读数据，例如文件内容、数据库记录、API 响应、Git 历史。是否把某份资源注入上下文，由宿主应用决定，而非模型随意抓取，从而降低敏感数据被无意带进对话的风险[3]。

SERVER PRIMITIVE

Prompts（提示模板）

用户控制。可复用的交互模板，例如代码审查、事故复盘、周报生成。通常由用户在界面上显式触发（如斜杠命令），把固定句式与上下文注入对话，属于「人主动选用」的工作流[3]。

CLIENT PRIMITIVE

Sampling（采样补全）

服务端反向请求模型。允许服务端向宿主的 AI 应用请求一次语言模型补全，使服务端作者无需内置模型 SDK 即可获得推理能力。该请求走多轮往返模式，且由客户端掌控具体使用哪个模型、是否需用户确认[3]。

CLIENT PRIMITIVE

Elicitation（信息征询）

服务端向用户追问。当操作缺少必要输入时，服务端可通过 elicitation 向用户索取补充信息或确认，而不是默默失败。它同样走多轮往返模式，把「缺参数」变成一次可读的人机交互。

此外协议还有通知（Notifications）机制：服务端可用 JSON-RPC 2.0 通知主动向客户端推送变更（例如可用工具列表更新），无需等待请求；以及可选的 Tasks 扩展，为耗时任务返回可轮询的句柄。控制权的分流值得反复强调——模型能调用工具，但只有应用决定哪些资源进入上下文，只有用户触发提示模板，这正是 MCP 把「能力开放」与「安全边界」同时锁死的方式。

两种传输方式：本地用 stdio，远程用 Streamable HTTP

原语要在网络上跑起来，离不开传输层。MCP 当前主推两种 Transport，选择取决于服务端是本地进程还是远程服务。

TRANSPORT · 本地

stdio（标准输入/输出）

Host 把 Server 作为本地子进程拉起，双方通过标准输入/输出交换 JSON-RPC 消息。没有网络端口、延迟最低，是访问文件系统、本地 Git 与本地数据库的默认选择；它直接继承启动该进程的用户账户信任。

TRANSPORT · 远程

Streamable HTTP

Server 作为远程 HTTP 端点存在，客户端用 POST 发请求、可借 SSE 接收服务端推送。它取代了早期的 HTTP+SSE 传输，是面向多用户、托管式服务端的方案，需要真正的授权体系（规范在 HTTP 传输上构建于 OAuth 2.1 模式）[4]。

一次完整的 Client-Server 通信工作流

把上面的原语与传输串起来，下面是一条典型的「模型借由 MCP 调用外部能力」的端到端流程。所有在线路上流动的内容都是 JSON-RPC 2.0——请求、响应、通知，协议刻意保持「无聊」，价值正在于人人都说同一种无聊的话。

  1. 拉起与握手：Host 启动后为每个 Server 创建独立 Client，双方通过初始化（initialize）交换协议版本、能力声明与身份标识，确认彼此兼容后才进入后续交互。
  2. 能力发现：Client 用 tools/list、resources/list、prompts/list 等列出方法，向 Server 询问「你能提供什么」，拿到名称、描述与参数 Schema，这套清单可以是动态变化的。
  3. 注入上下文：工具的描述与 Schema 被放进模型上下文，资源由应用按策略拉入，提示模板等用户触发后再注入，模型此时「看见」了可用能力。
  4. 模型决策：面对用户问题，模型判断需要调用某个工具，并产出满足 Schema 的参数（例如 orderId 的值），以结构化调用而非自然语言描述的形式发出。
  5. 服务端执行：Client 把调用路由到对应 Server，Server 真正执行业务逻辑（查库、发请求、写文件），返回文本、JSON、图像或错误——是数据，不是散文。
  6. 结果回流：执行结果作为工具结果重新进入对话，模型读取后要么给出最终答复，要么基于新信息继续调用下一个工具，直到任务闭环。

关于「无状态 vs 有状态」：协议版本演进中对生命周期管理的表述有所调整，但核心不变——每次请求都携带协议版本与本次相关的能力信息，使服务端可以逐请求独立处理；能力协商则通过初始化/发现阶段完成，保证客户端不会假设服务端不支持的特性。

MCP 与 Function Calling 到底是什么关系

这是被问得最多、也最容易混为一谈的一组概念。一句话区分：Function Calling 是模型侧的能力，MCP 是集成层的协议，两者处在不同层级、需要互相配合。

Function Calling（函数调用 / 工具使用）

  • 本质：大模型 API 内置的一项能力，模型经过微调后能判断「何时需要外部工具」，并输出结构化的函数名与参数 JSON。
  • 边界：它只解决「模型决定调用什么、填什么参数」，至于这些函数由谁暴露、如何被发现、结果怎么回来，它一概不管。
  • 痛点：工具定义常写死在应用代码里，每次请求都要带上 Schema；换一个模型供应商，格式往往要重写。

Model Context Protocol（模型上下文协议）

  • 本质：位于 Function Calling 之上一层的开放标准，把「服务端如何宣告能力、客户端如何发现并调用」统一起来。
  • 边界：它不替代 Function Calling，而是把工具从客户端代码里解耦：工具逻辑住在独立 Server 中，Client 启动时自动发现并翻译成模型期望的格式。
  • 收益：同一个 MCP Server 写一次，任何兼容客户端都能用；模型依旧在做 Function Calling，变的只是工具不再与应用强耦合。

一个形象的类比：Function Calling 是汽车的油门与变速箱，是驱动车辆移动的原始机制；MCP 是 USB-C 标准，是约定好的接口形状，让任意充电器、显示器、硬盘都能插进任意笔记本而无需定制线缆。你永远需要油门，但当你要连的设备超过一个，USB-C 接口就必不可少。需要提醒的是，如果你的场景只是「一个应用、两三个自家工具」，直接手写 Function Calling 往往更简单；只有连接数开始爬升、需要跨应用复用或借力现成生态时，引入 MCP 才物有所值。

集成场景对照表：什么时候该用什么

协议好不好，要看它落在具体场景里顺不顺手。下面把几类典型集成场景对照起来，帮助你判断 MCP 是否合适、该用哪种传输、要留意什么。

集成场景推荐传输典型原语控制权归属关键注意点
本地代码助手读项目stdioResources + Tools模型调工具 / 应用管资源继承本地用户信任，无需网络鉴权，但权限宜最小集
托管式多用户 SaaS 接入Streamable HTTPTools + Prompts用户触发提示 / 平台审计必须上 OAuth 2.1 级授权，避免把单用户凭证泄露给其他租户
企业知识库问答HTTP 或 stdioResources 为主应用决定上下文资源入上下文由应用把关，防止敏感文档被无意带入对话
需要模型在工具内再推理二者皆可Sampling服务端反向请求模型客户端掌控具体模型与是否需用户确认，避免无声推理
缺参数时补全信息二者皆可Elicitation服务端追问用户把「缺参数即失败」变成可读的人机交互，提升成功率
单一应用两三个私有工具不必引入Function Calling应用自身直接手写函数调用更轻，强上 MCP 反而增加无谓基础设施

安全与治理：协议开放了能力，边界要靠部署守住

MCP 本身只是一个协议，安全与否取决于你怎么部署。因为每一个 MCP Server 都是通往真实系统的一扇门，风险往往出现在落地环节而非规范文本。

01

权限过宽：一个本只需读文件的 Server 如果被赋予写权限，破坏面会急剧放大。原则永远是授予完成任务所需的最小权限，并按资源边界（Roots）限定可操作目录。

02

工具结果注入：从外部取回的数据里可能藏着隐藏指令，借「提示注入」悄然引导 Agent 行为。对任何工具返回内容都应保持不信任，必要时做隔离与净化。

03

仿冒与替换：名称相近的「山寨工具」可能悄悄顶替受信任工具。对第三方 Server 的来源、代码与运行时要做校验，不随便接入来路不明的服务端。

04

缺乏审计：调用散落在各应用日志里，事后难以复盘。通过统一网关与日志记录每一次「谁、在何时、以何参数」调用了什么，是平台团队能做的关键治理动作。

生态与采用时间线：从一家发起，到全行业靠拢

MCP 发布第一年里的采用速度，在同类协议里相当罕见。下面按时间梳理几个关键节点，便于理解它如何从一个厂商提案变成事实标准。

  1. 2024-11-05 规范初版：定义客户端-服务端模型、JSON-RPC 消息，以及 tools / resources / prompts 三大原语，奠定协议底座[4]。
  2. 2024-11-25 Anthropic 发布并开源：同步放出 Python 与 TypeScript SDK，以及 Google Drive、Slack、GitHub、Git、Postgres 等参考 Server[1]。
  3. 2025-03-26 规范修订 + OpenAI 采用：引入基于 OAuth 2.1 的授权框架，用更灵活的 Streamable HTTP 取代旧 HTTP+SSE，并新增工具注解等能力；同日 OpenAI 宣布在 Agents SDK 中支持 MCP，是另一家前沿实验室的首次采用[5]。
  4. 2025-04-09 Google 拥抱：Google DeepMind CEO Demis Hassabis 表示 Gemini 模型与 SDK 将支持 MCP，称其「正迅速成为智能体时代的一项开放标准」[6]。
  5. 2025-06-18 规范再修订：加入结构化工具输出、Elicitation（服务端向用户征询输入）、工具结果中的资源链接等能力，并明确 Server 作为 OAuth 资源服务器的定位[7]。
  6. 后续治理移交：随着采用扩大，社区围绕 MCP 建立起注册目录（MCP Registry）等发现机制；规范仓库持续作为协议单一事实来源维护于 GitHub[8]。

为什么它赢得如此快：通常互相竞争的厂商很少会为对手的标准背书，但 OpenAI、Google DeepMind、Microsoft、AWS 等先后接入 MCP，说明「统一连接层」确实切中了行业痛点。正如业界把 MCP 类比于描述 API 的 OpenAPI——它不替你实现业务逻辑，却让「怎么接」这件事第一次有了通用答案。

常见问答

MCP 是框架、库，还是协议？

它是协议，不是框架也不是某个具体的库。Anthropic 发布的是一套开放标准与互操作规范，配套提供 Python、TypeScript、C#、Java 等 SDK 与参考实现，但任何人都可以不依赖特定厂商、按规范自行实现客户端或服务端。

MCP 会取代 Function Calling 吗？

不会。两者是不同层的互补关系：Function Calling 是模型决定「调哪个函数、填什么参数」的能力，MCP 是之下的连接标准，负责工具如何声明、被发现与返回结果。模型依然在做 Function Calling，只不过工具不再与应用代码强耦合。

Tools、Resources、Prompts 三者最大的区别是什么？

区别在于「谁说了算」：Tools 由模型控制、可主动执行动作；Resources 由应用控制、是按需拉入上下文的只读数据；Prompts 由用户控制、是显式触发的工作流模板。这种控制权的分层，正是协议兼顾开放与安全的关键。

stdio 和 Streamable HTTP 该怎么选？

本地工具、桌面助手、访问本机文件与数据库，优先用 stdio，延迟低且继承本地账户信任；如果是多用户、托管式的远程服务，则用 Streamable HTTP，并必须配套 OAuth 2.1 级别的真实授权，避免跨租户凭证泄露。

我没有那么多工具，还有必要上 MCP 吗？

未必。如果你的场景是单一应用、两三个自家函数，直接手写 Function Calling 往往更轻；只有当连接数量开始爬升、需要跨应用复用，或想借力现成的 MCP Server 生态时，引入 MCP 才真正划算。

使用 MCP 时最该警惕的安全问题有哪些？

重点有四类：权限给得过大、工具返回内容里的提示注入、名称相近的仿冒工具顶替受信任服务、以及调用缺乏审计日志。落地时坚持最小权限、对返回内容保持不信任、校验第三方 Server 来源，并对每次调用做可追溯记录。

MCP 目前被哪些主流厂商采用？

自 2024 年底发布后，OpenAI（Agents SDK、ChatGPT 桌面端与 Responses API）、Google DeepMind（Gemini 模型与 SDK）、Microsoft（Copilot Studio、Azure AI Foundry、Semantic Kernel、Windows 等）、AWS（开源 MCP Server 套件）以及众多 IDE 与代码工具均已接入或提供官方支持。

参考资料

  1. 来源：Anthropic 官方公告——Introducing the Model Context Protocol（2024-11-25 发布并开源，含 SDK 与参考 Server）：https://www.anthropic.com/news/model-context-protocol
  2. 来源：维基百科——Model Context Protocol（协议定义、架构角色、采用与反响的第三方概述）：https://en.wikipedia.org/wiki/Model_Context_Protocol
  3. 来源：Model Context Protocol 官方文档——Architecture 架构总览（Host/Client/Server、原语与传输说明）：https://modelcontextprotocol.io/docs/concepts/architecture/
  4. 来源：Model Context Protocol 官方规范——Specification（JSON-RPC 2.0、生命周期、Streamable HTTP 与 OAuth 2.1 等）：https://modelcontextprotocol.io/specification/
  5. 来源：TechCrunch——OpenAI adopts rival Anthropic's standard for connecting AI models to data（2025-03-26 OpenAI 采用 MCP）：https://techcrunch.com/2025/03/26/openai-adopts-rival-anthropics-standard-for-connecting-ai-models-to-data/
  6. 来源：TechCrunch——Google to embrace Anthropic's standard for connecting AI models to data（2025-04-09 Google DeepMind 支持 MCP）：https://techcrunch.com/2025/04/09/google-says-itll-embrace-anthropics-standard-for-connecting-ai-models-to-data/
  7. 来源：VentureBeat——The open source Model Context Protocol was just updated — here's why it's a big deal（2025 规范修订要点）：https://venturebeat.com/ai/the-open-source-model-context-protocol-was-just-updated-heres-why-its-a-big-deal/
  8. 来源：GitHub——modelcontextprotocol/modelcontextprotocol（协议规范、Schema 与参考实现的单一事实来源仓库）：https://github.com/modelcontextprotocol/modelcontextprotocol

青衣网络 AI 观察团队 · 最后更新 2026-08-25　|　本文基于 Model Context Protocol 官方文档、Anthropic 公告与公开技术媒体报道整理，用于帮助读者理解该开放标准本身的定位、原语与集成方式；协议版本、采用范围与治理安排随时可能演进，具体技术细节与最新修订请以官方规范与文档为准。