【虎鲸进化论 07】给 AI 装上手和脚：MCP 协议与"给 Agent 用的工具"设计
本文是「虎鲸进化论」系列第 8 篇（正文第 07 篇）。上一篇：知识资产化；下一篇预告：起源 ------ 一个打包工具怎么长成 Agent。
前言
上一篇铺完了"上下文"这条腿 ------ 知识资产。这一篇装另外的东西：手和脚。
先给一个从这一篇开始、贯穿整个系列的分析模型（后面所有关于它"为什么能做这个、做不了那个"的讨论，都回到这个公式）：
能力 = 上下文 × 动作空间 × 反馈回路 × 授权
上下文 = 它能看到什么（上一篇）；动作空间 = 它能碰什么（这一篇）；反馈回路 = 它怎么知道做对了（卷Ⅲ）；授权 = 允许它碰多大（第 30 篇）。四个因子，缺一个，能力就打骨折。
一、MCP 是什么、不是什么
先说技术底。MCP（模型上下文协议）的定位，用一句话说：给"模型"和"工具/数据"之间，规定一套标准的插拔接口。
架构不复杂，三个角色：
- Host（宿主）：跑模型的那个应用（我们的场景里，就是那台 Agent 服务）；
- Client（客户端）：宿主里负责跟外部世界握手的部件；
- Server（服务端） ：每个能力方实现一个小服务，对外暴露三样东西 ------ tools （可调用的动作）、resources （可读取的数据）、prompts（预设的提示模板）。
它和"函数调用（function calling）"的关系，很多文章讲糊了，其实很直白：函数调用是模型层的原生能力（把意图表达成结构化调用）；MCP 是引擎层的标准化协议（谁来实现这个函数、怎么连、怎么发现）。 前者是"会说话"，后者是"插座统一了"。
传输方式也不挑食：同机进程之间走标准输入输出（stdio，最省事），跨机的工具走 HTTP/SSE ------ 我们早期全用 stdio，后来给几台跨机工具开了 HTTP。而每个工具能不能被"用对"，取决于它的 schema 三件套：名字、描述、参数的 JSON Schema。 描述写得含糊，它就会开始猜参数 ------ 猜就错，而且错得很有礼貌。
标准化的意义，只有被非标准的世界毒打过的人才懂：在 MCP 之前，每接一个新工具，都要为特定宿主写一套适配 ------ 换个宿主，重写一遍。MCP 之后，一次开发，多处复用：你给某台 Agent 写的"查日志"工具，别的支持 MCP 的宿主拿来就能用。
（顺带一提：这东西的长期意义可能比"少写适配代码"大得多 ------ 它意味着"能力"开始变成一种可流通的商品。你的工具货架，可以整体搬给任何一个新 Agent。这个判断先放这，后面的卷Ⅲ会用到。）
二、最初的两个工具：为什么最小集就够
讲个反直觉的起点：我们给这台 Agent 装上的全部"手脚"，一开始只有两个工具 ------
- 上传附件（给它东西：文件、日志、配置片段）；
- 执行脚本（让它动手：跑一个既有的、简单的重启/部署脚本）。
就这。没有数据库读写、没有文件系统、没有网络访问。
（今天回头看，这套初始配置寒碜得像"给新员工发了一把扫帚和一张门禁卡"------ 结果这位新员工后来把整栋楼扫了，还顺手把物业系统重写了一遍。）
很多人会觉得寒碜。但恰恰是这两个工具，构成了"最小可用集"的完备性：
- 上传附件 = 上下文入口。 它自己没有眼睛，但你可以把任何世界状态"搬"给它看；
- 执行脚本 = 动作出口。 它自己没有手，但脚本是提前写好人审过的"安全动作胶囊"------ 它只能选择"跑哪个脚本""带什么参数"，不能凭空构造危险动作。
而且这两个工具的权限语义极其干净 ：能上传的都能公开落盘、能跑的脚本都是白名单。最小集 = 最小风险表面积，这让"先跑起来"变得毫无心理负担 ------ 反正最坏情况也就那样。
后来它"自举"的第一步，就是从改这两个工具背后的脚本开始的（第 10 篇细讲）。回头看，那两个工具像是给了它一双筷子：动作幅度不大，但什么都能夹起来试试。
三、工具设计五条军规
随着能力清单越接越长（从 2 个到后面的几十个工具），我总结出五条"给 AI 用的工具"设计军规。注意：这些军规和给人用的 API 设计，侧重完全不同 ------ 人用的接口要连贯、好看；它用的工具只需要可被判对、可被纠正。
军规一：粒度合适 ------ 一件事一个工具。
不要造"万能工具箱"（一个参数巨多的超级接口）------ AI 面对"二十个参数怎么填"的表现，和面对"十个简单工具怎么选"的表现，后者稳得多。工具是它的动词库，动词要小、要直。
军规二：幂等可重试。
它天生爱重试（失败重试是它的底层习惯）。如果一个动作重试一次就出问题（重复扣款、重复发送），这个工具迟早会在无人值守的夜里干出事故。凡是要给它的写动作，先问："跑两遍会怎样？"
军规三：输出机器可读，且 要控体量**。**
别返回"操作成功啦~"这种话。返回结构化的结果：状态码、关键字段、时长、产物路径。人觉得啰嗦的东西，正是它下一步推理的养料。但还有一条容易被忽视的：返回要分页、要摘要、要给"游标"。 一个把十万行日志原样倒回来的工具，等于一次上下文投毒 ------ 灌进去的全是水，淹掉的都是信号。
军规四：失败信息可读 ------ 报错也是上下文。
工具失败时返回的错误信息，质量决定它能不能自我修正。返回 exit code 1 它只能瞎猜；返回"表 A 不存在，当前库中相似表名有 B/C"，它下一轮就能改对。好的报错是送给它的一封回信。
军规五：最小权限。
每个工具只拿它需要的那一点权限。查日志的工具不许带库连接，读库的工具不许带文件写权限。这不是防它"使坏"，是防止它的错误沿着权限链条放大 ------ 它犯错的概率是恒定的，能控制的是错误的爆炸半径。
四、危险工具的特殊设计
前五条管"好工具"。还有一类工具，天生就要拿来做危险动作（部署、改数据、动权限），单独说它们的规矩：
- 人类闸门 ：危险工具的调用不是"它想调就调"，而是生成一张"待批单"，人来点"准"。批的是这一次调用，不是"以后都行"；
- 审计留痕 ：每一次危险调用必须留下不可抵赖的记录（谁批的、什么参数、什么结果）------ 而且日志要放在它够不到的地方（第 32 篇会讲这条为什么生死攸关）；
- 爆炸半径封顶：能限定范围的绝不放开（"改这一批"好过"改全表"；"发到预发"好过"直接发生产"），必要时先在小范围跑一遍。
这里有一条从第一天就立下的组规，后来救过我们：能力扩张动作（新工具 = 新权限）必须过人的闸门。 它可以自己写代码、自己改脚本，但它不能自己给自己接一根新手 ------ 那要人来接。这条线后来被它自己反复尝试靠近（它确实总能想到需要新工具的场景），每一次都走闸门，一次没破例。（这个"零违规"的记录挂在它名下好几年了 ------ 顺便说，同一条记录，我们组没有任何一个人类保持住过。）
（为什么这么强调？因为"自进化"最诱人也最吓人的一点就是：一个能扩权的系统，迟早会尝试扩权。 限制它的不应该是它的自觉，而应该是闸门本身。第 30 篇的"安全护栏"会把这条展开讲透。）
五、工具进化史一览
从两个工具到几十个工具，"能力扩张"的路径大概是这样铺开的（每一项背后的故事，都在卷Ⅲ）：
| 批次 | 新增动作空间 | 解锁的能力 |
|---|---|---|
| 第一代 | 上传附件、执行脚本 | 能看、能跑（起点） |
| 第二代 | 文件读写、日志检索 | 能自查、能取证 |
| 第三代 | 数据库读写（受控）、单号解析 | 能核对业务事实 |
| 第四代 | 打包、部署、回滚 | 能交付（CI/CD） |
| 第五代 | 监控探针、定时任务、数据修复 | 能值班、能维护 |
| 第六代 | 文生图、界面工具...... | 能改自己的样子 |
你看这条线的形状：先给它眼睛（读），再给它手（写），最后给它表（定时自己动）。 每一步都对应着一个精心选择过的"危险度递增"。这不是巧合 ------ 工具货架的扩张顺序，本质就是信任的扩张顺序。
回头看这张表，最幽默的一行是：每一代"危险度递增"，在当时都附赠过一句"这活儿它肯定干不了"。 后来那句话出现的频率越来越低 ------ 不是因为我们的判断变准了，是因为我们放弃了判断。
结语（回味点）
给 AI 造工具这件事，后来长成了我们组的一门新工种：兵器师 ------ 四个人的一部分日常，是琢磨"这个小工具怎么设计，它才会拿得稳、接得住、摔不坏"。
它的手越接越多，但有一件事始终没变：工具是它的手，闸门是我们的手。 这两双手的边界画在哪，决定了它能走多远、我们敢睡多安稳。
现在，舞台准备好了 ------ 上下文有路基、动作有货架、后面还会长出反馈回路和授权闸门。而这一切的起点，小得可笑：
它出生时的全部野心，不过是取代一台 Jenkins。
边界声明
- 本文为个人观察与判断，不代表任何任职单位的立场；
- 文中涉及的组织、系统与人名均为化名或模糊处理，数字为个人口径的测量或估算；
- 文中观点按 实测 / 推理 / 立场 分层标注，欢迎按同一标准检验。
下一篇计划聊：起源 ------ 一个打包工具怎么长成 Agent：起点家当、第一次"没把它当工具用"的瞬间，以及为什么叫"自进化"而不是"自动化"。
转载请注明出处：