token 消耗过大的根因分析及改进建议

[kongyuna]

token 消耗过大的根因分析及改进建议

关联：#1052「上下文太大，token消耗增多」

背景

收到两类反馈：

1. 实际会话中处理约 1MB 的 HTML 文件（含大量 base64 图片），任务经历了约 9 轮"构建—验证—修复—重验"的调试循环，token 消耗和时间明显偏高。
2. 上下文太大，token消耗增多 #1052 中用户反馈 PTC 模式下，小任务也导致 token 用量从 70M 增长到 100M。

以下分析基于对当前版本预设配置和源码的核查。

根因

1. 自动压缩只在压力超阈值时触发，属于事后处理

dsh-compaction-basic 已装配在 standard/code/cordis 预设中（minimal 除外），通过 compactIfNeeded 在 ctx.tokenMeter 压力超阈值时触发。但会话增长的多数成本发生在阈值以下：

• 每轮携带全量历史，随轮数线性增长；
• 超大工具输出（Playwright DOM/快照、大文件内容）单轮即可消耗大量 token；
• 调试失败导致的轮次放大。

Claude Code 在接近上下文预算前预留缓冲自动压缩；Codex 提供可配置的 context_compaction_threshold 并建议在里程碑手动 /compact。当前版本两者均未提供。

2. spill 机制未装配，超大工具输出无保护

dsh-spill-policy 的实现是完整的（maxInlineBytes 超限后全文存盘、返回有界首尾预览和取回指引），但 maxInlineBytes 省略时策略完全禁用，且 standard/code/cordis 预设均未装配该插件。即开箱状态下，超大工具输出会直接进入上下文。

3. 压缩依赖 LLM 摘要，自身有成本

每次压缩调用 llm/stream 生成摘要，消耗 token 和时间。社区已有无模型压缩实现（dsh-compaction-instant，基于 VCC，毫秒级完成且不调用模型），说明该成本可以消除，但需要第三方替换。

4. 连续重复工具调用只有提醒，没有限制

dsh-repeat-tool-reminder 在连续重复调用达到阈值时注入提醒，但不阻止。失败轮次的调用放大（业界实测约 4 倍）没有硬性上限。

5. 模型侧没有上下文压力可见性

dsh-token-meter 提供 contextPressure 投影（pressureTokens / projectedTokens / contextWindow），但仅浏览器读取，模型看不到。社区插件 dsh-session-handoff 需要自行添加 60%/70% 软硬压力横幅，说明内置缺失。

改进建议

1. 在预设中装配 dsh-spill-policy 并设置默认 maxInlineBytes（如 64KB）。
2. 将 contextPressure 注入模型可见的提示词横幅（软/硬两级阈值），接近阈值时提示手动压缩。
3. 暴露压缩阈值配置（参照 Codex context_compaction_threshold），并按模型容量设定默认值。
4. 增加无模型压缩选项（仅结构化裁剪，不调用 LLM 摘要），降低压缩自身的成本后下调触发线。
5. 为连续重复工具调用提供可配置的硬性上限。
6. 统计压缩调用自身的 token 消耗并展示在会话投影中。

总结

当前上下文管理的问题在于：spill 默认关闭，压缩仅在压力超阈值后触发且自身消耗模型调用，模型侧无压力可见性。三项主要成本（历史累积、超大工具输出、调试轮次放大）均发生在任何机制介入之前。建议优先处理默认配置（开启 spill）和可见性（压力感知），再考虑压缩实现本身的优化。

[denial123789]

这个分析把“历史累积、超大工具输出、调试轮次放大”分开是对的；不过按当前仓库 rc.2 commit b150a55 的发布组合，有两处事实需要先校正，否则容易把 package default 当成 shipped runtime：

1. packages/bundle/base/cordis.patch.yml 已装配 dsh-spill-local，并给 dsh-spill-policy 显式设置 maxInlineBytes: 50000。所以“省略配置时禁用”是包级默认，不是这个 pinned base 的实际配置。
2. 同一个 base 也已装配 dsh-compaction-tool-result-pruner（8192/4096/1024）和 dsh-repeat-tool-reminder（3/5/8）。但 pruner 确实不是主动的低压过滤器：compaction-basic 先测量，低于阈值直接返回；达到压力或 provider 确认 overflow 后才 prune、重新测量、必要时再做 LLM summary。repeat reminder 也只是 advisory，不会阻止调用。

因此建议先把 70M→100M 拆成逐 call 序列，至少记录 turn/step、provider/model、uncached/cache-read/cache-write/output、pressure/projected/contextWindow、工具结果的 UTF-8 bytes 与 text/mixed 类型、是否出现 (Omitted N bytes...)、compaction trigger/threshold/prune/summary/retry。

需要特别注意：累计 usage 在 compaction 后不会下降；compaction 只降低后续请求的 occupancy。若 post-compaction 单次 input 明显下降但累计仍增长，这是正常现象，不足以证明压缩失败。

对于 1 MB 含 base64 的 HTML，也要确认 1 MB 是否真的进入 model-visible history：用户消息/附件、read、普通纯文本工具结果、mixed-content 结果、DOM snapshot 的路径完全不同。generic spill 明确跳过 read，mixed-content 也不处理。文件大小本身不能替代模型实际收到的 payload 证据。

我把逐调用取证表、两层保护的触发时机/绕过项和安全降本路径整理成了可复用 runbook：
https://sandbaseai.github.io/deepseek-harness-handbook/token-meter-accounting.html

[kongyuna]

感谢指正，两点校正都成立。我在本机 rc.2 安装的 @deepseek-ai/dsh-base/cordis.patch.yml 里逐一核验过：

1. spill-local 已装配，spill-policy 显式配置 maxInlineBytes: 50000。"省略配置即禁用"是包级 README 的默认，不是该 pinned base 的实际配置。原帖根因第 2 条（"未装配、开箱无保护"）撤回。
2. 同一 base 也装配了 compaction-tool-result-pruner（8192/4096/1024）和 repeat-tool-reminder（[3,5,8]，仅提醒）。pruner 是压力达标后的第一动作（prune→重新计量→必要时才摘要），不是低压过滤器；这一点与我的理解一致，帖子里相应表述一并修正。

按你给的 runbook 把引发此帖的那个会话做了逐调用取证（单 turn、51 步、52 次调用），主要数据：

• 真实账单：uncached input 189,182 / cache read 4,497,536（95.9%）/ output 37,353，提示侧合计 4,686,718。
• 占用阶梯 12,360 → 158,472（窗口 262,144 的 60.5%），单调增长；compaction 触发 0 次，pruner 0 次。
• spill 实际命中 1 次：step29 一个 49,998B 的 bash 结果被截到预算内，正文带 (Omitted 983 bytes…) 和 spill 文件路径——50KB 上限确实在工作。
• 源文件 994,949B 从未整体进入历史：工具结果累计进表面的字节只有 183,324B，最大单次 read 为 42,571B。佐证了"文件大小不能替代模型实际收到的负载证据"。
• Top5 大结果被后续请求以 cache-read 重带的估算合计 ≈120 万 tokens，占总 cache_read 的 27%；其中单个 step5 的 42KB read 贡献 ≈50 万。
• 缓存断裂：7 个步的命中率跌破 90%（最低 0%），按 95% 基线估算的超支 ≈12.3 万 tokens，占全部 uncached input 的 65%。日志中没有请求 envelope 变化的记录，具体成因不明，只报告现象。
• 反事实：若在 step30/35 手动压缩到 50%/30%，提示侧总计费分别降 17%/26%/36%。

据此修订建议清单：

1. 默认开启 spill —— 撤回，已在且有效。
2. 保留并提前：模型侧上下文压力可见性。峰值占用了窗口的 60.5%，模型和用户都没有看到任何提示；在 step30 之后这直接决定了后续每次请求的价格。
3. 保留：里程碑压缩引导。上面的反事实数字是它的量化依据——压缩机制存在但没人被提示去用。
4. 保留：连续重复调用的硬性可配置上限（现为 advisory，与你描述一致）。
5. 保留：压缩自身成本的统计展示（billing 与 occupancy 已用本次数据验证分离）。
6. 新增观察项：无 envelope 变化时的前缀缓存命中率跌落（本例 7 步、占 uncached 65%），是否与 pi-ai 路由的前缀稳定性有关，值得单独排查。

第 2、3 条是这次复盘里性价比最高的两个方向：同样的内核配置，只补上"看得见"和"该压就压"，这笔账单可以少掉三成左右。

[Jona-lee]

吐槽下，同样的调研任务，交给deepseek耗了我¥50，codex只花了¥4

[VillagerUncle02]

补一组工具表/固定开销的字节级拆分，可能对"能裁多少"那部分有用。

环境：dsh 0.1.5-rc.1，web profile，本机 bundle 列表：dsh-base, dsh-web-app, archify-dsh, dsh-web-search-anysearch, dsh-super-injector, linxin/first-web-all, hindsight-coding-agents, experimental-agent-team-profile。抓包方式：把 DEEPSEEK_BASE_URL 指到本地代理（隔离 DSH_HOME，
没动生产配置）。

每轮固定开销 63,527 B，其中工具表 46,424 B（占 73%）。工具表按来源拆：

来源	工具数	字节
standard preset	24	25,728
dev_*（super-injector）	19	8,325（17.9%）
hindsight_*	8	6,172（13.3%）
agent-team	9	4,520（9.7%）
mcp__ssh__*	4	1,614（3.5%）
插件类合计	40	20,631（44.5%）

另外每轮还带一份 dsh_plugin_packages：80 个包名 / 5,337 B，是部署元数据，跟任务无关，
而且 dsh-plugin-package-inventory-deepseek 默认开启。

从未被调用过的 48 个工具占 31,715 B = 68.3%；全裁可省 23,440 B（固定开销的 36.9%），
但会砍掉 agent-team 这类核心能力。更划算的是描述瘦身：desc 合计 22,964 B，
16 个 >400 B 的工具超出部分共 8,236 B（13.0%）可省且不丢任何工具。

一个需要一起说明的对照：Codex 只有 15 个工具，但工具表 47,050 B，比 dsh 还大
（含 mcp__blender 23,440 B）。所以"工具多"不是 dsh 独有的问题；差异在于 dsh 这 46KB 里
44.5% 来自用户自己装的插件，是可裁的。

（这部分属于用户装配，我已归到附录，不作为 dsh 缺陷；但如果要改"默认带什么"，上面这张拆分表
可能有用。）

影响的能力

• 每轮固定成本 / 上下文有效容量：固定开销乘以轮数是复利损耗，同时它挤占的是
  每次压缩可用的预算——工具表越胖，压缩后能留下的历史越少。
• 长任务相关：是（纯复利效应）。