按需加载 — 技能为什么长成三层
这一章讲三件事: 为什么模型够聪明还需要技能; 「上下文有限」这一条硬约束怎样塑造了技能的三层结构; 以及 description——那张名片——凭什么决定技能的生死。 读完你能回答第 01 章欠下的所有「为什么」:为什么不重启就不生效、为什么装多了会出问题、 为什么触发条件写在正文里没用。
1. 有能力做,不等于做得对
先看现象。 你让智能体根据一份销售数据 CSV(CSV 就是用逗号分隔的纯文本表格,Excel 能直接打开) 整理分析报告。它能出,但:标题格式不对、金额小数保留五位、结论段先写建议再写核心发现—— 一堆地方不合你们团队的规矩。你交代一堆要求让它重做,这次好了,下个月还得再说一遍1。
你可能会想:写个超长的提示词模板(写好存着、反复粘贴用的那段话)存起来,每次复制粘贴不就行了?书指出这条路有两个硬伤2:
- 极其挤占工作记忆。 几千字的提示词一旦塞进上下文,迅速耗掉有限容量, 模型注意力(分给每段文字的关注度)分散,容易「看漏行」忘掉后半段指令;
- 无法稳定 绑定工具流。 如果任务还需要先查数据库、再跑 Python 画图, 纯文本提示词很难让它连续稳定地完成这些调用。
所以根本原因在更深处:智能体的智能已经够用,但不了解你的业务规范。 你们公司的规矩、你踩坑总结的经验,这类知识有个专门的名字——流程性知识 (procedural knowledge,即「怎么把一件事做好」的知识,区别于「是什么」的知识)3。 再强的通用模型,也不可能凭空猜透你私人的工作流。做技能,就是把你的隐性经验 连同它要用的工具,封装成 AI 的 SOP(标准作业程序,即固定下来的操作规程)4。
这里有一个反直觉的判断,值得单独一段:
模型越升级,技能反而越值得投入。 早期模型像记性不好的实习生,复杂手册执行到一半就忘; 现在的顶尖模型指令遵循能力极强——菜谱越具体,菜越惊艳。 模型升级解决「能做好」,技能解决「做得对」5。
2. 四大进化:技能比「长提示词」强在哪
先明确比较对象:被比下去的不是日常一句话指令,而是试图充当操作手册的长篇提示词6。 四大进化,每一条都值得记住:
| 进化 | 提示词 | 技能 |
|---|---|---|
| ① 按需加载 | 多长就占多少工作记忆 | 启动只载名片,用到才读正文;细节拆到参考文档按需读7 |
| ② 文件系统当工作台 | 一切挤在聊天框,清空即消失 | 中间结果随时存文件;翻译长文每章一个文件,哪章不满意单独重译8 |
| ③ 协同工作流 | 各模板互不相识 | 多个技能接力(素材分析→翻译→润色→配图),上一手的输出文件是下一手的输入;还能带脚本干硬规则活(分块这种活用提示词做「既不稳定又浪费词元」,几行代码就能搞定)9 |
| ④ 单一信源 | 模板散落各处,改一份别处还是旧版 | 唯一一份 SKILL.md,原地迭代全局生效,天然支持版本管理,经验像资产越攒越厚10 |
词元(token)这个词在这里必须讲清楚:它是模型计算文本长度的 单位, 中文里 1 个汉字大约消耗 0.5~2 个词元,取决于模型怎么分词(怎么把文字切成词元),本书统一按 1.3 估算11。 下面所有「空间账」都用它算。
3. 上下文:一块有限的台面
第 02 章把上下文比作厨房台面,现在把账算细。
台面多大? 目前主流模型的上下文窗口(工作记忆的容量上限)从 20 万到 100 万词元不等; 100 万词元大约相当于一本 77 万汉字的长篇小说12。听着很多,但有个容易忽略的细节: 每一轮对话都会累积进上下文,雪球越滚越大13。
你「跟 AI 聊着聊着它就变笨了」,书给了两个原因14:
- 工作记忆被历史对话占满,新信息挤不进去;
- 更隐蔽的:即使还没满,堆的信息越多,模型的注意力越分散,开始顾此失彼、漏掉关键指令—— 台面没堆满,但摊了几十份菜谱,厨师也已经找不到东西了。
应急办法很简单:开新对话(等于清空台面),把之前的关键结论复制到新对话第一条消息里—— 既释放空间又保留要点15。更优雅的办法(子智能体)留到第 06 章。
4. 主走查:「帮我写周报」的三层加载
现在把全书最核心的机制走一遍。 官方叫法是渐进式披露(progressive disclosure): 不把技能文件一股脑塞进上下文,而是拆成三层,按需逐层追加16。 场景还是那个周报技能,从你按下回车开始:
① 启动时(你还没说话)
所有已装技能的名片(YAML 前置信息)被载入上下文
周报技能的名片:name: weekly-report + description(约百来字)
│
② 你说「帮我写周报」
智能体拿这句话与所有 description 比对 → 命中周报技能
(名片早就在台面上,这一步不消耗额外词元)
│
③ 触发:框架调用一次文件读取工具,把 SKILL.md 全文载入上下文
(代价 1:消耗一次工具调用;代价 2:全文留到对话结束)
│
④ 大模型按正文规则执行:确认任务 → 表格三列 → 亲和语气 → 存 Markdown
│
⑤(若正文指向关联文件)按需再读第三层
图说:①是启动的一次性成本;③是每次触发的成本;⑤只有复杂技能才有。
逐层说清:
第一层:技能名片。 必填 name + description;选填 license(许可)、compatibility(环境要求)、 metadata(自定义的元数据,即额外说明信息)、allowed-tools(限制可用工具)17。 名片体量小,装一二十个技能也不会轻易撑爆上下文窗口18。
第二层:SKILL.md 正文。 一旦锁定技能,智能体在后台调用一次文件读取工具, 把全文载入。触发是有代价的:多了一次工具调用,而且大模型会把这份内容当「历史聊天记录」 记住——对话结束前一直占地方19。
第三层:关联文件(linked files)。 复杂技能的「扩展弹药」,分三类: references/(参考文档)、scripts/(脚本)、assets/(静态资源)。 书里的例子是一个处理 PDF 的技能:SKILL.md 只讲核心流程;「填表单」的琐碎规范拆成 forms.md, 遇到填表任务才读;提取表格的重计算写成 pdf_tools.py 交给框架跑;标准表单样板放 assets/20。
第三层怎么被「牵出来」?靠 SKILL.md 正文里的大白话:条件 + 相对路径—— 「如需填写 PDF 表单,请先阅读 forms.md 并按步骤操作」。用户只要了文字提取?智能体根本不碰 forms.md, 它几千字的内容对上下文零消耗21。
书里给这条定了格式纪律:引用关联文件用从技能的根目录(就是技能文件夹本身)出发的相对路径,且只引用一层, 不要 A 引 B、B 又引 C 的嵌套链——层级越深,智能体越容易迷路22。
脚本的账要单独算(第 02 章说过脚本由框架跑):繁重计算在上下文之外的「独立沙盒」里运行, 回到上下文的只有一行精简结果——花几十个字的工作记忆,换来后台几万词元的数据处理23。 这就是「技能为什么能干重活」的算术基础。
补充(不在书里,依据我们的 protocol 书架): 这套三层结构在 Agent Skills 规范里有明确的 token 预算口径——第一层(元数据)启动时全部加载、约 100 词元/个;第二层(SKILL.md 正文) 激活时加载、建议不超过 5000 词元;第三层(资源文件)正文用到才加载。 规范原文还要求文件引用保持一层深——与书里的纪律逐条吻合24。
5. 三个管理技巧:把空间账当真
三层机制给了你省空间的架构,但用法上还有三条纪律25:
技巧一:严控常驻数量。 官方建议安装上限 20~50 个。书算了一笔中文环境的账: 按每个名片 100 个汉字、1 汉字 1.3 词元折算,50 个技能 = 6500 词元—— 已超出 200K 窗口模型通常留给系统提示词(模型开机先读的后台指令)的 2% 预算(约 4000 词元)。 所以全局技能少而精(建议 10 个以内),场景专属的放项目目录26。
技巧二:正文必须克制。 技能一旦触发就收不回去,别写成几万字的百科全书。 官方建议:SKILL.md 正文不超过 5000 词元(约 3800 个汉字)、不超过 500 行; 完整 API 规范这类重型内容拆进关联文件,用「条件 + 相对路径」按需读取27。
技巧三:适时开新对话。 长对话里连续触发多个复杂技能,占用会累积; 当回复变卡、质量下降、开始「忘事」,最彻底的解法就是开新对话,一键清空工作记忆28。
6. description:唯一的触发开关
这一节回答第 01 章排查「技能不生效」时欠下的原理。
一个底层事实:你安装的所有技能的 description,会在智能体启动的瞬间, 直接被注入大模型的「系统提示词」——系统提示词是模型开机时先读到的那段后台指令, 你在聊天框里看不见它29。所以有个反直觉的结论:
description 的首要读者是 AI,不是人。 模型决定要不要调用一个技能, 唯一的决策依据就是 description30。
它怎么判断? 不是死板的关键词精确匹配——模型动用自己的推理能力, 判断「哪个 description 与当前任务最相关」31。
由此立刻推出一条新手最常踩的坑:把「当用户说……时使用本技能」写进正文,等于白写。 正文属于第二层,模型读到正文时,「用不用这个技能」的决策在第一层早就做完了32。
写不好有两种代价33:
- 误触发:模糊的描述误导模型加载了不相干的技能——白花一次工具调用,还占上下文;
- 漏触发:装了技能模型却没认出来,自己即兴发挥,结果不稳定。
还有一个容易被冤枉的情况:模型天生偏向少用甚至不用技能(书里叫「工具调用惰性」)—— 它觉得自己能搞定就不查技能。所以 description 必须主动覆盖用户的高频说法,不能等着被精确命中34。 反过来,「把 hello 翻译成中文」没触发翻译技能,不算 bug——任务太简单,它判断自己就行; 只有当你期望(盼着)技能介入规范流程而它没介入时,才需要排查35。
怎么写? 极简公式:description = 功能定义 + 触发场景/触发词36。 要贴合用户实际说法,比如不写「处理数据」,写「处理 CSV/Excel 数据,用户提及数据统计、报表生成时触发」。
两个陷阱37:
| 陷阱 | 反例 | 正确做法 |
|---|---|---|
| 人称混乱 | 「我可以帮你处理 Excel 文件」——模型读到会懵:谁是「我」? | 去掉人称代词,陈述句直接写功能:「处理 Excel 文件并生成报告」 |
| 描述太长 | 名片预算是大家分的 | 控制在 100 字左右,最多 200 字(扣子商店上限 200 字;Claude Code 给所有 description 的总预算是上下文窗口的 2%,单条硬上限 1024 字符,通用技能推荐 50~200 字符) |
高阶技巧——反向触发词:技能装多了会「内卷」(翻译技能和润色技能抢活), 这时在 description 里划清界限: 「将文章翻译为目标语言。当用户需要翻译文章、网页内容时使用。 不用于润色已有中文内容,不用于改写或摘要。」一句话点明最容易混淆的场景就够; 装三五个技能用不上,装到 20 个你会感谢它38。
7. 作者的判断与证据,边界与局限
书里的判断(有论证): 「上下文窗口有限 → 必须按需加载」这条链,书里用容量数字(200K~1M 词元)、 累积机制、注意力稀释现象和三层开销逐级支撑,是全书论证最完整的一段。
书里的判断(引用权威): 「安装 20~50 个」「正文 5000 词元」「2% 预算」均标注为官方建议, 不是作者拍的数;书还诚实补了一句:主流模型窗口往往更大,装 50 个通常不至于过载39。
书里的坦白: 名片加载后触发匹配「不消耗额外词元」的前提是名片已经在上下文里—— 启动注入本身是花过钱的,只是摊到每次对话之前40。
边界:
- 数字会漂:上下文窗口大小、2% 预算、字数上限都是 2026 年各平台的口径,会随版本变;
- 「注意力稀释」书里给的是现象描述(台面摊几十份菜谱的比方),没有给出机制层面的量化(拿数字测出来)研究—— 照实说,这部分是行业共识性的经验而非被证明的定理;
- 书没讲模型内部怎么实现「注意力」,那属于原理层,我们的《这就是 ChatGPT》拆解有。
8. 可带走的
主走查一行复述:「帮我写周报」→ 名片比对命中(零额外成本)→ 框架读一次文件、 SKILL.md 全文进上下文(留到对话结束)→ 按规则执行;重活交给关联文件里的脚本,上下文只收一行结果。
- 模型缺的不是智商,是你的流程性知识;模型越强,技能越值钱;
- 技能四进化:按需加载、文件当工作台、协同工作流、单一信源;
- 上下文窗口有限且只增不减;变笨 = 空间被占 + 注意力被稀释,后者空间没满也会发生;
- 三层加载:名片常驻(小)、触发读正文(一次工具调用 + 持续占用)、关联文件按需(脚本只回一行结果);
- SKILL.md 引用关联文件:条件 + 相对路径,只引一层,不嵌套;
- 装技能 20~50 个封顶,全局 10 个以内;正文 ≤5000 词元;卡了就开新对话;
- description 是模型选技能的唯一依据,首要读者是 AI——触发条件写进正文等于白写;
- 公式:功能定义 + 触发场景/触发词;不写人称;100 字左右;技能多了加反向触发词;
- 模型有「工具调用惰性」,description 要主动覆盖高频说法。
9. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 有能力≠做得好、CSV 例子 | 第 2 章 | text/03-ch02.txt:261(搜「做得好」) · text/03-ch02.txt:265(搜「销售数据」) |
| 长提示词两个硬伤 | 第 2 章 | text/03-ch02.txt:273(搜「工作记忆」) · text/03-ch02.txt:276(搜「工具流」) |
| 流程性知识与 SOP | 第 2 章 | text/03-ch02.txt:144(搜「流程性知识」) · text/03-ch02.txt:283(搜「SOP」) |
| 模型越强技能越值得投入 | 第 2 章 | text/03-ch02.txt:286(搜「恰恰相反」) · text/03-ch02.txt:291(搜「能做好」) |
| 四大进化 | 第 2 章 | text/03-ch02.txt:299(搜「按需加载」) · text/03-ch02.txt:306(搜「持久化工作台」) · text/03-ch02.txt:325(搜「分块」) · text/03-ch02.txt:332(搜「单一信源」) |
| 窗口大小与词元换算 | 第 2 章 | text/03-ch02.txt:347(搜「200K」) · text/03-ch02.txt:353(搜「1.3 个词元」) |
| 变笨的两个原因 | 第 2 章 | text/03-ch02.txt:359(搜「占满」) · text/03-ch02.txt:361(搜「注意力」) |
| 渐进式披露与三层 | 第 2 章 | text/03-ch02.txt:374(搜「渐进式披露」) · text/03-ch02.txt:379(搜「第一层」) · text/03-ch02.txt:402(搜「第二层」) · text/03-ch02.txt:417(搜「第三层」) |
| 触发的代价 | 第 2 章 | text/03-ch02.txt:410(搜「工具调用」) · text/03-ch02.txt:412(搜「挤占宝贵的上下文空间」) |
| 关联文件与牵出方式 | 第 2 章 | text/03-ch02.txt:417(搜「关联文件」) · text/03-ch02.txt:443(搜「reference.md」) · text/03-ch02.txt:427(搜「forms.md」) |
| 引用只一层 | 第 2 章 | text/03-ch02.txt:440(搜「相对路径」) |
| 脚本沙盒与一行结果 | 第 2 章 | text/03-ch02.txt:460(搜「沙盒」) · text/03-ch02.txt:463(搜「一行精简的运行结果」) |
| 三个管理技巧 | 第 2 章 | text/03-ch02.txt:507(搜「20 ~ 50」) · text/03-ch02.txt:511(搜「6500」) · text/03-ch02.txt:538(搜「5000 个词元」) · text/03-ch02.txt:548(搜「新对话」) |
| description 注入系统提示词 | 第 2 章 | text/03-ch02.txt:560(搜「系统提示词」) |
| 首要读者是 AI、白写 | 第 2 章 | text/03-ch02.txt:565(搜「首要读者」) · text/03-ch02.txt:575(搜「等于白写」) |
| 误触发/漏触发/惰性 | 第 2 章 | text/03-ch02.txt:585(搜「误触发」) · text/03-ch02.txt:591(搜「少用甚至不用技能」) |
| 公式与陷阱 | 第 2 章 | text/03-ch02.txt:607(搜「功能定义」) · text/03-ch02.txt:626(搜「人称混乱」) · text/03-ch02.txt:645(搜「1024」) |
| 反向触发词 | 第 2 章 | text/03-ch02.txt:658(搜「反向触发词」) · text/03-ch02.txt:654(搜「反向触发词」) |