上下文验尸 11111353535/dsh-context-autopsy

dsh-context-autopsy · 上下文验尸

跑完的 agent 会话不是黑箱。 DSH 把每一次请求、每一条工具结果、每一次压缩尝试都写到磁盘上，连 provider 自己数的 token 一起写。这个 skill 读那份日志，只回答一个问题，且只用数字回答：

上下文窗口到底花到哪去了，把它一路搬着走花了多少钱？

dsh-context-autopsy · session-7f3a91c2 79 steps · 78 requests · peak context ~65,500 tokens · carried 66× C:\work\shop · 1 MB · 412 zstd frame(s) · 285 record(s) · 33m48s · deepseek/deepseek-v4.1-flash

Biggest lever: compaction was refused on all 6 attempt(s).

findings
[high] compaction was refused on all 6 attempt(s)
6 failure(s), yet 1 prune record(s) still landed (~18,400 tokens). Refusal: refused: another
layer owns compression on this lane
→ Two layers are claiming ownership of the history. Decide which one compacts, and turn the
other off — otherwise the pruning that does happen is not the pruning you configured. [high] read produced 94% of all tool output read returned 19 result(s) totalling ~62,000 tokens, against ~66,084 tokens of tool output overall. → Every read call is paid for again on every later step. Narrow it — a range, a limit, a narrower query — or re-read the same result instead of fetching it twice. [medium] context was carried 66× over ~3,577,800 tokens were sent in total while the window only ever peaked at ~65,500 (turn 1). 97% of that was cache re-read. → A long session at a low peak is a loop, not a big task. Split it: a fresh session per subtask starts near zero and carries nothing forward. [medium] edit failed 4 times First message: Error: old_string was not found in "src/invoice.ts" → A tool failing repeatedly with the same argument class is a wrong assumption about the environment, not bad luck. Read the first error before the second attempt.

where the context came from
tool output ~66K tokens over 55 result(s)
read 62K 94% 19 call(s) avg 3K 1 repeat(s)
grep 4K 6% 32 call(s) avg 126
edit 52 0% 4 call(s) avg 13 4 error(s), 3 repeat(s)
assistant ~156 tokens of visible text
reasoning ~9K tokens of thinking
largest 16K tokens from read at turn 2/step 20
provider 103K new input + 3.5M cache read = 3.6M sent

这一段是 node test/samples.mjs 生成的，不会与代码脱节。

这份 README 就写自那次会话——一个跑了 48 小时、被当事人当成「任务本来就这么长」的运行。报告说的是（中途快照，会话还在继续长）：

1093 steps · 1092 requests · peak context ~153,316 tokens · carried 1173× Biggest lever: context was carried 1173× over. [high] compaction was refused on all 426 attempt(s) — 426 failure(s), yet 74 prune
record(s) still landed (~322,468 tokens).
[medium] read produced 51% of all tool output — 508K tokens over 291 calls. provider 2.2M new input + 94M cache read = 97M sent

两层病理叠在一起——426 次压缩全被另一个声称拥有压缩权的层拒绝，同时一个工具悄悄占了一半窗口。
两个问题在会话内部都看不见，在日志里各是一个数字。

安装

作为 DSH skill，克隆进任意 skill 根目录：

git clone https://github.com/11111353535/dsh-context-autopsy "$DSH_HOME/skills/dsh-context-autopsy"
或按项目放：
git clone https://github.com/11111353535/dsh-context-autopsy .dsh/skills/dsh-context-autopsy

agent 会在 <available_skills> 里看到它，并在「这次会话为什么这么贵」时加载。也可以自己跑：

node scripts/autopsy.mjs # 本机最新会话
node scripts/autopsy.mjs --list # 有哪些会话
node scripts/autopsy.mjs latest --full
node scripts/autopsy.mjs <session-id>
node scripts/autopsy.mjs /path/to/session.v4.jsonl.zstd
node scripts/autopsy.mjs latest --json

Node 22+。零依赖、没有安装步骤、不联网、不写盘。路径取 $DSH_HOME，没有就 ~/.dsh。

这个 skill 存在的理由：一个会静默出错的坑

session.v4.jsonl.zstd 不是一个 zstd 流。DSH 每 flush 一次追加一帧，所以这个文件是几千个独立帧的拼接。在一份真实的 8.2 MB 日志上实测：

$ node -e "console.log(require('zlib').zstdDecompressSync(require('fs').readFileSync(process.argv[1])).length)" session.v4.jsonl.zstd
192

$ node scripts/autopsy.mjs session.v4.jsonl.zstd --json | head -20
改成走帧边界：4,064 帧 → 30,505,563 字节

zstdDecompressSync 解完第一帧就停了。192 字节只是那份日志的 0.001%——7206 行里的 2 行——而且它是合法 JSON，能正常 parse，描述出一个只有三条记录的会话。什么都不报错。 你拿到一个自信、极小、错的答案，每一个照着这个文件写的朴素读取器都拿到这个答案。

scripts/lib/zstd-frames.mjs 按 zstd 格式（RFC 8878 §3）自己走帧边界，所以报告覆盖整个文件。如果你自己写读取器，请先断言 解出字节数 > 文件字节数，再信任它下游的任何东西。

数的是什么，每个数从哪来

| 数字 | 来源 | 性质 |
| 请求数、峰值上下文、缓存读、输出、推理 | assistant/message → data.usage | 实测——provider 自己数的 |
| 搬运 N×、缓存重读占比 | 上面这些的算术 | 实测 |
| 压缩尝试、被拒次数、被裁 token | compaction/start、compaction/end、compaction/prune | 实测 |
| provider 重试与错误码 | request/retry 记录 | 实测 |
| 每个工具的 token 归因 | 结果文本长度 | 估算 ±15%（latin chars/3.8，中文一字一 token） |
| 重复调用 | 工具名与参数完全相同 | 实测（匹配是，代价不是） |

报告每次都说明哪个是哪个。估算从不承担本该由实测承担的决定。

会报出来的发现

每一条都给数字、给产生它的证据、给一个「当时换个做法就会不一样」的动作。阈值是 scripts/lib/findings.mjs 里的常量，不做成配置——能被调参的发现，没人信。

| 发现 | 含义 | 该改什么 |
| context was carried N× over | 会话把自己的历史重发了 N 次。有缓存时高是正常的；峰值不高却几百倍是循环，不是大任务 | 一个子任务一个会话 |
| compaction was refused on all N attempts | 两层都声称拥有历史。裁剪却仍落地，所以数字看着健康，机制在自己打自己 | 定一个压缩归属方 |
| X produced N% of all tool output | 一个工具占了窗口 | 收窄调用：范围、上限、用 grep 代替 read |
| one X result was ~N tokens | 一条结果被后续每个请求搬着走 | 在源头截断输出 |
| N tool calls repeated with identical arguments | 同一个答案买了两次 | 读前面那条结果 |
| X failed N times | 同一类参数反复失败 = 对环境有错假设 | 读第一个错误 |
| turn N took M steps, P% of the session | 那一轮本来是 subagent 形状 | 派出去 |

健康的会话会直接报 No context pathology found.——这是个有用的答案，这个 skill 是照着「宁可说没问题，也不编一个问题」写的。

它不做什么

- 不写。 从不修改、删除、重试、修复日志。读一个正在写的会话会得到截断的最后一帧，报告里标为 truncated，不算错误。
- 不猜。 没有模型调用、没有启发式打分、没有「上下文健康分」。数字是 provider 的，唯一的估算已经标注。
- 不跨轮平均。 「一轮占了大部分工作」恰恰是平均值会抹掉的那个发现。

目录

SKILL.md agent 加载的正文 scripts/autopsy.mjs CLI scripts/lib/discover.mjs 找会话、解析会话 scripts/lib/zstd-frames.mjs 多帧解码（上面那个坑） scripts/lib/parse.mjs 记录、token 估算 scripts/lib/analyze.mjs 预算、构成、轮次、压缩、重试、失败 scripts/lib/findings.mjs 数字 → 命名发现，阈值即常量 scripts/lib/render.mjs 纯文本报告、JSON 形状 references/ 会话格式、以及怎么把报告变成建议 test/ node --test，只用夹具

开发

node --test "test/*/.test.mjs" # 53 个单测
node test/live.mjs # 19 项，对着本机真实会话跑
node test/samples.mjs # 打印样例
node test/inject-sample.mjs # 把样例写回两份 README
node test/check-samples.mjs # 样例与代码不一致就失败

README 里的样例由 CLI 自己调用的渲染函数生成：inject-sample.mjs 整块替换而不是让人手改换行， check-samples.mjs 再比回来。test/live.mjs 只读，机器上没有 $DSH_HOME/sessions 时会干净跳过。

MIT。