科普 · Agent 背后的通用插口

Agent 的“手”：
MCP 协议科普

一个 AI Agent 再聪明，如果连不上你的文件、日历、数据库和业务系统，也只能纸上谈兵。2024 年 11 月，Anthropic 公开了一个叫 MCP（Model Context Protocol，模型上下文协议）的开放协议，目标就是给“Agent 接工具”这件事定一个统一标准。官方把它比作 AI 应用的 USB-C 接口：插上去就能用，不用每换一个设备重做一根线。

资料基准日：2026 年 11 月 10 日 · 约 12 分钟读完 · 协议细节以官方文档 modelcontextprotocol.io 为准

先说结论

MCP 是 Anthropic 在 2024 年 11 月 25 日公开的开放协议，2025 年 12 月捐给了 Linux 基金会旗下的 Agentic AI Foundation，现在由多家厂商共同维护，不属于任何一家公司。

它解决的是一个很具体的问题：Agent 想用外部工具和数据，不用每对组合都单独写一份对接代码——工具方写一次，Agent 方接一次，到处通用。

记住两句话：MCP 只管“怎么连”，不管“该不该干”——让 Agent 发消息、删文件、付钱，仍要经过你的审批；MCP 本身不收费、不卖服务，它只是一份公开的规矩。

一先从一个麻烦说起：没有统一插口的日子

假设公司想让 AI 助手帮你办事：查日历、读 CRM 里的客户资料、搜知识库。没有统一标准之前，是这样接的：

助手 A 要查日历，开发团队给它写一份对接代码；A 要读 CRM，再写一份；A 要搜知识库，再写一份。然后换一个助手 B——前面写的全部作废，重写三份。公司里有 3 个助手、要接 3 个工具，就是 3 × 3 = 9 份对接代码，而且每换一个助手、每加一个工具，都要再写一轮。

这就像每买一个电器都要换一种插座，或者每认识一个人都要先学一门外语。活不是干不了，而是每接一次都要从头干一遍，越接越贵、越接越慢。

图 1 · MCP 解决的核心问题：把 N × M 份对接代码，变成 N + M 次接入。

MCP 就是来终结这种重复劳动的。它不是一款产品，也不是一个模型，而是一份公开的规矩：只要工具方和 Agent 方都按这份规矩办事，插上去就能通。

二MCP 是什么：AI 应用的 USB-C

MCP（Model Context Protocol，模型上下文协议）是一份开放标准，规定 AI 应用怎么向外部系统要数据、怎么调用工具、怎么复用提示词模板。官方介绍里写了一句很直白的比喻（意译）：“就像 USB-C 给电子设备提供了统一的连接方式，MCP 给 AI 应用提供了统一的连接方式。”

USB-C 的好处不需要解释：不管手机、电脑还是耳机，同一根线都能充。MCP 想做的就是同一件事：不管 Agent 背后是哪个公司的模型，也不管工具是文件、日历还是数据库，同一套接法，到处都能用。

谁做的？现在归谁管？

2024 年 11 月 25 日，Anthropic 公开 MCP，规范与开发包全部开源，早期合作方包括 Block、Apollo，以及 Zed、Replit、Sourcegraph 等开发工具。
2025 年 3 月，OpenAI 宣布采用 MCP，随后 Google、微软等厂商跟进；Claude、ChatGPT、VS Code、Cursor 等产品都已支持。
2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会旗下的 Agentic AI Foundation（由 Anthropic、Block、OpenAI 共同发起），从“一家公司的项目”变成了“多家厂商共管的中立基础设施”——和 Linux、Kubernetes 一样的治理模式。

“开放”在这里有三层意思：规矩公开（任何人都能按规矩做产品）、没有授权费（用 MCP 不用交钱）、不被一家公司卡脖子（捐给基金会之后，任何一家厂商都不能单方面改规矩）。

一个数字：Anthropic 在捐赠时称，MCP 官方开发包的每月下载量已超过 9,700 万次（2025 年 12 月，厂商公布的数字，未经独立核实）。不管这个数字准不准，有一点是实的：MCP 在一年多里从一个新协议变成了 Agent 接工具的默认做法。

三三件套：Host、Client、Server 怎么配合

MCP 的架构只有三个角色。记住它们各自是谁，整套东西就通了。

图 2 · MCP 的三件套：Host 管着一堆 Client，每个 Client 只连一个 Server，Server 替某个外部系统“站岗”。

Host（宿主）：你直接用的 AI 应用，比如 Claude Code、Cursor、Claude 桌面版、VS Code。它负责管着一堆连接，也负责最后把结果拿给你看、等你点头。
Client（客户端）：宿主里面、每个连接配一个的“联络员”。连几个 Server，就有几个 Client；每个 Client 只维持自己那一条连接。
Server（服务器）：真正干活的那头——一个小程序，替某个外部系统“站岗”。文件系统 Server 替你的电脑文件站岗，数据库 Server 替公司数据库站岗，GitHub Server 替代码仓库站岗。它先向 Client 报上“我能提供什么工具、什么数据”，再按吩咐执行。

配合起来是这样一趟：你提需求 → Host 把问题和“手头有哪些工具”一起交给模型 → 模型说“我要用查日历这个工具” → 对应的 Client 按规矩把调用发给 Server → Server 去日历里查 → 结果原路返回 → 模型结合结果回答你。

两种连线方式也值得分清：本地 Server跑在你自己电脑上，和 Host 之间直连（技术上叫 Stdio），比如文件系统这种；远端 Server在网上，用 HTTP 连、要登录（官方推荐 OAuth），比如公司内部系统这种。本地的快、不用联网；远端的能跨设备、能集中管。

四MCP 能给 Agent 的三样东西

一个 MCP Server 能提供的东西，协议里归为三类。分清它们，就知道 Agent 接上 MCP 之后到底多出了什么本事。

工具（Tools）：能动手的事

模型可以调用的“动作”：查、改、发、算。比如“查一下下周的日程”“给这张表加一行”“在 GitHub 上开一个 issue”。工具是 MCP 里最常用的一类，也是唯一能让 Agent“动手改东西”的一类——所以也是最需要审批的一类。

资源（Resources）：能读的数据

模型可以拿来当上下文的数据：文件内容、数据库记录、接口返回。比如数据库 Server 可以先把表结构（有哪些字段）当作资源交给模型，模型知道了表长什么样，查起来才不会瞎猜。资源是“只读”的：模型拿去看，不直接改。

提示词（Prompts）：现成的办事模板

存在 Server 里的“办事套路”：比如“按公司格式写周报”“按这个清单审合同”。Agent 随取随用，不用每次重新发明流程。对团队来说，这等于把“老员工的经验”写成了模板，新人（和新 Agent）照着做就行。

还有一个留给“人把关”的口子：协议里有一种叫“elicitation（征询）”的机制——Server 可以在执行前反过来问用户要补充信息、或者请用户确认。也就是说，“先问人”这件事不是各家产品自己发挥，而是写进协议里的标准动作。

五MCP 和“插件”有什么不一样

很多人第一次听 MCP，会问：这不就是插件吗？像，但不是一回事。插件是“某家店的会员卡”，MCP 是“通用的插座标准”。

维度	插件（Plugin）	MCP
是什么	某个产品自家的扩展方式	公开协议，多家厂商共用
谁定的规矩	这家公司自己定	开放规范，基金会共管
写一次能用几次	只在这一款产品里能用	任何支持 MCP 的应用都能接
跑在哪	通常跑在厂商的云端	本地 Server 跑在你自己电脑上；远端 Server 跑在服务商那
换工具要不要重学	换个产品要重写	换个 Agent 不用重写，接上就行
谁负责安全	厂商兜底，也由厂商说了算	你自己（和你的管理员）把关——协议不管审批

一句话记住：插件解决的是“在这一个产品里多一个功能”，MCP 解决的是“在所有产品里都能接上同一个工具”。两者不冲突——一个产品可以既有自己的插件商店、又支持 MCP；但对企业来说，MCP 的价值在于“不被一家产品绑住”：今天用 Claude，明天换 Cursor，工具不用重接。

六一次调用走完全程

把第三、四节合起来，看一次真实的工具调用是怎么走完的。以“帮我查一下下周三下午有没有空”为例：

连线：Host 启动，Client 问 Server“你是谁、你会什么”这一步叫发现（discovery）：Server 先报上自己的身份、支持的协议版本，以及它能提供的工具、资源和模板清单。
报菜：Server 回一张清单比如日历 Server 说：我有一个“查日程”的工具，要传“开始时间”和“结束时间”两个参数；还有一个“读日程详情”的资源。
点菜：模型看完清单，决定调用哪个工具模型读了你的问题和工具清单，决定调用“查日程”，参数是下周三下午。
上菜：Server 执行，把结果原路返回Server 去日历里查到结果，通过 Client 交回给 Host，再交给模型。
收尾：模型拿着结果回答你“下周三下午 3 点到 5 点是空的。”如果 Server 说“这个操作要你确认”，Client 会先回来问你，点了头才执行。

技术细节一句话带过：它们之间说的是一种叫 JSON-RPC 2.0 的通用“问答格式”——跟编程语言无关，Python 写的 Server、TypeScript 写的 Client 也能通话。普通读者不用记这个名字，知道“它们说同一种语言”就够了。

七企业接 MCP，要注意什么

MCP 让接工具变容易了，也让“接错工具”的代价变大了。容易接，不等于可以随便接。给企业列五条清单：

一 ·先分级：只读的先接，能写的后接

查日历、读文档这类只读的，先接；发消息、改数据、付钱这类能写东西的，后接，每类单独审批。别图省事一次全开。

二 ·先管“谁能看到什么”

MCP Server 能摸到多少数据，取决于你给它什么权限——给最小权限，别全开。接数据库的 Server，只给它读某几张表的权限，不要给整个库。

三 ·小心“被下毒的工具”

Server 是谁提供的？它的工具说明里有没有夹带指令——比如让模型偷偷把数据发出去？安全圈把这叫“工具投毒”，已有专门的防范清单。只接可信来源的 Server，定期复查；来路不明的 Server，再方便也别接。

四 ·审批别外包给协议

MCP 不替你做决定。发送、删除、付款这些动作，Host 那一侧的审批规则必须开着。协议只负责把调用送过去，“让不让它干”是你和你的管理员说了算。

五 ·记账与审计：留日志

谁调了哪个工具、什么时候、改了什么，要留日志；出问题才能查。没有日志的自动化，等于没有刹车的车。

八MCP 的边界：它不管什么

把 MCP 吹成万能钥匙就错了。它有明确的边界，知道边界，才知道该指望它什么、不该指望它什么。

不管模型聪明不聪明。那是模型的事。MCP 只负责把工具和数据送到模型面前，模型会不会用、用得对不对，协议管不着。
不管该不该执行。审批是 Host 和你的事（见第七节）。
不管数据对不对。Server 给什么，模型就信什么——脏数据进，脏答案出。数据源本身的质量，还得靠你自己把关。
不是所有系统都有 MCP Server。有些系统还没有人给它写 Server，有些老系统接不上，别硬套。没有 Server 的地方，还是得单独接。

一句话：MCP 是“插座标准”，不是“电器本身”。插座再统一，电器好不好用，还得看电器自己。

九未能核实、请勿当事实的事项

9,700 万次月下载量：Anthropic 捐赠公告中的说法，厂商自述，未经独立核实。
OpenAI 采用 MCP 的具体时间（2025 年 3 月）：来自多家二手报道的交叉说法，本次未直接打开 OpenAI 官方公告核实。
各家产品对 MCP 的支持程度：哪些版本支持、哪些功能受限，随时在变，以各产品官方文档为准。

十主要来源

检查日期均为 2026 年 11 月 10 日，除非另有注明。官方文档优先，其次为多家交叉的二手报道。

MCP 官方介绍（USB-C 比喻为官方原话）：https://modelcontextprotocol.io/introduction —— 2026-11-10 直接打开核实。
MCP 官方架构文档（Host / Client / Server、两层结构、三种原语、两种传输方式）：https://modelcontextprotocol.io/docs/learn/architecture —— 2026-11-10 直接打开核实。
MCP 捐赠与生态（Anthropic 捐赠公告的二手转述）：https://atlan.com/know/what-is-model-context-protocol/ ；https://www.spend7.com/blog/model-context-protocol-explained
MCP 发布日期 2024-11-25（多家交叉）：https://youtrust.com/blog/model-context-protocol-mcp ；https://imagine-works.com/insights/model-context-protocol-for-enterprise-leaders
MCP 与插件的区别、采用时间线：https://api.onysoft.com/blog/mcp-nedir ；https://www.fanscreator.ai/blog/what-is-mcp-for-creators