写 Agent skill 的人很多真去量过一份 skill 有多大的人很少。我量了。样本是一份线上生产环境正在跑的SKILL.md不是玩具 demo。结果比我预估的严重 17 倍——我原先拍脑袋估的是 800 token。先摆数字字符 o200k cl100k SKILL.md 24,624 14,147 18,018 references/*.md3 份 6,672 2,870 3,254 摘要那一条name description location XML 包装 263 157 212摘要 / 正文 157 / 14,147 1.1%。那么我们如何做测量呢一、怎么量三行代码你可以拿自己的 skill 复现importtiktoken,pathlib enctiktoken.get_encoding(o200k_base)# cl100k_base 是老口径见下ppathlib.Path(path/to/SKILL.md)print(len(p.read_text()),len(enc.encode(p.read_text())))两个口径都给是因为它们能差 27%14,147 vs 18,018。中文占比高的 skill 差得更多。报数字的时候不写口径等于没报——这是我踩过的第一个坑一开始拿 cl100k 量、拿 o200k 的窗口算白紧张了一轮。摘要那一条指的是 skill 没被激活时常驻在 system prompt 里的那部分namedescription 文件位置 外面那层 XML 包装。263 个字符157 token。二、渐进披露不是优化是可行性前提很多人把skill 按需加载理解成一个省钱的优化项——能省就省不省也能跑。算一笔账就知道不是。假设你有 10 个这种规模的 skill对一个正经系统来说10 个不多全塞正文 141,470 token 每轮付 ← 直接爆窗口一轮都跑不起来 只放摘要 1,570 token 每轮付 真读一个 14,147 token 一次性14 万 token 每轮。这不是贵不贵的问题是一轮都跑不起来。所以只放摘要、用到才读正文这件事在 skill 数量上到两位数之后是能不能跑的前提不是省不省钱的选择。渐进披露省掉的那 98.9%是你的系统能存在的理由。反过来说也成立如果你只有两三个 skill你确实感觉不到差别——这就是为什么很多人做到一半、形状建了一半就停了。下一节就是这样一个例子。三、references/建了一次都没被引用过这份 skill 是有references/目录的。三个文件写得也不差references/commands.md 1,154 token references/errors.md 1,083 token references/params.md 633 token ──────────── 2,870 token然后我全目录 grep 了这三个文件名和references这个词→ 零命中没有任何一个地方引用它们。SKILL.md 正文里没提代码里没提索引里没提。这 2,870 token 写下来了模型永远读不到。这不是谁偷懒。渐进披露的目录形状建了线没接上——建目录这个动作有很强的我做完了的错觉而正文里真的有一句话告诉模型什么时候去读它这一步没有任何东西会提醒你漏了。所以结论是一条闸不是一句提醒加一个 CI 检查skill 目录里每一个存在的引用文件都必须在正文里被真的引用过。写了没接线判红。形状不等于机制。靠自觉维持的东西扛不过第二个往里写代码的人。四、62.8% 的 token 压在一个小节里把 SKILL.md 按二级标题拆开量主流程小节 8,890 token 62.8% 调用方式 1,290 9.1% 错误处理 649 4.6% 其余 13 个小节 3,318 23.5% ────────────────── 14,147 100%一个小节吃掉六成。而这个小节内部是线性的 Step 0–6Step 0 1,645 Step 3 1,033 Step 4 836 Step 4.5 2,529 ← 最大的一块 Step 5 1,080关键的一句话一次对话里模型不可能同时处于 Step 2 和 Step 5。链路还停在前半段的时候Step 4.5 那 2,529 token 是纯浪费——它不只是费钱它还在稀释当前这一步真正重要的约束。模型手上多拿着 2,500 token 跟眼下无关的规则判断只会更差不会更好。所以正确的形状不是一个 14k 的文件SKILL.md ~2k 总原则 错误铁律 流程骨架每步一行 steps/step0.md 1.6k 走到哪步读哪步 steps/step4_5.md 2.5k ... 14k → 常驻 2k 按需 1–2.5k这里有一层很多人没走到的区分第一层渐进披露description 常驻、正文按需读。——这层我量的这份 skill做对了。第二层渐进披露skill 内部按 step 拆走到哪步读哪步。——这层没做一激活就是整份 14k。第二层才是大头。第一层省的是没用到的 skill第二层省的是用到了、但这一步用不上的那 80%。五、一个没人提的坑自动压缩会把你的口径悄悄摘要掉这条我觉得最值得单拎出来因为它不报错。skill 正文一旦被读进来它就是对话历史里的一条 message。而现在的 agent 框架基本都带自动压缩context 超阈值就摘要折叠。那下一次压缩就会把你的口径摘要掉。想想这意味着什么。假设你的口径里有一条明确的禁止性约束模型不会跟你说我忘了那条禁令。它只会开始做那件你禁止过的事。约束丢失是静默的。你不会在日志里看到任何异常你只会在某一天看到一个不该发生的输出。两条路做法代价A把 skill 正文标成压缩时保留保留的都是原文压缩基本省不下东西B ✓正文不进历史每轮按当前 step 重放每轮付 1–2.5k但约束永远是原文选 B。每轮 1–2.5k 比一次性读 14k 还便宜更要紧的是——不可撤回的动作所依赖的约束不能靠摘要传递。如果你的 skill 只管回答得好不好摘要掉了顶多效果差一点。如果它管的是能不能执行、执行了收不回来的那一类动作那它就不能活在会被摘要的那一层。配套的闸很直接压缩发生之后断言当前 step 的口径原文仍逐字节在上下文里——不是还在是是原文。六、顺带纠一个流传很广的前提长 prompt 不是延迟的主因我一开始也是奔着太长了会慢去量的。量完发现动机错了。prefill 是并行的通常不是瓶颈。真正的耗时是 decode 和多轮 tool 往返。对延迟来说减少轮数 ≫ 缩短 prompt。这有个很实际的推论——如果链路上有些判断根本不需要模型把它们从 prompt 里拿掉收益是双份的prompt 短了而且少了一整轮往返。我这份样本上能拿掉的比想象中多。按性质分只有最后一类真的需要模型判断的性质要模型吗为什么数值比较、阈值判断不要一次整数比较的事状态查重、时间窗口不要查一下、算一下的事格式硬校验不要拦截点应该在执行前不是在模型脑子里需要理解语义的判断要这才是模型的活需要生成自然语言的要同上五类判断三类是规则。拿掉之后 prompt 短一半而且结果更稳定——同一条输入今天判 A 明天判 B调用方会疯。判据一句话把模型拔掉这条链还能不能跑能跑就说明它压根不需要模型。七、什么该进 skill什么该进代码上面那条推到底会撞上一个真实的矛盾流程放进代码 改流程要发版而外置 skill 的初衷恰恰是改一句话术不用发版。这两条是打架的。所以分界线必须写出来不能靠感觉什么放哪为什么话术 · 口径 · 语气skill改得频繁改错了是效果问题不是事故流程顺序 · 能不能进下一步 · 什么时候允许执行代码改得少走错一步是不可撤回的事故判据一句话改错了会不会造成不可撤回的后果会 → 进代码不会 → 进 skill。顺带一个反直觉的观察我量的这份 skill 用的是prose 状态机——那 8,890 token 的 Step 0–6 全靠模型读散文自律代码一步都不拦。而它没做错。因为在人在环、逐轮推进的链路里四条前提都成立每一步都有外部输入当天然分界模型从历史里一眼能看出走到哪了走错了会被当场纠正真正不可撤回的点只有一个。但换成无人值守、批量并发的链路——同一批任务并行跑、没有外部输入当分界、历史里分不清哪条是哪条、每一条的输出都不可撤回——上面四条全反。prose 状态机在那边一条都不成立。同一个做法一边对一边错。判据不是做法本身是那四条前提。八、三条可以直接抄走的闸如果这篇你只带走一样东西带这三条。它们全是脚本判的不靠人自觉任何单个SKILL.md≤ 3,000 tokentiktoken 实测写明口径。超了必须拆进steps/。skill 目录里每一个引用文件都必须真的被引用过。写了没接线判红——防的就是那 2,870 token 的死内容。压缩发生之后当前 step 的口径原文仍逐字节在上下文里。不是还在是是原文。第 3 条最容易被跳过因为没有它系统照常跑——它只会在某一天让模型做出一件你明确禁止过的事。最后这篇里没有一个数字是估的全是拿一份真在线上跑的 skill 量出来的。你可以拿自己的 skill 复现——我猜大部分人量完的表情会跟我一样。我最大的收获不是那些数字是量完之后意识到的这件事skill 不是给模型的说明书它是一份要付每轮成本的常驻资产。按说明书写你会写出一份完整、自洽、24,624 字符的文档。按资产写你只会问一个问题这一刻模型手上必须有哪一段那份 14k 的文件是照第一种写法写出来的。它写得很好——问题在于它是一份好说明书。