CodeGraph 残存上下文占用：用多轮 A/B 度量 Agent 检索响应在上下文窗口中的残留成本

2026-09-04 17:06:36作者：范垣楠Rhoda

Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local

项目地址：https://gitcode.com/GitHub_Trending/co0degr/codegraph

本篇介绍 CodeGraph 的 agent-eval 评测框架中一个关键反馈指标——残存上下文占用（residual context occupancy，编号 CG-7）：它回答的问题是「当问题已经答完时，工具响应仍在上下文窗口中占据多少 token」，也就是后续每一轮对话真正可用的余量有多少。读完本文，你会理解吞吐（throughput）与存量（stock）两类度量为何方向相反、token 如何做到「实测而非估算」、A/B 实验中 without-arm 的 CLI 污染是如何被发现并封堵的，以及 2026-08-05 针对 7 个 README 基准仓库跑出的完整基线数据。

该指标是 agent-eval 三反馈指标之一，入口文档说明了三个指标各自回答的问题（占用 CG-7、充分性 CG-8、分配效率 CG-9）与应选用的 harness；本文聚焦占用指标本身的度量方法、实验事故与基线结果。

一、为什么需要「占用」这个指标

它度量的对象：当问题已经被回答后，某工具（工具族）的响应仍然占据上下文窗口多少 token——由此决定此后每一轮还有多少工作空间。

这正是 issue #1500 真正在抱怨的事。报告者当时盯着一个 Cursor 的实时会话：explore 的输出在答案给出之后仍然驻留在窗口里，于是它对之后发生的一切计费。而当时仓库里的 A/B harness 只跑单题到底，报告成本、token、耗时和工具调用次数——这些指标全都看不见那个现象。单题运行报告的是吞吐（每次请求把整个前缀重新计一遍），而占用是存量：它只从后续轮次开始真正产生成本。

harness 现在已经能测量它了——通过多轮会话。

二、如何运行测量

单仓库、三eturn会话、双臂对比

# 一个仓库、一个三轮会话、两个 arm：
scripts/agent-eval/run-all.sh /tmp/codegraph-corpus/gin \
  "How does gin route requests through its middleware chain?||\
Where is the 404 / no-route case handled in that same chain?||\
What would I change to add a per-route middleware that runs before the global ones?"

# 7 个 README 仓库（默认每会话 3 轮、每 arm RUNS=4 次）：
CORPUS=/tmp/codegraph-corpus RUNS=2 scripts/agent-eval/bench-readme.sh
node scripts/agent-eval/parse-bench-readme.mjs /tmp/ab-readme

关键机制：|| 分隔轮次。第 1 轮正常运行；此后每一轮都对同一会话执行 --resume，因此前几轮的工具输出仍留在窗口中——这正是该指标的全部意义所在。各轮日志分段落盘为 run-<label>.jsonl、run-<label>.t2.jsonl……，parse-run.mjs 把它们拼回一个完整会话（--resume 不会重放历史消息，所以分段拼接后 token 记账可以跨边界延续）。

开关	作用
`CG_TURNS=1`	退回原始的单题 A/B（不测占用）
`CG_WINDOW_TOKENS`	覆盖 200k 名义窗口，用于 share-of-window 列的计算
`CG_ARMS=with\|without`	只重跑其中一个 arm，不重做另一个

每次运行打印的占用块

每个 arm 都会打印如下格式的报告：

Residual context occupancy at end of run:
  final context       54,950 tok   27.5% of 200k window
  codegraph           13,941 tok   25.4% of ctx    7.0% of 200k win   (31,312 chars, 2 results)
  Read                     0 tok    0.0% of ctx    0.0% of 200k win   (0 chars, 0 results)
  Grep/Glob                0 tok    0.0% of ctx    0.0% of 200k win   (0 chars, 0 results)
  Bash                     0 tok    0.0% of ctx    0.0% of 200k win   (0 chars, 0 results)
  → file-access            0 tok    0.0% of ctx    0.0% of 200k win   (0 chars, 0 results)
  other tools             33 tok    0.1% of ctx    0.0% of 200k win   (73 chars, 1 result)
  base (prompt+prose)  40,976 tok   74.6% of ctx   20.5% of 200k win
    of which fixed    37,726 tok  system + tool schemas + question, before any tool answered
  measure: 2.25 chars/tok measured ±0.9% · turns 6 · compactions 0

正确的比较对象是 with 臂中 codegraph 的残留，对 without 臂中 file-access（Read + Grep/Glob + Bash）的残留——这是 agent 把同一批字节送进自己脑子里的两种方式。Bash 不可省略：在小仓库上，without 臂经常通过 Bash 用 cat/grep 而不是 Read 工具去取文件，如果只计 Read，这些运行会被记成「什么都没读」。从源码看，parse-run.mjs 中工具族划分就是 codegraph / read / search / bash / other，并显式定义了 FILE_ACCESS = ['read', 'search', 'bash'] 作为 without 臂的对照组合。

三、token 是如何实测的

实测，不是估算

对每个 assistant 请求：

ctx_k = usage.input_tokens + cache_read_input_tokens + cache_creation_input_tokens

这是该请求整个 prompt 的精确 token 数。因此 ctx_k − ctx_{k−1} 恰好是上一个请求之后新追加的内容：上一条 assistant 输出，加上其后跟来的工具结果与用户文本。每个间隙（gap）的实测 delta 按其中的字符数计价。

在 parse-run.mjs 中可以确认：ctx 正是三项相加，timeline 里每个 req 条目携带该请求的 ctx，相邻两 req 之间的 add 条目构成 gap。

校准有一个关键陷阱：chars/token 比值只能在按字符 ≥80% 为工具结果的 gap 上校准，然后所有结果都用该比值计价。如果拿所有 gap 校准是错的——当 assistant 自身输出在 transcript 中欠表征时（被 redact 或为空的 thinking block 是最常见情形），按比例切分会把整个 delta 全记给工具结果。实例：一个 73 字符的 ToolSearch 结果被记了整整 830 token 的 gap，即 5.5 token/字符。源码中对应过滤条件在 parse-run.mjs：g.toolChars / g.chars >= 0.8，并辅以「丢弃远高于下中位数的 gap」防止窗口收缩（shedding）伪装成异常致密的文本。

做对这件事比看上去更重要。explore 输出的实测密度约为 2.2–2.3 字符/token——它是带行号的密集源码。惯用的 bytes/4 经验法则会低估它约 40%。

误差棒

在某个 ≥95% 为单一工具结果的 gap 上，实测 delta 就是该结果的 token 数，因此与运行级比值的偏离量就是该结果的归因误差。对所有这类 gap 取中位数，打印在比值之后：真实运行上为 ±1–2%。源码里对应 parse-run.mjs 的 dispersion 计算（errs 取中位数）。

残存（residual）≠ 贡献（contributed）

内容离开窗口有两条路径，两者都被追踪：

compact_boundary 系统事件——它之前的所有内容被摘要替换，驻留集清零；
微压缩（micro-compaction）——窗口在运行中途下降但没有 boundary 事件。Claude Code 先丢弃最旧的工具结果，因此逐出按 FIFO 应用。

缺口只有在超过容差（200 token 与 5% 的较大者）时才算逐出；低于该容差的是归因噪声，真实丢弃动辄数千 token。源码中这一逻辑集中在 parse-run.mjs：compact gap 时 queue = [] 并累计 evicted，其余 gap 计算 shortfall = toolTokens − delta，超过 Math.max(200, toolTokens * 0.05) 才调用 FIFO 的 evict()。

两个 transcript 陷阱

两者都对着真实日志验证过，写任何读取这些文件的工具之前都值得知道：

Claude Code 对每个 content block 发一个 assistant 事件，且都携带同一个 message.id 和同一个 usage。按事件累加 usage 会把同时发出 thinking block 和 tool_use 的每一轮都重复计一遍。parseSession() 按 message.id 去重（parse-run.mjs 的 seenMsgIds）。
流式的 output_tokens 是部分快照——观察到某轮实际生成约 1,100 token 却报 out=2。它不可用；字符比例法刻意不依赖它。

补充记录：在 Claude Code 2.1.198 中，result.usage 是段内累计（其 in+cache+out 等于该段所有请求 prompt 之和），并非 CLAUDE.md 写作时的「仅最后一轮」。parseSession() 无论如何都是逐段求和。该数字是「已处理 token 数」——每个请求都重计整个前缀——这正解释了它为什么答不了占用问题。但要注意：当前版本 Claude Code 的 result.usage 已变为仅报最后一轮，这一点直接导致了下文吞吐表的 2026-08-05 修正。

四、without-arm 从来不是真的「没有 codegraph」

确立基线时发现了一条一直在敞开的污染通道，它使 harness 此前为「带 Bash 的 arm」产出的所有数字作废。

without 臂拿到的是空 MCP 配置，因此没有 codegraph 工具。但它仍有 Bash——而目标仓库仍带着 with 臂需要的 .codegraph/ 索引，且 codegraph 二进制在 PATH 上。Agent 会找到它。在第一次「看起来干净」的 7 仓库通过中，15 次 without 运行里有 14 次通过 Bash 跑了 codegraph explore，其中一次是 ls .codegraph && codegraph explore …。那个 arm 实际度量的是 codegraph-over-CLI 对 codegraph-over-MCP，而不是 codegraph 对「无 codegraph」。

反向也会失真。当 with 臂通过 shell 调用时，输出以 Bash 结果形式到达，被记在 Bash 名下——低估了 codegraph 自身占用。15 次 with 运行中有 1 次如此。

修复在 run-all.sh 中：两臂都运行在一个把 CLI 藏起来的 PATH 上，于是 MCP server 是到达 codegraph 的唯一通道，保持 A/B 的单变量。具体实现在 no-cli-shim.sh，它是两层的：

PATH 替换：二进制通常与运行所需的工具（这里 claude 就紧挨着它）同目录，所以不能整目录删掉；做法是原位替换为一个符号链接目录——链接该目录里除 codegraph 外的每一个条目，保持 PATH 顺序与优先级不变。
PreToolUse hook：只藏 PATH 不够——被拒过一次后，agent 跑过 find / -maxdepth 4 -iname "*codegraph*" 找到二进制并用绝对路径调用。hook 拦截「调用本身」：用 CG_CMD_RE 正则（no-cli-shim.sh）只匹配命令位置上的 codegraph（grep codegraph src/、ls .codegraph、which codegraph 这类「提及」放行），命中则以 permissionDecision: deny 拒绝。

脚本还内置自检探针：hook 必须能拦截绝对路径调用、且放行普通提及；若净化后的 PATH 丢了 claude 或 node 则拒绝运行（no-cli-shim.sh 的存活检查与 cg_no_cli_probe）。

仅靠预防会在二进制下次落到新位置时静默失效，因此还有检测：parse-run.mjs 用同一套 CG_CLI_RE 标记任何点名 codegraph 的 Bash 命令，并区分「被拦截的尝试」（无输出入窗，无害）与「实际返回了输出」的调用（真正的污染）；parse-bench-readme.mjs 则把受污染的 without 运行从聚合中剔除（CG_INCLUDE_CONTAMINATED=1 可保留）。

任何重读此 harness 旧 A/B 结果的人都应假定 without 臂可能用过 codegraph。

五、基线：7 个 README 仓库

先读 regime，再读任何数字

	本次战役	README 已发表表格
模型	`claude-sonnet-5`	Claude Opus 4.8
会话形态	3 轮（README 问题 + 2 个顺流追问）	1 个问题
运行数	每 arm 4 次 × 7 仓库 = 56 个会话	每 arm 4 次，取中位
运行时间	2026-08-05，137 分钟（`bgjob-6d357cd2`），原始日志在 `/tmp/ab-readme`	2026-07-21

这两者不可比，且差异来自模型 + 轮数——不是污染。 Sonnet 是该 harness 刻意选择的地板模型（CLAUDE.md 的既定策略：能在 Sonnet 上落地的能力可向上泛化；只在 Opus 上有效的能力不向下泛化）。三轮是让占用「可计费」的最小形态。两个选择都会移动效率数字，因此下文吞吐行会读得比 README 低，且没有任何一方使另一方失效。要确认已发表的 Opus 数字是否仍然成立，需要一次匹配的 Opus 4.8、单题重跑；那被刻意排除在本次范围之外。

复现命令：

CORPUS=/tmp/codegraph-corpus scripts/agent-eval/bench-readme.sh   # RUNS=4 CG_TURNS=3
node scripts/agent-eval/parse-bench-readme.mjs /tmp/ab-readme

bench-readme.sh 中硬编码了 7 个仓库各 3 轮的原题（vscode 扩展宿主通信、excalidraw 画布渲染、django ORM 查询、tokio 任务调度、okhttp 拦截器链、gin 中间件链、alamofire 请求校验），前两轮保持 README 原问题、后两轮是同一流程内的追问；CG_TURNS=1 可以只跑 README 单题。

核心发现：codegraph 的残留高 82%，7 个仓库无一例外

repo        turns W→WO   final ctx W→WO   residual W→WO       % of ctx W→WO   % of window W→WO
vscode      12.5/44      113k→53k         67k→18k  (+276%)    59.7%→36.0%     33.7%→9.0%
excalidraw  9/32         87k→57k          43k→25k   (+71%)    49.5%→47.6%     21.5%→12.5%
django      7.5/16.5     60k→51k          18k→10k   (+71%)    29.3%→19.9%      8.8%→5.1%
tokio       9/33.5       87k→64k          45k→31k   (+45%)    52.1%→50.5%     22.7%→15.7%
okhttp      6/14         61k→59k          20k→16k   (+27%)    33.2%→27.6%     10.1%→8.0%
gin         6/15.5       56k→49k          15k→8k    (+79%)    26.3%→16.7%      7.3%→4.1%
alamofire   10/31        76k→65k          34k→32k    (+7%)    44.7%→50.6%     16.9%→15.8%

AVERAGE: retrieval residual 82% HIGHER with codegraph · share-of-context 27% HIGHER

W = codegraph 响应在运行结束时仍驻留的量；WO = Read + Grep/Glob + Bash 结果仍驻留的量。turns 为每会话的 assistant 轮数中位数。

7 比 7。 没有任何一个仓库是 codegraph 留得更少。在 vscode 上，它对 without 臂的 18k 留下了 67k token 的驻留——200k 窗口的三分之一，在第 4 轮开始前就没了。唯一接近打平的是 Alamofire（+7%），而它打平的原因是其 share-of-context 实际更低（44.7% 对 50.6%），不是因为残留量小。

两件事同时为真。 7 个仓库中 6 个上，without 臂处理的总 token 远多于 with 臂——gin 660k 对 290k，okhttp 704k 对 302k——却留下得更少。吞吐和存量是两个不同的量，在此指向相反的方向：

codegraph 前置一个大而逐字（verbatim）的载荷（gin 上 2 次 explore 调用，每次是数万个密集源码字符），该载荷对其后每一轮保持驻留；
Read/Grep/Bash 则磨碎许多小结果（gin：每运行约 6 次 read + 约 5 次 bash），其中大多是 agent 随后丢弃的重新推导，它们会被逐出。

这在我们自己的 harness 上证实了 issue #1500。 报告者的抱怨正是这个轴，而在此战役之前我们没有任何能看见它的测量。给读 git 历史的人留一句注：聚合器最初把它打印成「-82% lower with codegraph」——一个符号错误，已在提交 520ed9d 修复。诚实的数字才是这个指标的全部意义；不要柔化它。

固定开销。 codegraph 的工具 schema + MCP instructions 在任何工具被调用之前消耗 +546 tok 上下文（with 臂 ctxBase 中位数减 without 臂 ctxBase 中位数，跨仓库平均）。无论 agent 是否调用 codegraph 都要付。它很小——上下文真正去处的大头是残留，不是 schema。

同战役的吞吐（sonnet · 3 轮）

以下数据为保证完整性而报告，也因为占用发现只有对照它才有意义。这些不是 README 的数字，不得作为 README 数字引用。

2026-08-05 修正。 本文 token 列最初发布时是错的，且错在一个方向上。它取自 result.usage，而该字段在当前 Claude Code 中只报最后一轮，因此系统性少计了轮数更多的那个 arm——永远是 without 臂。它把真实数字 56% 的 token 节省报成了 23%，并显示 vscode 用 codegraph 后处理 token 多 98%，实际是少 41%。下文已从同一批原始日志（/tmp/ab-readme-sonnet3turn）按每 assistant 轮求和重新推导。成本、耗时与工具调用从未受影响——它们未变。占用取自时间线而非该字段，因此上文表中每个数字仍然成立。

repo        time W→WO        tools W→WO   tokens W→WO (saved)   cost W→WO (saved)
vscode      2m 59s→1m 59s    8→60         940k→1.6M   (41%)     $1.21→$1.62  (25%)
excalidraw  1m 45s→2m 1s     5→44         549k→1.3M   (57%)     $0.78→$1.03  (24%)
django      1m 4s→1m 30s     3→13         362k→715k   (49%)     $0.52→$0.45 (-17%)
tokio       1m 47s→4m 35s    5→43         568k→1.6M   (65%)     $0.67→$1.25  (47%)
okhttp      49s→1m 25s       2→11         299k→698k   (57%)     $0.35→$0.48  (27%)
gin         1m 6s→1m 43s     2→12         285k→652k   (56%)     $0.38→$0.43  (12%)
alamofire   1m 35s→1m 47s    6→29         539k→1.5M   (64%)     $0.67→$1.30  (49%)

AVERAGE saved: cost 24% · tokens 56% · time 20% · tool calls 84%

	本战役（sonnet，3 轮）	README（Opus 4.8，1 题）
成本节省	24%	44%
token 节省	56%	62%
耗时节省	20%	53%
工具调用节省	84%	88%

Token 与工具调用削减在 regime 切换下几乎原样保留。更难打的 regime 付出的是成本与墙钟时间：在更弱的模型上跑三轮追问，with 臂赢得余量更少，且 django 成本反而高 17%——这一点不在此处遮掩。with 臂在此 regime 下也并非零文件读取：28 个 with 会话中有 4 个仍触发了 Read（vscode run4 rd5 bs7、tokio run2 rd3 bs2、django run4 rd1、alamofire run2 rd1），对照 README 在 Opus 单题下「七个仓库全部零文件读取」的记录。

污染门：干净，且通道是真实的

56 个会话中，没有任何一次 CLI 调用返回过输出。 聚合值未受污染，没有任何运行被剔除。

但有 29 次尝试被拦截——26 次在 without 臂（覆盖其 28 个会话中的 26 个），3 次在 with 臂。93% 的 without 会话试图通过 Bash 触达 codegraph，被净化 PATH + PreToolUse hook（no-cli-shim.sh）拦下。这不是 harness 出于谨慎防的假想通道；它是 agent 一旦注意到树里存在 .codegraph/ 时的默认动作。no-cli-shim.sh 是承重墙——没有它，本次战役就会退化成 codegraph-over-CLI 对 codegraph-over-MCP，正如更早那次 14/15 的通过（见上文第四节）。在相信这个 harness 的任何数字之前，先检查污染行。

次级读数——是绝对值，不是前后对比

本战役没有 baseline-build 臂——下文的数字全部是当前构建在这些问题上的一次绝对读数。分配效率尤其如此，它是相对的（按引用归因）：它比较的是同一问题上的不同构建，单独看说明不了浪费。前后对比式分配 A/B 见 explore-allocation-ab-1500.md。

repo        calls  again    read-ret  read-miss  grep    MOVED ON   alloc eff  envelope
vscode      26     21 81%   0  0%     1  4%      1  4%   3 12%      63.2%      442k
excalidraw  18     14 78%   0  0%     0  0%      0  0%   4 22%      94.7%      338k
django      11      6 55%   1  9%     0  0%      0  0%   4 36%      96.2%      186k
tokio       16     12 75%   0  0%     0  0%      1  6%   3 19%      92.9%      343k
okhttp       8      4 50%   0  0%     0  0%      0  0%   4 50%      97.9%      151k
gin          8      4 50%   0  0%     0  0%      0  0%   4 50%      99.0%      116k
alamofire   23     19 83%   1  4%     0  0%      0  0%   3 13%      89.0%      306k

POOLED (110 answered explore calls):
  explore again 73% · Read a file we returned 2% · Read a file we did NOT return 1%
  · Grep/Glob 2% · moved on / answered 23%
POOLED allocation efficiency: 86.7% over 110 calls / 1.9M chars

分配效率 pooling 86.7%。vscode 以 63.2% 是离群点——最大信封（442k 字符）配最低的引用份额，任何分配变更都会最先在这里显现。
Read a file we returned = 2%（110 次中 2 次）。「文件对了、字节不对」几乎不存在；该指标旨在捕捉的分配缺失并不是 vscode 数字的驱动因素。
召回缺失共 3%（1 次 read-miss、2 次 grep）。
explore again = 73%，且按构造就是含糊的——它无法区分「第一次调用不够」与「agent 正在走三轮会话，这是第 2 轮的第一次调用」。在三轮 regime 下该歧义比单轮时代大得多；应把高 again 仓库（alamofire 83%、vscode 81%）视为未决，而非失败。

六、本指标确立了什么，又没确立什么

已确立。 指标存在、是实测而非估算、跑在多轮会话上——占用真正被计费的 regime。截至 2026-08-05，7 个 README 仓库的基线（见上）已可用于对比后续变更，且它说的是 codegraph 的残留在每一个仓库上更高。（在那次战役之前，本文档曾声称基线存在而实际上并不存在；现在它存在了，且只对应一个 regime——claude-sonnet-5、3 轮——不是一般性结论。）

未确立，且刻意不主张：

README 的效率数字。 上述基线跑的是 sonnet / 3 轮；README 发表的是 Opus 4.8 / 单题。24/23/20/84 与 60/69/20/89 之间的差距是 regime 差异，不是回归，本战役无法判断已发表数字往哪个方向移动。那需要一次匹配的 Opus 4.8 单题重跑。此处超出范围，且 README.md 被刻意未动。
不同的宿主。 报告者在 Cursor 上。我们度量的是 Claude Code。窗口大小、系统提示与压缩策略都不同，因此 share 数字不能跨宿主搬运；能搬运的是两臂之间的比值。
三轮太短。 它长到足以让残留被计入某个东西——单轮运行根本做不到——但短到在 200k 窗口上够不到压缩，因此压缩与微压缩路径虽已实现并埋点，实际上未被本基线测试到：没有任何一次运行触发过两者。
延迟加载的工具 schema 落在 base 里。 codegraph_explore 是延迟工具：初始清单只带名字，ToolSearch 稍后拉取完整 schema。该注入不是工具结果，其 token 被计入 base 而非归因给 codegraph。固定开销行（with 臂 ctxBase 减 without 臂 ctxBase）计价的是从一开始就存在的那部分。
子代理上下文不计入。 Task 子代理有自己的窗口，只有其摘要返回父窗口。委托型运行只按父窗口度量。
占用不等于充分。 残留小只有在答案仍然正确时才是好事。本指标对响应是否够用不作任何断言——那是 explore sufficiency 的事，现在每次运行都会与本占用块并排打印——也不断言返回字节中答案实际用掉了多少（CG-9）。

七、README 措辞提案（未应用，供维护者参考）

README.md 是本工作刻意不触碰的对象。它的基准表是 Opus 4.8 / 单题 regime，本文测到的任何东西都无法复述它。以下是一份提案：把占用发现写成效率表的诚实制衡，措辞上不依赖 sonnet 对 Opus 的 regime 差异即可成立。可采纳、否决或重写——这不是待执行的编辑。

建议位置：紧跟「A note on cost」段（README 约 195 行），作为同一表格下的第二条 > 注。

A note on context. 上文效率表度量的是吞吐——到达一个答案所处理的 token、调用的工具、花费的美元。它没有度量答案之后仍留在窗口里的东西，而在那条轴上 CodeGraph 花得更多，而不是更少。在同样七个仓库的多轮会话中，CodeGraph 的响应在会话结束时留下的检索上下文比文件读取型 agent 多约 80%——在 VS Code 上是 67k token 对 18k。机制与它快的原因是同一件事：CodeGraph 返回一个密集、逐字的载荷，回答了问题，然后留在窗口里；而 grep-and-read 型 agent 磨碎许多小结果，它们会被逐出。更少的 已处理 token 与更大的持久足迹都是真的。如果你在小窗口里跑长会话，请为此做预算。逐仓库实测见：docs/benchmarks/residual-context-occupancy.md。

三句起草说明（如果被编辑）：

提案中不出现本战役效率表的任何百分比。「多约 80% 驻留」是两臂间的占用比值，是能跨模型与宿主搬运的那部分；24/23/20/84 吞吐数字是 sonnet-3 轮专属，绝不应靠近 README。
它承认这个缺点，而不是把它包装成功能。 这是刻意的——CLAUDE.md 的「产品中的诚实是承重墙」在 README 上的效力优先于产品界面；一个在自己的会话里撞上 #1500 却发现 README 对此沉默的读者，会不相信表里的其他任何数字。
share 数字（200k 窗口的 33.7%）是 Claude Code 的，不能搬到别的宿主，因此草案只引用绝对 token 数与两臂比值。

参考路径

类别	路径
指标入口（三指标总览）	docs/benchmarks/agent-eval-feedback-metrics.md
本文原始文档	docs/benchmarks/residual-context-occupancy.md
双 arm A/B 驱动	scripts/agent-eval/run-all.sh
7 仓库战役脚本	scripts/agent-eval/bench-readme.sh
日志解析 + 占用计算	scripts/agent-eval/parse-run.mjs
战役聚合 + 污染剔除	scripts/agent-eval/parse-bench-readme.mjs
CLI 隔离两层防护	scripts/agent-eval/no-cli-shim.sh
相关指标：分配效率 A/B	docs/benchmarks/explore-allocation-ab-1500.md
相关指标：充分性	docs/benchmarks/explore-sufficiency.md