按加载时机分别计算上下文开销

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

Skill 包把入口从 20 KiB 缩到 2 KiB，却要求每次调用额外读取 18 KiB 参考。教学宿主始终加载的 name/description 为 0.4 KiB；完整 front matter 另作清单，调用正文已包含它。你要比较实际加载负担，不把文件变短等同于 token 节省。

具体做法

按加载时机建立独立清单：发现元信息、完整 front matter、单次调用的正文和必读参考。说明宿主实际怎样加载、哪些内容重复进入输入。对同一包改动前后用相同 tokenizer 测量，或把字节统计明确标为估算；有条件分支的资料按触发情况单列，不把总包大小当每次都付的成本。

反例

入口从 20 KiB 到 2 KiB，所以直接宣布调用上下文减少 90%，忽略强制读取的 18 KiB 和始终加载元信息。

改进写法

核对同一教学包前后加载记录。发现 name/description 都是 0.4 KiB，完整 front matter 另记但已包含在正文账目。原调用读取 20 KiB 入口；新调用读取 2 KiB 入口加 18 KiB 必读参考。分别报告这些账目与实测方式，不重复相加同一输入。入口字节缩短不支持调用上下文减少 90%；token 数据未知时保持估算标签。

为什么这样改

把内容移到每次必读的文件只改变存放位置。按加载时机比较完整消费内容，能看到发现层与调用层分别承担什么，也能避免把一份参考忘记或计算两次。

如何验证

教学的调用内容总量前后均为 20 KiB，始终加载清单保持 0.4 KiB；token 数没有 tokenizer 记录时不输出确定值。

检查必读与条件读取区别、front matter 是否重复计数、改动前后方法一致。仅引用入口缩小比例，不足以声称成本下降。

适用边界

字节、token、缓存计费与上下文占用是不同指标，依宿主和实际载荷而变。来源的预算上限和估算比率不是通用容量或价格承诺；更少上下文也不证明任务质量不变。本篇不调用 tokenizer API。