想让大模型帮你查数据库、读本地文件、发消息，它却只能回答「我做不到」——MCP 要解决的就是这件事。MCP（模型上下文协议）是一套标准，规定 AI 该怎么和外部工具、数据源对话。它常被叫作 AI 的「USB 接口」：USB 统一了设备怎么插电脑，MCP 统一了工具怎么接 AI。
没有标准时，对接是怎么做的
在协议出现之前，每接一个工具都要单独写一套对接代码：A 产品接日历是一种写法，B 助手接日历是另一种写法。M 个 AI、N 个工具，最坏要做 M×N 套对接，每一套都随版本变化反复维护。工具方不敢轻易改接口，AI 方每加一个能力都要重写一遍，两边的成本都堵在这里。
协议把 M×N 拆成 M+N
MCP 把对接拆成两半。工具方按协议声明「我有什么能力、需要什么参数、会返回什么」，做一次就够；AI 侧按协议去发现能力、发起调用，同样做一次就够。两头都对着标准做，彼此不用认识对方——一次对接，处处可用。类比到这里就通了：USB 之前，键盘、打印机、相机各插各的口；USB 之后，设备只管实现 USB 标准，电脑只管提供 USB 口，双方互不认识也能配合。
一次调用进来什么、发生什么、出去什么
回到机制本身。你问 AI「帮我把这份周报存到文档里」，进来的是你的指令；AI 先从已接入工具的清单里挑出文档工具，按协议规定的格式发出调用请求，带上文件名和内容参数；工具服务执行写入，把结果按协议返回；这段结果进入上下文，AI 再基于它生成回答——「已保存，链接在这里」。整条链路上，AI 不直接碰你的文件系统，它只负责决定调谁、传什么，执行发生在工具那一侧。MCP 本身不产生智能，它决定的是 AI 能触达多少真实世界的能力。
「USB 接口」类比准在哪、不准在哪
| 对比维度 | USB 接口 | MCP |
|---|---|---|
| 统一的东西 | 物理插口与供电规范 | 能力声明、调用格式、返回格式 |
| 接上之后 | 设备即插即用 | AI 获得一项可调用的能力 |
| 安全边界 | 插错设备顶多不识别 | 接错工具可能读走或改掉你的数据 |
| 质量责任 | 接口不管设备好坏 | 协议不管工具执行得对不对 |
类比到「插上就通」为止是准确的，再往下就不准了。USB 插上一个来路不明的设备，最多读不到数据；MCP 接上一个能读写你文件的工具，意味着交出了一部分数据权限。安全模型是它和 USB 分道的地方，授权要按需给、可撤销。
MCP 速查
- 它是一套对接标准，解决 M×N 对接爆炸问题
- 工具方声明能力一次，AI 侧适配一次，两头对着协议做
- 调用链：指令 → 选工具 → 发请求 → 工具执行 → 结果回填上下文
- AI 决定调谁，执行在工具侧，授权范围最小化
- 工具执行的质量不由协议负责，关键操作留确认环节
它解决不了什么
协议只管「怎么对话」，不管三件事。工具本身做得对不对：一个查数据库的工具查询逻辑写错了，协议帮不上忙。权限给多了会发生什么：接一个能发消息的工具，就等于把发送权交了出去，范围要按需给。执行过程是否可控：多步任务里一步调错，后面步步偏。所以接入工具之后要盯执行过程、要定期评测，这些都不在协议的职责范围内，得靠接入方自己做。
关于 MCP 的三个新问题
- MCP 和模型自带的函数调用有什么区别？：函数调用解决「模型怎么表达一次调用」，MCP 解决「这次调用怎么标准化地到达任何工具」。前者是模型能力，后者是生态协议，通常配合使用。
- 普通用户需要懂协议细节吗？：不需要。用户面对的通常是「连接器」或「插件」形态，装一个就给 AI 加一项能力，协议细节被产品包掉了，要关心的只剩授权范围。
- 接的工具越多能力越强吗？：恰恰相反的风险更大。每多接一个，AI 挑工具时的干扰就多一分，错调的概率随之上升。按任务需要接，用不上的先关掉。
沿着工具化这条线继续走：多步任务里智能体怎么交接，Agent 间通信讲了交接与汇报的规范；执行过程怎么盯住，Agent 可观测性给了监控的基本盘；接完一堆工具之后效果如何，Agent 评测提供了考卷；对外服务时工具和接口的承诺怎么定，SLA 的一个例子把服务等级讲透了。
