每一轮都在送出的固定前缀

上下文注入的成本，通常按「注入了多少条记忆」来估。这个口径在这套系统上不成立。

原因是结构性的：注入内容里有一半以上与「这一轮有没有值得记起的事」无关。它们是框架头、规则、索引——不管这一轮多安静，它们都会到齐。

一　账不是这么算的

要算清这件事，得先解决数据源问题。估算不可靠，因为它无法反映「预算被逐个分项切走」的真实过程。

可用的最强证据藏在会话记录里：session.v3.jsonl.zstd 保存的就是真实发给模型的 messages。把其中的记忆块取出、按段落标题行切开，量出的就是实际成本。

这份记录有一个技术细节需要先解决：它是多帧 zstd 追加流（一个 5.5 MB 文件含 1,049 帧）。用常规方式解压整个文件，只能得到第一帧——274 字节的会话头。必须逐帧解压。

token 口径采用仓内唯一的估算器：保守口径取「字符数除以二」与「字符数除以四加四」的较大者。比例分母为配置项 injectBudgetChars，本机为 8,000。

二　把每一段切开

三　四点一七成

规则段一段就是 7,634 字符，占完整版的 41.7%。它在精简版里是 7,414 字符，占精简版的 75.0%。

这一段有一个刻意的设计：它不参与裁剪。代码里的桶级豁免是显式的——limitOf('rules') 返回空，即使调用方显式传了上限也会被忽略并留痕。rules-section 的入队优先级是「普通」，但因为桶级豁免，优先级在此不生效。

把规则段与 Tier-0 索引相加——这两段是「每轮必须在场」的部分——合计 8,663 字符，正好是精简版的 87.6%。

换句话说：精简版里有近九成的内容，与「这一轮发生了什么」无关。无论这一轮是深夜的无人值守，还是刚刚打开的一段闲聊，这两段都会如数到场。

四　精简版省下了什么

两档之间的差额是 8,405 字符（约 4,203 token，保守口径）。

即便按最省的节奏跑，每轮均值仍超出预算 43.5%。

这里需要对「预算」一词作一处澄清：injectBudgetChars 并不是硬性闸门。它只用于两件事——推导出分项上限，以及写入投递元数据作为「合计是否超预算」的可观测量。超预算不阻止投递。

五　不该动的四件事

既然规则段占去四成，最直觉的动作是「让整块稀疏一些」。这条路走不通，因为它会同时破掉四条已确立的纪律。

收益也支撑不起这个代价：整块跳轮省下的不到一成。真正的成本大头是那两段必须在场的部分——它们不是可以优化的对象，而是这套系统的运行前提。