MCP 协议

上一课我们把工具调用拆成了「定义 → 意图 → 执行 → 回填」四步。这一张先算最实际的一笔账：为什么每接一个新工具，就要为每个宿主各写一遍适配代码。

因为工具调用依赖宿主自己的私有约定——A 应用写的工具，B 应用没法直接拿来用。就像每家门店都要为每个品牌的会员卡各装一台刷卡机：5 家店 × 20 个品牌 = 100 台，谁也统一不了，每加一个品牌每店都要再加一台。所以下面把 M×N 这笔乘法，与它被压成 M+N 之后的差距算出来。

更直接的做法是「谁要用谁自己接」——每个宿主单独为每个工具写一份适配。只有 1 个宿主时它也够用，但成本随规模平方涨：从 5×20 加到 10×50，两两对接的份数从 100 涨到 500（约 5 倍——宿主翻倍、工具数又增至 2.5 倍，乘法叠加；而协议化后份数只从 25 涨到 60，约 2.4 倍）；每新增一个工具，还要在全部宿主里各改一次。

上一张卡片算清了 M×N 这笔乘法。这一张回答：MCP 到底是什么，三个角色怎么分工。

因为一个宿主往往要同时连多个服务器，如果让应用自己记住每条连接的细节，它会越写越重，所以要把「连接」从应用里拆出来，交给一个专门的角色 Client。就像一家公司要对接多个供应商，会给每个供应商配一个专门的对接人，而不是让老板自己记所有细节。所以一次 tools/call 的请求，走的是「宿主 → 客户端 → 服务器」这条固定的路。

上一张卡片看到 Server 通过「原语」对外提供能力。这一张把三类原语拆开，回答各自解决什么、什么时候用哪个。

因为三类原语的控制方不同，混用会让模型做出越权的事，所以要先按「谁控制」把边界划清。就像一个抽屉柜：Resources 是别人直接放进你桌面的资料（应用决定给什么）、Prompts 是你自己挑的模板卡（用户决定用哪张）、Tools 是给助手的一把钥匙（模型决定什么时候用）。所以下面用一笔 token 账，看把太多东西当 Tools 会付什么代价。

更省事的做法是「把服务器能提供的东西全写成 Tool」，反正模型都能调。但 Tool 的 schema 每次都常驻上下文：12 个能力全做成 Tool 就是 12 × 200 = 2,400 token，其中不少是只读资料，本该由应用按需注入。分出 Resources / Prompts 后，常驻的只剩 3 个 Tool = 600 token，省 1,800 token（每次请求都省）。

上一张卡片把三类原语分清了。这一张动手，把一个公司内网系统（工单查询）包成 Server。

因为服务器只需要把能力声明出来、把编排交给宿主，所以一个 server 常常只有几十行。就像给新同事做一张「工作说明卡」：写清他能做什么、要什么输入、返回什么，剩下该调谁、什么时候调，由主管来定。所以下面用四个工具把工单系统的 Server 走一遍，并算一下工作量。

上一张卡片把工单 Server 跑起来了。这一张处理「谁能调什么」，也就是传输与鉴权的配套选择。

因为本地与远程的信任边界不同，所以传输方式与鉴权强度要一起选，不能只看方便。就像同一栋楼的门禁：本楼员工刷工牌就进（本地 stdio 直接继承宿主进程的权限），外来访客要登记换证（远程 HTTP 走 OAuth token）。所以下面用一笔账，比较两种传输的成本。

上一张卡片解决了「谁能调什么」。这一张看协议自己的演进：为什么要无状态化。

因为有状态要求请求必须回到原来那台实例、状态还要外置到共享存储，所以实例一多，扩容就卡在这两件事上。就像一家店要求「必须找上次接待你的那个店员」：人一多，排班和交接全乱了；改成「谁都能接」，才排得开班。所以下面用一笔账对比两种部署方式，并看缓存能省多少探测。

更直接的做法是「保留会话、用粘性路由把请求钉回原实例」。单实例时没问题，但实例从 1 台加到 10 台，就要求负载均衡记住每个会话落在哪台、并把会话状态外置到共享存储——扩容从「加机器」变成「迁会话」。无状态化把这两条约束都去掉，所以加实例不再需要迁移。