波仔
🐎 第6章 海纳百川：MCP
📄 一句话概括

没有标准时，五个宿主乘六个工具要单独写三十条对接；有了标准，五加六等于十一条。 标准化省的从来不是初期的活，是让「再加一个工具」从改五处变成改一处——边际成本从乘变成一。

📝 本章和前面几章的关系

这一章换一块：前五章讲的都是「本地怎么组织」，这一章讲「怎么把外部系统接进来」。 第一节先算账。不算清这笔账，后面十节都会觉得「为什么非得套一层协议」。

一、没有标准的世界：乘法

一个宿主要接一个工具，就得单独写一次对接：怎么发现工具、怎么传参、怎么取回结果、怎么报错。 宿主指的是能跑模型的那些界面——命令行、编辑器、自研的 Agent。 工具指的是文件系统、数据库、Git 这类外部系统。 五个宿主、六个工具，就是三十条对接。每条都要单独维护、单独测，而且写法还都不一样。

这是所有「没有标准」的领域的共同命运：成本是乘法，加一个变量整体就涨一截。

二、有了标准：加法

标准协议把这件事拆成两半：宿主实现一次客户端，工具实现一次服务端，中间按协议说话。 于是五加六，十一条。演示里三十降到十一，只剩原来的百分之三十七。 这才是标准化的意义：它不是把某一对做得更好，是把「对」这个概念本身取消掉。

三十条变十一条，初期就少写一半多。但这还只是小头。

三、真正的价值在边际成本

大头在加新东西的时候。加一个新工具，私有协议要改五处——每套宿主都要改一遍、各测一遍。 标准协议改一处：服务端写完，所有宿主立即可用。 宿主越多，这个倍数越大。二十个宿主就是二十倍。

所以这句话要记住：标准化买的不是省钱，是买「以后加东西变便宜」。 它的收益随时间增长，而它的成本集中在第一天。这就是为什么标准化的决定要按长期算。

四、标准化的代价

第一条，接受协议的表达能力上限。协议只规定「列出工具、调用工具、返回内容」，复杂交互要自己套。 第二条，多一层协议转换。 工具输出要序列化成协议格式、宿主再解析，这一步会吃掉一些信息，比如流式输出、附件。 第三条，标准也会变。协议版本不同，字段可能有差异，这是所有标准化都要付的税。

这三条代价都是真的，而且都不可免。判断该不该走标准，是把这三条和上面的收益放在一起称。

五、什么时候该走标准

判据看长期：一次性的对接写死更省事；要长期维护、要多个宿主共用，标准化才划算。 M 乘 N 的痛，只有 M 和 N 都变大时才真的痛。一个宿主、三个工具，写死就完了。 所以 MCP 这个选择，本质上是赌「以后会有很多宿主和很多工具」。

现在看这个赌注已经赢了：宿主有几十个，工具服务器有上千个。这种情况下再自己写对接，就是逆着走。

六、动手 Demo：五套宿主乘六个工具，私有协议要写几条适配

没有标准的时候，每一个「宿主加工具」的组合都要单独写一次对接。 这里算两笔账：初期要写多少条，以及加一个新工具要改几处。

HOSTS = [u"Claude Code", u"Cursor", u"Zed", u"自研 Agent", u"脚本"]
TOOLS = 6

private = len(HOSTS) * TOOLS      # 乘法：每一对写一次
standard = len(HOSTS) + TOOLS     # 加法：各写一次

实跑输出：

--------------------------------------------------------------------
五套宿主乘六个工具，私有协议要写几条适配
--------------------------------------------------------------------

  没有标准的时候，每一个「宿主加工具」的组合都要单独写一次对接。

  ① 私有协议：乘法
  --------------------------------------------------------------------
| 宿主 | 要做什么 | 条数 |
|---|---|---:|
| Claude Code | 六个工具各写一份 | 6 |
| Cursor | 六个工具各写一份 | 6 |
| Zed | 六个工具各写一份 | 6 |
| 自研 Agent | 六个工具各写一份 | 6 |
| 脚本 | 六个工具各写一份 | 6 |

  5 个宿主乘 6 个工具，一共 30 条对接。每条都要单独维护、单独测，而且每一条的写法都不一样。

  ② 标准协议：加法
  --------------------------------------------------------------------
  有了标准之后，每个宿主实现一次客户端，每个工具实现一次服务端，中间按协议说话。
  5 加 6，一共 11 条。从 30 降到 11，只剩原来的 37%。

  ③ 加一个新工具，代价差多少
  --------------------------------------------------------------------
| 协议 | 改动点 | 说明 |
|---|---:|---|
| 私有协议 | 5 处 | 每套宿主都要改一遍、各测一遍 |
| 标准协议 | 1 处 | 服务端写完，所有宿主立即可用 |

  这一列才是标准协议的真正价值：不是「省了初期的对接」，是边际成本从乘变成一。
  加了新工具，私有协议要改 5 处，标准协议改 1 处。宿主越多，这个倍数越大——二十个宿主就是二十倍。

  ④ 标准化的代价
  --------------------------------------------------------------------
  第一，你得接受协议的表达能力上限：协议只规定了「列出工具、调用工具、返回内容」，
  复杂交互要自己套。
  第二，多了一层「协议转换」。
  工具的输出要序列化成协议格式，宿主再解析——这一步会吃掉一些信息（比如流式输出、附件）。
  第三，标准也会变。协议版本不同，字段可能有差异，这是所有标准化都要付的税。
  ! 所以判断要不要走标准，看的是长期：一次性的对接写死更省事；
  要长期维护、要多个宿主共用，标准化才划算。M×N 的痛，只有 M 和 N 都变大时才真的痛。

①私有协议是乘法：五个宿主乘六个工具，三十条对接。 每条都要单独维护、单独测，而且每一条的写法都不一样。 ②标准协议是加法：宿主实现一次客户端、工具实现一次服务端，五加六等于十一，只剩原来的百分之三十七。 ③真正值钱的是边际成本，不是初期那点活：加一个新工具，私有协议得改五处，标准协议改一处。 宿主越多，这个倍数越大。 ④标准化的代价三条：得接受协议的表达能力上限、多一层转换会吃掉流式输出和附件、协议版本会变。 所以判断要不要走标准，看的是长期：一次性的对接写死更省事，要长期维护、要多个宿主共用， 标准化才划算。

30 秒实验

  1. 把宿主从五个加到十个，重跑一遍。私有协议涨到多少条？标准协议涨到多少条？ 两者的比值变大了还是变小了？
  2. 把工具从六个减到两个，重跑一遍。这时候标准协议还划算吗？临界点大概在哪儿？
  3. 给「加一个新工具」补上测试成本（假设每个改动点要测两遍），重跑第 ③ 步。两边的差距被拉大了多少？

常见误区

  1. 以为标准化的好处是「初期少写点代码」。真正的好处是加新东西的时候只改一处。
  2. 一个宿主、三个工具也硬套标准协议。M 和 N 都小的时候，写死更省事。
  3. 接了标准协议就以为能拿到工具的全部能力。协议只规定列工具、调工具、返内容，流式和附件会被吃掉。
  4. 把协议版本当成永远不变的。版本一变字段就可能变，这是所有标准化都要付的税。
  5. 把标准当成「更高级的做法」。它是给多对多的场景准备的，一对一的时候反而是负担。
自测三问（点开对答案） 1. M 乘 N 和 M 加 N 的本质差别在哪？ —— 在成本形状。私有协议每一对都要单独写，成本是乘法；标准协议宿主和工具各写一次，成本是加法。 2. 标准化的真正价值是什么？ —— 边际成本。加一个新工具，私有协议要改 M 处，标准协议只改一处。宿主越多，倍数越大。 3. 什么情况下不该走标准协议？ —— M 和 N 都很小、又只打算短期用的时候。一次性的对接写死更省事，套协议反而是负担。

标准定下了「大家按同一套话说话」，下一节看这套话具体长什么样：一行一个 JSON。

相关笔记