如果要给这几年的 Agent 生态画一张最写实的图，画面中心可能不是机器人在干活，而是工程师在写胶水代码。
想让 Agent 会用日历？写一段适配。想让它查数据库？再写一段。想让它读某个 SaaS 的数据？还有一段，连鉴权带错误处理一起伺候。
一两段不算什么。但现实是：模型不止一个，工具成百上千——每一个“模型 × 工具”的新组合，都要多写一份适配。这是一道乘法题，越滚越大。
MCP 想做的事，就是把这乘法降下来。
泥潭：胶水代码写不完
USB 出现之前的世界，是一堆各说各话的插头：打印机的口是圆的，键盘的口是圆的（另一种圆），鼠标走串口，显示器另有一路。每换一个设备，就换一种插头。
今天 AI 工具的接入现状，和那个年代像得出奇：
- 每个模型厂商，有自己的插件格式
- 每套 Agent 框架，有自己的工具定义
- 每个外部服务，按自己的脾气暴露接口
结果是：工具作者为 A 平台写的适配，搬到 B 平台基本作废；用户则被困在一张“哪些工具支持哪些模型”的表格里。
更现实的是版本地狱：模型升一级，原来的适配要回归一遍；工具换了鉴权方式，散落各处的一排适配都得跟着改。适配层攒到最后，成了一种没人说得清有多少副本的私有方言。
胶水的活还细碎：返回格式的一次调整、一种新参数类型的支持、一次鉴权过期后的重试——单拎哪一件都不值一提，但乘以组合数，就成了压在每个人头上的日常。
问题不在于工具不够多，而在于每一个“模型-工具”组合都被要求单独适配一遍。
把插座标准化
USB-C 的聪明之处，不在它传了多少数据，而在它不规定设备做什么，只规定怎么插。设备端守一份规矩，主机端守同一份规矩，于是任意设备能插任意主机。
MCP（Model Context Protocol，模型上下文协议）走的是同一条路。它既不管各家模型怎么训练，也不管工具内部怎么实现；它只管一件事：让“模型这一端”和“能力那一端”按同一套话术说话。
说得再直白一点：谁也不许再发明私有的插头，大家都照一份说明书来。说明书之外的部分，各家的自由。
MCP 最初由 Anthropic 提出并开源，随后被多家模型厂商和开发工具接纳——开放标准的价值就在这里：任何一方都可以照着实现，不需要向谁申请许可。
协议规定的东西其实很朴素：怎么建立连接、怎么列出对方有什么、怎么发起调用、结果怎么带回、出错怎么报。就是这些“接头暗号”，让两端不必再互相猜。
两个角色：客户端与服务器
MCP 这套模型里只有两个角色：
- 客户端（Client）：挂在宿主应用这一侧，负责提问。你的 Agent 应用、IDE、聊天工具，都住在这一头。
- 服务器（Server）：把一项能力包成标准服务，负责应答。本地文件系统、一个数据库、某个平台的接口，都可以被包成一个服务器。
连接规则很干净：一个客户端可以连多个服务器，一个服务器也能被多个客户端复用。连上之后先握手、互报能力，再按需调用。
第一轮往来的样子，像开店前的对表：服务器递上一份清单——“我这儿有文件读取、有数据库查询”；客户端挑出自己确实需要的那几项，记进本地。从此每次调用，双方都按同一套格式收发。
换模型不用重写服务器，换服务器不用升级客户端——中间的协议层不动。
这一步的意义，就是把乘法变成加法：原来要维护“模型数 × 工具数”份适配，现在只需要“N 份客户端 + M 份服务器”。
菜单：工具与资源
服务器对客户端亮出的清单，主要是两样东西：
- 工具（Tools）：能让模型“动手”的动作——查订单、发消息、改文件。有副作用，所以调用前通常要过一道授权确认。
- 资源（Resources）：供模型“读取”的内容——文件、记录、文档。只读，不改状态。
还有一类叫提示模板（Prompts）：把常用任务预先写好，让用户在界面上一键发起。
这些声明都是结构化的：每个工具带着参数说明，参数带着类型与约束。这份结构会原样转给模型，模型照着它来选——服务器把清单写得越清楚，模型猜的力气就省得越多。
值得留意的是流程里谁在动手：模型从头到尾只是看菜单点菜；真正的下单、执行、权限把关，全都由客户端那一侧的宿主应用完成。模型只负责点单，执行与权限始终握在宿主手里。
生态：一次编写，处处可用
对单个开发者，MCP 的好处是省事：一个工具写一遍，所有支持这套协议的客户端都能用。
更大的东西在后面——网络效应：服务器越多，每个客户端能调用的能力越丰富；客户端越多，写服务器越值得。工具作者的处境从“写 N 份适配”变成“写一份，处处可用”，生态的正循环就此转起来。
支持名单也越拉越长：从模型厂商到编辑器、终端、各类开发工具，都在往这套协议上靠。一个接口标准能走多远，看的从来不是它多优雅，而是接的人多不多。
当然，边界也要看清：
- 服务器是别人给的代码：连上它意味着信任它，权限必须显式授权、按最小必要给
- 协议统一接口，统一不了质量：服务器写得烂，照样把烂服务递到你面前
- 它管连接，不管编排：多个工具怎么配合、谁先谁后，仍归调用方自己设计
协议管不到的地方
回头说一句常被忽略的话：MCP 只是“接线方式”，不是“智慧”。
模型会不会用这个工具、该不该用、用完结果可信吗——协议一概不管。接线标准让插头终于对得上了，但电器的品质、用电的规矩，还是各家自己的功课。安全、评测、兜底这些词，会比协议的讨论活得更久。
墨造旁注：协议解决的是“能不能连”，剩下的“连上之后靠不靠得住”，才是真正的长跑。
骨架之外
把这个系列串一遍：最小循环 → 工具 → 记忆 → 检索 → 分工 → 协议。一套能自己干活的 Agent，骨架到此基本立住了。
接下来轮到成品了：真实世界里天天有人用的那些 Agent，各自把骨架装出了什么脾气——手感从哪儿来，又栽过哪些跟头。剩下的地图，一篇一篇慢慢走。