Tool / MCP / Skill：能力的三代封装

🎒 预备知识：完成上一课「A1」（零基础入口：第 0 课）

一、三代演化的历史逻辑（每代解决上一代的什么痛）

第一代：函数工具（2023）。L7 讲的机制。痛：每个 harness（模型外的运行时容器，A17 详述）自己注册函数， 复用靠复制代码。更大的痛在后面——schema 常驻。

第二代：MCP（2024）。Model Context Protocol 把"工具服务器"标准化： 工具以独立进程运行，harness 作为 client 连接（本地 stdio 或远程 HTTP），自动发现对方的 tools / resources / prompts。于是生态出现——GitHub、数据库、浏览器各出官方 server， 你的 agent 挂上就能用。解决：跨项目复用与生态。没解决：schema 还是全量进上下文， 挂 10 个 server 几十个工具，窗口被吃掉一大块（后来加了 tool-search 缓解）。

第三代：Skill（2025）。把"能力"从函数升维成一套流程： SKILL.md（说明书，<200 行）+ references（领域知识）+ scripts（可执行脚本）。 harness 只把每个技能的 frontmatter（markdown 文件顶部两行 --- 之间的小块元数据，L6 详述；技能的只含 name + description，约一行）常驻注入， 模型决定用哪个技能后才加载正文，脚本则永远不进 prompt 只被执行。 解决：token 危机 + 能力的可读可审计（markdown 是人能审的，JSON schema 不是）。

二、token 算术（Skill 存在的硬理由）

路线 A：100 个函数工具
  常驻 = 100 × (name + description + schema) ≈ 100 × 25 token ≈ 2500 token / 每轮

路线 B：114 个 Skill（Easel 实际规模）
  常驻 = 114 × frontmatter 一行 ≈ 114 × 10 token ≈ 1100 token / 每轮
  触发 2 个技能时另加 ≈ 2 × 2000（SKILL.md 上限 200 行）——用才付

差距看着只有两倍多，但真正的量级差在能力规模上限：路线 A 到 500 个工具时 常驻 1.2 万 token（约 1/10（按 128K 窗口）永远被吃掉），路线 B 到 500 个技能时常驻仍只有约 5 千 token， 且每个能力的"说明书"可以有 200 行深度。Skill 本质是把 schema 的'全量常驻'换成了'索引常驻 + 正文按需'—— 和操作系统的虚拟内存是同一个思想：页表常驻，页面按需调入。

三、三者不是互斥，是分层

真实系统常常共存：Easel 底层是 OpenClaw 的函数工具 + MCP 支持，上层用 Skill 组织业务能力；OpenClaw 甚至把 MCP 工具包装成进程内函数统一执行（agent-bundle-mcp-materialize.ts）。 选型只问一个问题：这个能力是"一个动作"还是"一套流程"？ 查天气=动作→工具；管理 issue=一组动作→MCP server；"做论文解读视频"=流程→Skill。

四、常见踩坑

坑 1：工具描述互相重叠。两个工具 description 都写"获取数据"——路由抖动， 每次选不一样的。描述要划边界（负空间），Easel 技能规范强制写"与相邻技能的边界"就是防这个。

坑 2：MCP server 挂一堆不用的。每个都贡献常驻 schema。原则： 这个会话真会用吗？不会就别挂。

坑 3：Skill 写成没人能触发的文档。frontmatter 的 description 含糊（"处理内容相关任务"）， 模型永远路由不到。Skill 的 description 要写用户会怎么说（触发场景原话）。

五、检索练习

六、出口检验

给五个能力选封装形态并各说一句理由：查天气、管理 GitHub issue、写小红书笔记、读文件、 做论文解读视频。再加一题：如果你要给公司内部 200 个业务操作做 agent 化，三代形态怎么组合？ 发到对话里我批改。