第 10 章 · MCP —— 工具的"USB 标准"

🐣 小a的换工具箱烦恼
小a在 pi 工坊用顺了 read/edit/bash 这些工具,觉得自己武装齐了。某天它去隔壁 Claude Code 工坊串门,想借用那边的工具,结果傻眼了——
"你这边工具接口怎么跟我们不一样?参数格式也不一样?"
Claude Code 那边一脸无奈:"我们一直这么写的啊。你要用,得按我们的格式重写一遍。"
小a又跑去 Cursor 工坊,又是另一套格式。它崩溃了:每家 agent 的工具,长得都不一样,工具只能给一家用。
老z听完,点点头:"这事儿全行业都在头疼。所以最近出了一个标准,想解决这个问题。它叫 MCP。"

10.1 工具的"巴别塔危机"

先看清问题。回忆第 3 章——LLM 调用有"巴别塔危机"(近 40 家厂商方言不通)。工具这边也有同样的危机:

Agent 框架	工具接口格式
pi	自己的 Tool 定义
Claude Code	另一套格式
Cursor	又一套
LangChain	又又一套

🧙 后果:
你给 pi 写了一个"读 GitHub"的工具,搬到 Claude Code 用不了,得重写
工具开发者被迫给每家框架各写一遍同一个工具
工具生态被割裂成一个个孤岛
这就是工具层面的巴别塔:框架之间不互通,工具不能共享。

10.2 MCP:工具的"USB 标准"

老z掏出一个比喻,小a秒懂。

🧙 MCP(Model Context Protocol)是什么?
MCP 是一个统一的协议标准,让"工具/资源"像 USB 一样即插即用——写一次,任何支持 MCP 的 agent 都能用。
老z打比方:
USB 出现前:每个设备配自己的插头(键盘一种、鼠标一种、打印机一种……)→ 接口灾难
USB 出现后:所有设备用统一接口 → 一个 USB 设备插哪台电脑都能用
MCP 之于工具,就像 USB 之于硬件:统一接口,生态共享。

10.3 MCP 的核心角色:Server 和 Client

MCP 把世界分成两半:

   ┌─────────────────┐        ┌─────────────────┐
   │   MCP Server    │        │   MCP Client    │
   │  (提供工具的一方)│ ◄────► │  (使用工具的一方)│
   │                 │  标准协议 │                 │
   │ 暴露:工具/资源  │        │ = 各种 Agent    │
   │  (如:文件浏览) │        │ (pi/Claude/Cursor)│
   └─────────────────┘        └─────────────────┘

MCP Server:把某种能力(读文件、查数据库、调 API)按 MCP 标准暴露出来
MCP Client:各种 agent 框架,它们"说 MCP",能连任意 MCP Server 用它的工具

🧙 关键:一个 Server,多个 Client 都能用。 Server 只写一遍,任何支持 MCP 的 Agent 都能连上它取用工具。

10.4 一个简单例子

假设有个 "MCP 文件浏览器 Server",它暴露了"列目录""读文件"等能力。

那么:

pi 连上它 → pi 多了"列目录""读文件"能力
Claude Code 连上它 → Claude Code 也多了同样能力
Cursor 连上它 → Cursor 也多了同样能力

关键:这个 Server 只写了一遍,三家 agent 都能用。 这就是 MCP 的价值——打破工具孤岛。

🐣 小a眼睛亮了:"那以后我写一个工具,所有 agent 都能用?"
🧙 "理论上对。 但要诚实告诉你——MCP 还很新,生态在建设中。现在不是所有工具都有 MCP 版本,也不是所有 agent 都完美支持 MCP。它是趋势,但还没到『万能』的地步。"

10.5 MCP 的边界:它不是万能的

🧙 诚实地说,MCP 有自己的适用边界:
标准化 vs 灵活:MCP 要按标准协议来,意味着"格式统一"但也"不够灵活"——有些场景(私有、高性能)不适合
生态成熟度:不是所有工具都有 MCP 版本
不是唯一标准:还有其他协议在竞争,生态还没尘埃落定
MCP 是"方向",不是"答案"。 理解它,你就能看懂行业趋势;但要灵活判断哪些场景该用、哪些不用。

10.6 pi 的选择:自带工具

🧙 pi 对 MCP 的支持是有限的。 它的工具(read/edit/bash/grep 等)是内置的,用的是 pi 自己的 Tool 接口。
这不奇怪——pi 是个"自带完整工具箱"的成品,核心场景是本地编码,内置工具够用,不太依赖外部 MCP 生态。
但这不影响你理解 MCP——它是行业标准,你用别的 agent(Claude Code 等)会经常碰到。pi 选择了"自带工具"这条路,不代表 MCP 不好,只是场景不同。

10.7 MCP 不止"工具":三种原语

"前面一直说 MCP 是工具标准,"老z纠正道,"其实工具只是 MCP 的一部分。MCP 定义了三类能力,叫原语(primitive)。"

🧙 MCP 的三种原语:
原语是什么类比什么时候用
Tool(工具) 可执行的动作按钮 Agent 要"做事"时(执行、计算、改数据)
Resource(资源) 可读取的数据资料库 Agent 要"查资料"时(文件、数据库、文档)
Prompt(提示词模板) 预置的可复用指令 模板 Agent 要"套模板干活"时(生成周报、代码评审)
一个 MCP Server 可以只提供一种,也可以三种都提供。比如一个"GitHub Server":
Tools:create_issue、merge_pr(动手)
Resources:repository_contents、issue_list(查数据)
Prompts:summarize_pr、review_code(套模板)

原语	是什么	类比	什么时候用
Tool(工具)	可执行的动作	按钮	Agent 要"做事"时(执行、计算、改数据)
Resource(资源)	可读取的数据	资料库	Agent 要"查资料"时(文件、数据库、文档)
Prompt(提示词模板)	预置的可复用指令	模板	Agent 要"套模板干活"时(生成周报、代码评审)

🐣 小a:"所以 MCP 不只是在统一『工具』,是在统一『Agent 需要的一切外部能力』?"
🧙 "对。这也是 MCP 全名的意思——Model Context Protocol,模型上下文协议:把 Agent 干活要用的动作(工具)、数据(资源)、套路(提示词模板),都用统一协议打包,让任意 Agent 即插即用。"

10.8 MCP 怎么跑起来:传输与运行模型

"最后看一个务实问题:MCP 的 Server 和 Client 是怎么连起来的?"老z问。

🧙 MCP 的传输方式(transport):
传输是什么适合
stdio Server 是本地的一个子进程,通过标准输入/输出通信本地工具(文件浏览器、git 助手)
HTTP(SSE / Streamable) Server 是一个远程服务,通过 HTTP 通信远程服务(云端数据库、在线 API)
翻译成人话:
本地 MCP Server = 你的电脑上跑着一个小程序,Agent 起一个子进程跟它说话
远程 MCP Server = 云端跑着一个服务,Agent 通过 URL 访问它

传输	是什么	适合
stdio	Server 是本地的一个子进程,通过标准输入/输出通信	本地工具(文件浏览器、git 助手)
HTTP(SSE / Streamable)	Server 是一个远程服务,通过 HTTP 通信	远程服务(云端数据库、在线 API)

连接 MCP 的安全边界

⚠️ 连第三方 MCP Server,就是把"手"交给别人。
MCP Server 可以读你的文件、发你的请求——它的权限就是 Agent 的权限(第 15 章会讲信任模型)
装一个来源不明的 MCP Server ≈ 装一个来路不明的插件:它可能做它承诺的事,也可能做别的
工程建议:只连可信来源的 Server;给远程 Server 配独立鉴权;敏感数据不要随便丢给第三方 Server

🐣 小a:"所以 MCP 的『即插即用』,是把双刃剑——方便,但信任要自己把关?"
🧙 "对。MCP 降低的是『接入成本』,不是『信任成本』。 协议让你少写代码,但它管不了『对方的 Server 可不可信』——那是你自己的安全判断。这个主题,第 15 章还会深入。"

本章小结

🐣 小a的 USB 课

┌──────── MCP ────────┐
│                      │
│  • 工具也有巴别塔:   │
│    每家框架格式不同  │
│                      │
│  • MCP = USB 标准    │
│    写一次,全 Agent 用│
│                      │
│  • 两个角色:         │
│    Server(提供工具) │
│    Client(用工具)   │
│                      │
│  • 边界:标准化≠灵活  │
│    生态还在建设      │
│                      │
│  • 三种原语:         │
│    Tool(动作)/       │
│    Resource(数据)/   │
│    Prompt(模板)      │
│                      │
│  • 传输:stdio(本地) │
│    HTTP(远程)        │
│    → 连第三方要审信任│
│                      │
│  • pi 选择:自带工具  │
│    (场景不同,非对错) │
└──────────────────────┘

关键认知:MCP 是工具生态的"USB 标准"——解决"工具不能跨框架共享"的巴别塔。它统合了三类能力(动作/数据/模板),传输分本地与远程;但"即插即用"只降接入成本,信任仍要自己把关。它是方向,不是万能的答案;pi 选了自带工具,是场景适配而非否定 MCP。

课后实验

画关系图:标出 MCP Server、MCP Client、Agent 三者的关系。
找 MCP Server:搜索一下现有哪些流行的 MCP Server(文件、数据库、浏览器等),看它们暴露什么工具。
判断适用性:想想你的场景,该用 MCP 还是自带工具,为什么?
分辨原语:挑一个 MCP Server,判断它暴露的是 Tools、Resources 还是 Prompts,想想"如果换成另外两种,合适吗"。
安全审查:浏览一个 MCP Server 的权限声明(它要求哪些权限),评估"敢不敢让它连我的文件系统"。

下一章:比 Tool 更高一层的"能力打包"——让小a会干一套完整的活。 → 第 11 章 · Skill

10.1 工具的"巴别塔危机" ​

10.2 MCP:工具的"USB 标准" ​

10.3 MCP 的核心角色:Server 和 Client ​

10.4 一个简单例子 ​

10.5 MCP 的边界:它不是万能的 ​

10.6 pi 的选择:自带工具 ​

10.7 MCP 不止"工具":三种原语 ​

10.8 MCP 怎么跑起来:传输与运行模型 ​

连接 MCP 的安全边界 ​

本章小结 ​

课后实验 ​