第05篇-Agent 连不上工具？MCP 就是那根“USB-C”

Agent 连不上工具？MCP 就是那根"USB-C"

AI 学习笔记 · 第 5 篇（MCP 篇）

上一篇我们讲清了 Skill------它是递给 Agent 的那本"操作手册"。

但手册写得再漂亮，如果 Agent 的手够不到工具、拿不到数据，照样干不了活。

那么，Agent 究竟是怎么"接上"外部的数据库、文件系统和云服务的？

这一篇就来讲 MCP------那个被称作"AI 世界 USB-C"的东西。

顺便还要讲一个很多人还没更新的消息：2026 年 7 月 28 日，MCP 迎来了问世以来最大的一次改版。

一、先想想，没有 MCP 的世界有多麻烦

假设你是一家公司，手里有 3 个 AI 应用 （一个聊天助手、一个编程助手、一个内部问答机器人），还有 3 套系统（客户数据库、文件服务器、云 API）。

你想让每个 AI 都能连上每套系统，会怎样？

聊天助手要连数据库，得写一套对接代码；
编程助手也要连数据库，再写一套（逻辑几乎一样，但格式不同）；
问答机器人还得再写一套......

这就是所谓的 "M×N 难题" ：M 个 AI 应用 × N 套外部系统，最坏情况下要维护 M×N 套对接。

多接一个工具，成本就往上翻一倍------不是加法，是乘法。结果就是：AI 的"聪明"没问题，卡在"接不上"上。

MCP 想干的事，就是把这个"乘法"变成"加法"：定义一套大家都遵守的接口标准，两边各自实现一次，就能自由组合。

二、MCP 到底是什么？一句话：AI 世界的 USB-C

MCP，全称 Model Context Protocol，中文叫"模型上下文协议"。 它由 Anthropic 在 2024 年 11 月开源发布 ，是一套开放标准，专门用来统一"大模型应用如何连接外部数据和工具"。

官方对它有一个非常形象的比喻，也是流传最广的一句：

把 MCP 看作是 AI 应用的 USB-C 接口。

回想一下 USB-C 出现之前：鼠标、键盘、打印机各有各的接口，插错一根线就用不了。USB-C 统一之后，任何设备插上就能用，没人在意插的到底是鼠标还是硬盘。

MCP 做的事一模一样：

AI 应用侧，只要按标准实现一次"客户端"；
工具和数据源侧，只要按标准实现一次"服务端"；
两边就能即插即用、自由组合。

也难怪它火得这么快。到今天，OpenAI、Google、微软和发起方 Anthropic 四家已经集体"站队"支持 ，Claude、ChatGPT、Cursor、VS Code、微软 Copilot 这些你叫得上名字的产品，基本都完成了接入。协议本身也已交给 Linux 基金会旗下的 Agentic AI Foundation 托管，从"某家公司的协议"变成了"行业公共基础设施"。

一句话记住：

MCP 不生产能力，它只是把"AI"和"外部世界"之间的接口标准化了。

三、MCP 里的四个角色

别看名字抽象，MCP 的架构其实就四个角色，各有各的分工：

① MCP 主机（Host） ：就是你正在用的那个 AI 应用------Claude、Cursor、ChatGPT 都算。它负责统筹全局：谁来连、能连什么、敏感操作要不要你点头。
② MCP 客户端（Client） ：藏在主机内部的"插头"，负责和某一个服务器保持一对一连接。
③ MCP 服务器（Server） ：一个轻量程序，把自己的能力"摆到台面上"------能查什么、能改什么，都由它对外声明。
④ 上游系统（Upstream） ：真正干活的底层------数据库、API、文件系统、SaaS。MCP 服务器通常只是"转接"，并不取代它们。

这里有个特别容易搞混、但很关键的点：

客户端和服务器是一对一的；但一个主机可以创建很多个客户端。

所以，一个 AI 应用想同时连数据库、文件系统和云 API，做法不是"一个巨型连接全包"，而是开三个客户端，各连一个服务器 。好处是互相隔离：连数据库的那个，不会顺带拿到云平台的密钥；敏感操作还能单独要求你确认。

再补一个数字感受下生态规模：目前公开的 MCP 服务器已超过 1 万个 ，协议官方披露的 SDK 月下载量已突破 4 亿次 （年内涨了约 4 倍）。在国内，百度早在 2025 年 4 月就发布了首批 MCP 服务，其智能云平台全面兼容 MCP；腾讯云的桌面助手也内置了主流的 MCP 服务器------"支持 MCP 吗"正在变成和当年"支持 USB 吗"一样的问题。

四、一次请求，是怎么跑完的？

光看角色还是抽象的，我们让一个真实问题跑一遍：

你问："帮我查一下 ACME 这个客户目前的状态。"

你提问，主机接到这句话；
主机把可用的工具清单交给模型------相当于告诉它"你现在有这些工具可用"；
模型判断 ：这次需要查客户数据，于是选定类似 get_customer_status 的工具；
客户端按标准协议发出请求------消息用统一的 JSON-RPC 格式封装；
服务器校验并调用上游系统------检查参数和权限，然后去查真正的 CRM 数据库或 API；
结果回流，模型拿到结构化数据，生成你能看懂的那句回答。

整个过程里，有一个细节很关键：

模型从头到尾都不需要知道"数据库是哪种、接口长什么样"。 它只需要知道"有个工具能查客户状态"，剩下的都交给服务器。

这就是标准化的威力------AI 负责"想"，MCP 负责"接"，上游系统负责"做"。

五、两种传输方式：本地 vs 远程

MCP 的协议语义是统一的，但"消息怎么传"有两种常见方式，对应两个不同的使用场景：

本地 · Stdio ：客户端启动一个子进程 ，双方通过标准输入/输出通信。不走网络、延迟最低，适合个人工具和开发调试。你在本地让 AI 读文件、跑 Git 命令，多半走的就是这条路。
远程 · Streamable HTTP ：把服务器部署到网上，通过 HTTP 请求访问，支持 OAuth、API Key 等认证。适合公共、企业和多租户场景。

这里要特别提一句历史变化：早期的 SSE 传输已经被弃用 ，官方现在推荐统一转向 Streamable HTTP。如果你看到旧的教程还在讲 SSE，那是上一版协议的事了。

两者的区别在"部署在哪"，不在"协议本身"------协议语义完全一致，只是换了个通道。

六、服务器对外提供什么？三个核心原语

那服务器到底能"摆出"哪些东西？MCP 定义了三个核心概念，业内叫"原语"：

① 工具（Tools） ：可以执行的动作 ------查数据库、发邮件、调第三方 API。由模型主动决定什么时候调用。你可以粗略理解成"往服务器写"。
② 资源（Resources） ：只读的数据------文件内容、数据库记录、API 响应，供模型"阅读"。粗略理解成"从服务器读"。
③ 提示（Prompts） ：可复用的模板------比如"代码审查"的标准提示词、某类分析的固定工作流。它把"怎么问"也标准化了。

服务器用 tools/list 这类方法把能力"摆出来"，客户端按需发现和调用；能力清单还能动态更新，新增了工具，正在运行的 Agent 也能感知到。

一个常被忽略的补充：MCP 也定义了客户端侧的能力 ，比如"获取用户输入"（elicitation）------服务器可以反过来向用户问一句，比如执行敏感操作前请你确认。这也是 MCP 强调"人在环路"的体现。

七、2026 年最大的一次改版：从"有状态"到"无状态"

如果这篇只记住一件事，那应该是这个。

2026 年 7 月 28 日，MCP 发布了第 5 版规范（2026-07-28）。 官方把它定性为协议问世以来规模最大、最系统性的一次修订。它的核心变化只有一句话：

把"有状态连接"改成"无状态核心"。

旧版（有状态）是这样工作的 ：客户端连上服务器，先来一轮"初始化握手"，然后服务器发一个会话 ID ，之后每个请求都要带上它------服务器得记住"你是你"。这套设计源于 MCP 最早的本地进程出身，但一旦搬到云端，麻烦就来了：负载均衡必须配置"粘性会话"，请求只能路由到同一台机器；某台机器一挂，会话就断；自动扩缩容也很别扭。

新规范（无状态）直接把这套东西拆了：

取消初始化握手------不再需要开局先"对暗号"；
移除会话 ID ------每个请求都自带所需信息，独立、自包含；
新增 server/discover ------客户端想在动手前先看看"你会什么"，可以主动问一次（但也不是强制的）；
用"多轮往返请求"取代长连接 ------当工具跑到一半需要用户补充信息时，服务器返回"需要输入"，客户端答完再发起一次调用即可，全程不需要挂着一个活的长会话；
请求必须带上 Mcp-Method、Mcp-Name 这类头部 ------这样网关、限流器、防火墙不用拆开 JSON 正文，光看请求头就能路由和计费；
顺带强化了 OAuth 2.0 / OIDC 的企业级适配，可以直接对接企业身份系统。

这套改动带来什么好处？ 一句话：请求可以路由到任意一台服务器实例。 于是------

扩容不再卡在会话上，加机器就行；
可以直接跑在 AWS Lambda、Cloudflare Workers 这类无服务器架构上；
蓝绿发布不用再做"会话排水"，新实例上线即可接流量。

要注意一个措辞上的细节，官方说的是"不再强制有状态 "，而不是"禁止状态"。无状态指的是"协议层不替你兜状态"------你的数据库、缓存、业务状态该在还在，只是不能再指望"连接"本身帮你记着了。

同时，新版还引入了一套版本化的扩展机制 ，把"MCP 应用""长任务"等能力做成了正式扩展；并给出了 12 个月的旧特性过渡期 。对普通用户来说，这些你不需要记，但"无状态"这个大方向，值得记住------它决定了 2026 年之后，MCP 服务器该怎么建、怎么部署。

八、MCP 和 Skill 到底什么关系？

写到这里，十有八九有人要问：那它和上一篇讲的 Skill，是不是一回事？会不会一个取代另一个？

不会。它们解决的根本不是同一个问题。

MCP 管"能摸到什么" ------它能调用哪些工具、能读到哪些数据。这是连接层、能力供给层。
Skill 管"这活该怎么干" ------流程是什么、标准是什么、输出长什么样。这是方法层、行为规范层。

用一句话概括两者的分工：

MCP 是插座和输电线，Skill 是插上去的电器和说明书。

没有 MCP，模型"知道怎么做，但够不到数据和工具"；没有 Skill，模型"能干活，但每次干法都不一样、结果不稳定"。两者是配合关系，不是替代关系。

举个你已经见过的例子：让 AI 做浏览器自动化测试------用什么去操作浏览器 （比如 Playwright 那类工具）是 MCP 的事；按什么流程测、先做什么后做什么（一份操作说明）是 Skill 的事。工具 + 方法，一个都不能少。

（顺带澄清一个常见误解：MCP 服务器里通常不"存"Skill。 它存的是工具、资源、提示这些底层能力；复杂的方法论，通常留在 Agent 或客户端那一层。）

九、几个常见疑问

Q1：MCP 是一个新 API 吗？

不完全是。它更像建立在 API 之上的统一接口层 。MCP 服务器可以把已有的 REST API、数据库、文件系统"包一层"，用标准方式暴露给 AI------它通常是补充 API，而不是取代 API。

Q2：一个客户端能连多个服务器吗？

不能。协议定义的是客户端与服务器一对一 。想连多个，就得由主机创建多个客户端------这也是它做隔离的方式。

Q3：MCP 一定有状态吗？

现在核心是无状态的（见第七节）。应用和上游系统仍可以各自维护状态，但那已经不属于"协议帮你管"的范畴了。

Q4：不上远程、只在本地用，可以吗？

完全可以。本地 Stdio + 远程 Streamable HTTP 都受支持，角色和部署位置无关。

十、一点安全提醒

MCP 把"接上外部世界"变得太方便了，便利的另一面，就是攻击面变大 。这不是危言耸听------公开的安全公告里，已经出现过 MCP 相关的漏洞编号（比如影响本地启动方式的命令注入、会话标识被劫持等问题）；更微妙的一类风险是：你批准过的工具，描述文字在后续会话里被偷偷改了，而"批准"往往只发生在那一次。

给三条使用者层面的朴素建议：

只装你信得过的服务器------尤其别随便跑来源不明的远程服务器，它看到的可能就是你的敏感数据。
敏感操作保留人工确认------删库、转账、发邮件这类动作，让"要你点头"成为习惯。
把工具当"不可信输入"看待------工具返回的内容、工具描述本身，都可能被人做手脚，别让 AI 无条件照着执行。

对开发者 还要加一句：不要把 API 密钥写进客户端代码 ；远程服务器建议老老实实用 OAuth，短期令牌、频繁轮换，别自己发明一套鉴权逻辑。

写在最后

回到最开始那句话：

MCP 不生产智能，它只是把 "AI" 和 "外部世界" 之间的接口，标准化了。

记住四件事就够了：

它解决的是 "M×N 变成 M+N"------一次对接，到处能用；
四个角色 ------主机、客户端、服务器、上游系统，客户端与服务器一对一；
三样东西------工具（做）、资源（读）、提示（模板）；
2026 年最大的变化 ------从 "有状态" 走向 "无状态"，扩容和部署从此松绑。

到这里，"概念与工具" 这一组就讲完了：Agent 是干活的人，Skill 是他的操作手册，MCP 是他面前那张标准工具台。 从下一篇开始，我们把视角从 "零件" 抬到 "路线"------聊聊 AI 工程里最经典的三种技术路线：RAG、微调、Agent，它们到底该怎么选。

下一篇预告： RAG、微调、Agent，三条技术路线到底有什么区别？为什么 2026 年还得多看一个"长上下文"？

福利，关注公众号-物联网老王，后台回复 11111，免费获取超火学习资料：

《读懂 AI：术语与常见问题》简介

面向 AI 学习者的术语速查与方法指引手册，收录 148 个高频术语与 50 个常见问题。术语按关联性分八类、类内按英文首字母排序，核心词条四项展开、其余一行说明。

术语速查
- LLM（大语言模型）：AI 的"大脑"，会思考、会表达，但光有大脑干不了活。
- RAG（检索增强生成）：开卷考试------不会就当场翻书，比闭卷硬背靠谱。
- MCP（模型上下文协议）：AI 世界的 USB-C，以统一标准连接外部工具与数据。
本书适合哪些读者？
- 初识 AI 的高校学生：建立整体概念框架。
- 正在学习或转向 AI 方向的工程师：快速核对术语口径。
- 一人公司创业者与产品、运营从业者：在技术选型与落地决策中随查随用。
经常被问到的问题
- Agent 和聊天机器人到底差在哪？
- 上下文窗口都 100 万了，还需要 RAG 吗？
- 装了 MCP，还要不要写 Skill？
- 微调、RAG、提示工程，我该选哪条路？
读完这本书，你能掌握什么
- 厘清 AI、机器学习、深度学习、大模型与智能体之间的包含与并列关系。
- 掌握提示工程、上下文工程、RAG 与微调各自的能力边界。
- 了解智能体平台的选型维度，以及数据、权限、审查三条落地底线。

本文为个人 AI 学习笔记整理，框架来自学习资料，并参考了公开的行业资料与最新进展；涉及具体产品、版本与数据以官方信息为准（截至 2026 年 10 月）。