为什么 Agent 工具需要一个「协议」而不是「框架」：MCP 成为标准的底层逻辑

后来大家都开始喊一个词：MCP，这次我不想讲这么使用MCP ，而是退一步，讲清楚一个更本质的问题——为什么偏偏是它，能成为「Agent 的工具标准」？一个协议凭什么？

前言

MCP 能成为标准，不是因为它技术最牛，而是它应对了三个原因：

1. 时机对：Agent 大爆发，工具集成的「分散化之痛」到了临界点，市场急需一个「统一接口」。
2. 形态对：它是「协议」不是「框架」——只约定边界，不锁死你，所以谁都能接受。
3. 生态对：开放 + 网络效应，工具方和 Agent 方的正反馈一旦滚起来，就停不下来。

MCP 就正好是：标准赢，从来不是赢在「更好」，而是赢在「刚好卡在所有人都不反对、且都受益的那个位置上」。

一、先搞清楚问题：不是「不会接工具」，是「每个都要重接一遍」

很多人以为，没有 MCP 之前，Agent 接工具是「能不能」的问题。其实不是，是「要不要重复劳动」的问题。 我们把这个乘法拆成两边看：

• 工具提供方（比如 GitHub、数据库、浏览器）：想让自己的服务被 Agent 用。可 Agent 框架有十几个，每个的「工具定义格式」都不一样。想全覆盖，就得给每个框架写一套适配，维护十几份几乎一样的代码。
• 工具消费方（写 Agent 的你）：想给 Agent 接能力。可每个服务的 API 长得都不一样——鉴权方式、分页方式、错误码、参数结构，各有各的脾气。接一个服务学一遍，接十个服务学十遍。

两边的痛苦，指向同一个根源：中间缺一层「大家都认的共同约定」。 这跟历史上的 USB、HTTP、PDF 是同一类问题——它们的伟大之处从来不是「技术多惊艳」，而是解决了一个「协调问题」：让成千上万个互不相识的参与者，不用互相商量，也能严丝合缝地对接。

记住：标准要解决的，是「协调成本」，不是「技术难题」。 技术难题总有人能解，协调难题才需要一个所有人都愿意签字的「公约」。

二、为什么是「协议」赢，而不是「框架」赢

想清楚「协议」和「框架」的区别

仔细看看这个区别。 框架是「我全都替你做好，你照着用就行」——好用，但代价是把你锁死：你的循环、记忆、工具全都长在它身上，想换框架等于重写。所以框架的市场，永远是「几家割据、谁也统一不了谁」。

而协议它主要的事情就是：约定「边界」——你说什么格式、我回什么格式，就这一层。边界之内，你爱用什么语言、什么框架、什么模型，随便。因为只约定边界，所以它不抢任何框架的地盘；因为不抢地盘，所以所有框架都愿意支持它。

MCP 赢，赢就赢在它「卡对了位置」：它没有野心去定义「Agent 该怎么做」，只定义了「Agent 和工具之间的那一层边界」。 这个位置足够薄，所以谁都接得住；又足够关键，所以谁都绕不开。

三、函数调用、HTTP、插件——为什么它们都不够？

到这里你可能会问：不是已经有「函数调用（function calling）」「HTTP API」「插件系统」了吗？为什么还需要一个新协议？

看出共同点了吗？它们都缺了「一层中立的、大家都认的边界」。 函数调用是「厂商的边界」，HTTP 是「没有边界」，插件是「某一家平台自己的边界」。而 MCP 补的，恰恰是这层「行业公共边界」：一次定义，所有 Agent、所有工具、所有厂商都能用。

也正因为这个「中立」，MCP 后来的故事才顺理成章——Anthropic 2024 年底把规范开源，2025 年 OpenAI、Google 也先后跟进支持。没人愿意被竞争对手的私有协议锁死，但人人都愿意加入一个「不属于任何一家」的公共协议。

四、MCP 到底约定了一个什么「边界」？

既然是「边界」，那这条边界上具体划了什么线？核心是它把 Agent 真正需要的三类「外部能力」都抽象进去了：

• Tools（工具）：能「调用一个动作」——查 issue、改文件、跑命令。对应「让 Agent 做事」。
• Resources（资源）：能「读取一段数据」——读文档、读配置、读数据库。对应「让 Agent 查资料」。
• Prompts（提示词）：能「提供一段模板」——把现成的提示词片段塞给 Agent。对应「给 Agent 一个套路」。

而这三个原语背后，藏着一个比「三个名词」重要得多的设计：能力是「运行时发现」的，不是「编译期写死」的。 一个 MCP server 有哪些工具、每个工具什么参数，不是写在 Agent 代码里的，而是 Agent 一问（tools/list），server 现场交出来：

Agent 问：你有哪些能力？
<span>Server</span> 答：我能 create_issue（参数：title, body…）、list_issues（参数：…）……

这条「发现」的边界，才是 MCP 区别于一切「手写工具」的灵魂。 工具作者改了 server（加了个新工具、改了参数），所有用它的 Agent 下次一问就自动知道了，一行都不用改。边界把「能力的定义权」还给了工具的拥有者，把「接能力的成本」降到了接近零。

五、但是它现在还不是「完美标准」

到目前为止，MCP 还远没有到「盖棺定论」的程度，它有几个明摆着的不完美：

1. 规范还在剧烈变动。传输层、鉴权、Sampling……过去两年改了好几版，早期跟着写的代码，过阵子可能就要跟着改。你接入时要有个心理预期：跟的不是一个「稳定成品」，而是一个「快速演进的活标准」。
2. 三个原语只用活了一个。现实中 90% 的落地只用到了 Tools，Resources 和 Prompts 很少被真正用起来（第 10 篇也提过这点）。它「大而全」的部分，多少有点超前。
3. 安全是天然的软肋。MCP 靠「跑一个第三方 server 包」（经常是 npx 拉起来）来扩展能力——这意味着你把「运行别人代码」的权力交给了它，供应链风险得自己把好关。

不过，一个被广泛使用、还在快速迭代的开放协议，比一个「设计完美但没人用」的封闭框架，更接近「标准」——因为标准的本质是「大家都来用、大家都来改」，而不是「一个人想得很完美」。

六、你、我，开发者都应该知道的事情

最后落到你自己身上：理解了这套逻辑，写 Agent 时该怎么对待 MCP？

1. 别把它当银弹。 MCP 解决的是「接外部服务」这一层，你的 Agent 还有循环、记忆、上下文、安全一堆自己的事。工具接入标准化了，不等于 Agent 本身标准化了。
2. 该手写还得手写。 如果就接一两个、很定制化的能力，手写两个工具函数可能比引入一套 MCP client 更轻。标准是为了「规模」准备的，不是为了「省一个函数」准备的。
3. 永远按「边界」去设计你自己的扩展点。 MCP 最大的启发不是「快去用 MCP」，而是那个更通用的道理：把「会变的东西」和「不变的东西」用一层清晰的边界隔开，你就能同时拿到「灵活」和「稳定」。

七、总结 + 思维导图

收成一张图：

MCP 为什么能成为标准
│
├── 解决什么（协调问题）
│   └── N×M → N+M：工具方和 Agent 方都只写一次
│
├── 为什么赢（形态对）
│   ├── 是「协议」不是「框架」→ 只约边界，不锁死
│   ├── 中立、开放 → 不属于任何厂商
│   └── 网络效应 → 越多人用，越值得用
│
├── 约定什么（一条边界）
│   ├── Tools   → 做事
│   ├── Resources → 查资料
│   └── Prompts   → 给套路
│
└── 还不完美（但反而证明它活着）
<span>    ├── 规范还在演进
    ├── 三原语只用活一个
    └── 供应链安全风险
</span>

参考 / 延伸阅读：

• Model Context Protocol 官方规范
• MCP —— Introducing the Model Context Protocol（Anthropic 2024 公告）
• Anthropic Engineering —— Building effective agents