CodeGraph Agent 评测三反馈指标实战Residual Occupancy、Explore Sufficiency 与 Allocation Efficiency【免费下载链接】codegraphPre-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/codegraphCodeGraph 的 agent-eval 评测框架在每次运行时固定输出三个反馈指标残差上下文占用Residual Context OccupancyCG-7、探索充分性Explore SufficiencyCG-8与分配效率Allocation EfficiencyCG-9。它们不是同一个数字的三种视图而是分别回答这次检索为后续回合留下了多少上下文负担检索结果是否足以让 Agent 停止翻查返回的字节有多少真正被答案引用三个独立问题一次检索改动可能只移动其中一个而不动其他两个。本文围绕 入口文档 讲解如何为不同评测目的选择 harness、如何读输出表、三个指标各自的坑并结合 scripts/agent-eval/parse-run.mjs 的源码说明每个指标是如何从既有 stream-json 转录日志中解析出来的。读完你可以独立运行这三套评测、解读 ARM COMPARISON 表并在数字异动时定位到具体该修哪一段检索逻辑。三个指标各答一个问题互不替代入口文档给出的核心分工如下表。三者都是harness-only指标全部从评测框架自己写出的转录日志中解析而来产品侧不输出任何遥测数据数据也不离开本机。指标回答的问题深入文档Residual context occupancyCG-7运行结束时该臂的检索结果还占着窗口里的多少 token——即后续每一轮都要在多大的剩余空间里工作residual-context-occupancy.mdExplore sufficiencyCG-8响应够不够读 Agent 紧接着做了什么再 explore、Read 文件还是直接作答explore-sufficiency.mdAllocation efficiencyCG-9响应花掉的字节里有多大比例给了答案真正引用的文件explore-allocation-efficiency.md入口文档还强调了一个阅读纪律Efficiency is not value, and occupancy is not sufficiency.一个响应可以 100% 高效却毫无用处比如只有一个被顺带提到的小文件残差小也只是在答案仍然正确的前提下才有意义。把三个指标接在同一次运行里输出正是为了强制三者一起读。选择 harness按你要问的问题挑三个指标在两套 A/B harness 中都会打印按问题类型选择1. 隔离一次检索改动ab-new-vs-baseline.sh新构建HEAD对比基线构建任意 git ref两臂都挂载 codegraph跑同一个实现任务。这是这三个指标的设计目标场景——两臂 codegraph 都在所有数字度量的都是改动本身而不是有没有用 codegraph。RUNS3 scripts/agent-eval/ab-new-vs-baseline.sh /tmp/codegraph-corpus/express \ Add a charset option to res.send and wire it through main从 ab-new-vs-baseline.sh 的脚本实现看它的运行机制有几个关键点脚本先把目标仓库rsync出两份干净副本t-new/t-base排除 node_modules/.git/dist/.codegraph分别用 HEAD 构建和基线 ref 构建各自索引并运行基线臂通过逐文件git checkout ref -- file还原旧构建src/无差异时会直接拒绝运行nothing to A/B每次运行前对目标副本预温热一个常驻 codegraph daemon并等待daemon.sock出现同时用CODEGRAPH_WASM_RELAUNCHED1跳过启动再执行。这一步load-bearing不可删除没有它Agent 会在 codegraph 完成约 2–3 秒启动前就扑向 Read/grep整次运行测的是 attach 延迟而不是检索质量两臂都设置CODEGRAPH_NO_PROMPT_HOOK1禁用环境里 ambient 的 UserPromptSubmit 前置钩子——否则会经第二条不受控通道注入上下文污染工具调用计数RUNS环境变量控制每臂运行次数默认 1。由于两臂各自只构建/索引一次提高RUNS远比重新调用脚本便宜而运行间方差很大文档明确要求RUNS2并报告区间。2. 有无 codegraph 对比run-all.shCodegraph-on 臂仅 codegraph MCP对比空 MCP 配置臂。它回答的是另一个问题位移displacement与采用adoption而非改动效果。内置 Read/Grep/Bash 在两臂中均可用所以without臂获取同样字节的方式是读文件和搜索。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?多回合语法是||分隔第一回合正常运行后续每个回合用--resume续接同一 session前一回合的工具输出仍在窗口里——这正是残差占用真正被记账的地方单问题运行结构性地看不到这个成本。从 run-all.sh 源码看每段落在run-label.jsonl、run-label.t2.jsonl… 中parse-run.mjs会把它们拼回一个 session--resume不重放历史消息所以各段可干净拼接。CG_ARMSwith|without可只重跑一臂而不重做另一臂对比表仍会对着$AGENT_EVAL_OUT默认/tmp/agent-eval中已有的日志渲染。3. 完整战役bench-readme.sh7 个 README 仓库vscode、excalidraw、django、tokio、okhttp、gin、alamofire每个 3 回合每臂RUNS次全部经由run-all.sh驱动——因此战役中每次运行都携带三个指标。从 bench-readme.sh 看仓库需预先克隆并索引到$CORPUS默认/tmp/codegraph-corpus每行固定为主问题 两个不离开同一流程的追问CG_TURNS1可退回原始单问题 A/B。聚合用parse-bench-readme.mjsCORPUS/tmp/codegraph-corpus RUNS2 scripts/agent-eval/bench-readme.sh node scripts/agent-eval/parse-bench-readme.mjs /tmp/ab-readme已运行过一次战役2026-08-05 基线sonnet3 回合每臂 4 次。文档提醒比较任何东西之前先读它上面的 regime box且注意它不是 README 表格发布时所用的 regime。4. 已有日志随时可解析parse-run.mjs run.jsonl [run.tN.jsonl …]对任意 stream-json 日志打印三个指标块--brief去掉带编号的调用转录保留其余--envelope额外报告 explore 响应在文件间的字节分配--answer glob可重复标记真正答题的文件parse-session.mjs project-dir对交互式session 做 sufficiency 和 allocationcompare-arms.mjs out-dir label…随时从磁盘日志构建对比表任意标签。模型策略两套 harness 通用不可协商每臂都用--model sonnet --effort high两臂同模型。Sonnet 是有意的下限——能在它上面落地的 affordance 可以上泛到任何宿主模型只在更强模型上有效的改动无法下泛到多数用户实际拥有的 Agent。读懂输出对比表回答动没动逐运行块回答为什么每次运行先打印自己的三个指标块块形状见各指标文档然后一张表把两臂并排。这是真实的 CG-22 express 运行输出也是三个指标一起读的完整示例 ARM COMPARISON — /private/tmp/cg22/ab-express new baseline runs 3 3 behavior duration (s) 24 [18–35] 26 [24–30] Read 0 1 codegraph calls 2 [1–2] 2 residual context occupancy (CG-7) — tokens still resident at end of run codegraph residual (tok) 11,549 [7,193–12,591] 10,388 [10,373–10,447] file-access residual (tok) 231 [0–242] 1,661 [1,306–1,663] → retrieval residual (tok) 11,780 [7,193–12,833] 12,034 [11,753–12,051] → share of final context 23.3% [15.8%–24.9%] 23.8% [23.4%–23.9%] explore sufficiency (CG-8) — pooled over every answered explore call answered explore calls 5 6 explore again 2 40% 3 50% Read a file we returned 0 0% 3 50% Read a file we did not return 0 0% 0 0% Grep/Glob 0 0% 0 0% moved on / answered 3 60% 0 0% explore allocation efficiency (CG-9) — share of returned bytes the answer cited pooled efficiency 96.9% 82.0% per-run efficiency 100.0% [92.5%–100.0%] 81.9% [81.9%–82.0%] contamination — the CLI must never be how codegraph is reached CLI calls that RETURNED output 0 0 CLI attempts blocked 0 0这个例子的读法基线臂把 18% 的 envelope 花在了一个答案从未引用的文件上因此 Agent 在6 次调用中的 3 次里 Read 了我们已经返回过的文件整次运行以82%效率收场新构建送出了正确的字节——该桶 5 次中 0 次、96.9%——而残差大体相当。只看 occupancy 会判定两臂等价这正是三指标并排的价值。对比表是did it move?逐运行块才是why?。只有逐运行块会指出哪个 query 落了空、Agent 转而去读了哪个文件通常足以用 scripts/agent-eval/probe-explore.mjs 复现一次 miss。compare-arms.mjs 的表格统一按median [min–max]渲染原因见下文小样本一节。哪个桶指向哪个修复Sufficiency 的桶被刻意设计成每个桶对应一个不同的修复方向其中两个直接挂钩其他指标Read a file we returned→ allocation分配问题文件对了字节错了被裁掉了。同一批运行上预期 allocation efficiency 也偏低。注意不对称性——效率指标会给一个被引用但裁剪掉了部分内容、Agent 不得不去读的文件其 section 记 100% 分这个桶就是为此而设的捕获器。Read a file we did not return/Grep/Glob→ recall召回问题文件根本没浮出来。Allocation efficiency 对此完全失明——envelope 只是缺了一块。explore again→ 构造上就是模糊的。它说明响应没有回答但不说明是分配还是召回问题后续 query 通常能分辨。moved on / answered→ sufficient充分但充分不等于正确。指标实现原理源码级补充以下三点是读懂指标块里那些数字的前提均在 parse-run.mjs 中实现。Occupancy测的是真 token不是估算。对每个 assistant 请求ctx_k input_tokens cache_read_input_tokens cache_creation_input_tokens是该请求完整 prompt 的精确 token 数相邻请求之差gap_k就是新追加内容的量按字符比例把 gap 拆给其中的各 tool_result。chars/token 比值只在字符 ≥80% 为工具结果的 gap 上校准避免 assistant 输出在转录中欠代表时把整个 delta 记到某个小结果上实测 explore 输出约 2.2–2.3 chars/tokenbytes/4 的经验值会低估约 40%。内容离开窗口有两条路都被跟踪compact_boundary事件清空此前的驻留集micro-compaction 下按 FIFO 逐出最老的 tool result短缺超过 max(200 tok, 5%) 容差才算逐出真实 shed 是数千 token 量级。SufficiencyAgent 的下一步动作是免费的地面真值。分类器把每次已应答的codegraph_explore按其后的第一个实质动作分桶并有三条保真规则同一条 assistant 消息里与 explore 并发发出的 Read 不构成裁决响应还不存在单独计为concurrentToolSearch/TodoWrite这类无信号工具被跳过subagent 的调用是独立线程转录里以parent_tool_use_id交错标记父线程的裁决是对委派本身的判断——按子 Agent 第一个实质动作来评否则会把子 Agent 的 grep 误记成父线程对某次 explore 的裁决。Bash 命令还会被意图解析sed -n 100,200p file读作 Readgrep/rg/find读作搜索带重定向/here-doc 的写文件命令不算读。Allocation按引用归因两个通道。computeAllocation从渲染后的 markdown而非诊断 sidecar——sidecar 只存在于较新构建无法测基线臂解析出 explore 的 per-file section然后从 Agent 的最终答案中提取引用PATH 通道答案点出文件含lib/response.js:126-220与裸 basename——裸名只在扩展名确实出现在 envelope 中时放行避免res.send被误认作文件和 SYMBOL 通道代码 span 中的符号且该符号只由目标文件的 section 头列为定义才计分出现在 ≥3 个返回文件中的名字过于通用弃用——否则send/get会把半个 envelope 标成已用而乐观偏差是这个指标唯一不能倾斜的方向。被返回两次的文件计两次——因为它占用了窗口两次。汇总视图下仍然成立的注意事项各指标文档有完整清单以下是会改变你对表格本身的读法的那几条Allocation efficiency 是相对量不是绝对量。归因靠引用而 Agent 可以用了但从未点名一个文件用它来排除或据此建立模型。误差单向只能在同一问题上比较构建绝不能把数字引用为codegraph 浪费了 N% 的返回内容。语料中位数落在 80% 区间是因为这些 flow 类问题的答案要遍历整条链区分度在 p25 及以下。Occupancy 的占比不跨宿主迁移。基准是 Claude Code、名义 200k 窗口CG_WINDOW_TOKENS可覆盖。窗口大小、系统提示、压缩策略在别处都不同能迁移的是两臂之间的比值百分比不是对 Cursor 的主张。比对的必须是正确的一对。在 with/without A/B 中是 codegraph 残差对 without 臂的file-access残差Read Grep/Glob Bash——Agent 把同样字节读进脑子的两种方式。只数 Read 工具会把经 Bashcat取文件的运行记成没读任何东西。充分不等于正确一次 Read 是票不是证明。桶仍是对的信号——Agent 去读说明有东西缺失——但单次调用有噪声。小样本永远。一次运行只有 1–5 次 explore 调用单运行的百分比很粗。表格打印median [min–max]正是为此报告区间。RUNS2下结论用战役。Subagent 上下文不计入 occupancy——Task子 Agent 有自己的窗口只有摘要回流。而 sufficiency会跟随子 Agent 线程委派按子 Agent 的第一个动作评判。两个指标对委派的差异化处理是刻意的。延迟工具 schema 计入 occupancy 的basecodegraph_explore是延迟加载的ToolSearch稍后拉取 schema那次注入不是工具结果fixed-overhead 行只计价一开始就存在的部分。Contamination先看这一行两套 harness 都让每个臂运行在一个屏蔽 codegraph CLI的环境里PATH 中把二进制符号链接摘除的净化目录外加一个PreToolUse钩子拦截绝对路径调用no-cli-shim.sh两套 harness 共用。两层都必要——曾有 Agent 在 PATH 上拿不到codegraph后执行find / -iname *codegraph*找到二进制并用绝对路径调起。Contamination 行是检测的一半与预防的一半不冗余预防在下一次二进制落到新位置时会静默失效计数器不会。在with/withoutA/B 中一次 CLI 调用意味着 without 臂并非without。某次 7 仓库遍历中 15 次 without 臂运行有 14 次通过 Bash 跑了codegraph explore——shim 之前的所有旧结果都应假定已被污染。在new/baselineA/B 中两臂都是 codegraph-onCLI 调用不是泄漏而是归因失败会同时破坏三个指标经 Bash 到达的输出在 occupancy 表里被记到 Bash 头上经 CLI 发出的 explore 根本不是工具调用永远到不了 sufficiency 分类器和 allocation 解析。运行会静默地把调用从上方每个数字里丢掉。CLI attempts blocked是良性的——Agent 试了但没有任何内容进入窗口。CLI calls that RETURNED output不是。parse-run.mjs 用只匹配命令位置而非任意提及的正则识别 CLI 调用grep codegraph x、ls .codegraph、which codegraph都是看而不是用放行。测试指标数学本身的回归用内建 selftest 覆盖node scripts/agent-eval/parse-run.mjs --selftest # 68/68它对带已知答案的合成转录做断言occupancy 的完整算术校准、FIFO 逐出、compaction 清空、sufficiency 的每个桶以及 same-message/thread/delegation 三条规则、allocation 的引用通道及其守卫歧义上限、prose 不计引用、per-call 与 pooled 的口径。selftest 特意放在 parse-run.mjs 内部而不是独立测试文件——新写的scripts/agent-eval/*.mjs会进入 self-query eval fixture 自己的语料污染被评测对象。各指标的用例清单见对应指标文档。小结这套三指标体系的设计逻辑一句话概括occupancy 管留了多少sufficiency 管够不够allocation 管送得准不准三者接在同一次运行上互相制衡——任一指标单独向好都可能被另外两个证伪。运行侧记住三件事即可按问题选 harness隔离改动用ab-new-vs-baseline.sh采用/位移用run-all.sh战役用bench-readme.shRUNS2并报区间输出表先看 contamination 行再看其余数字。【免费下载链接】codegraphPre-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodeGraph Agent 评测三反馈指标实战：Residual Occupancy、Explore Sufficiency 与 Allocation Efficiency
CodeGraph Agent 评测三反馈指标实战Residual Occupancy、Explore Sufficiency 与 Allocation Efficiency【免费下载链接】codegraphPre-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/codegraphCodeGraph 的 agent-eval 评测框架在每次运行时固定输出三个反馈指标残差上下文占用Residual Context OccupancyCG-7、探索充分性Explore SufficiencyCG-8与分配效率Allocation EfficiencyCG-9。它们不是同一个数字的三种视图而是分别回答这次检索为后续回合留下了多少上下文负担检索结果是否足以让 Agent 停止翻查返回的字节有多少真正被答案引用三个独立问题一次检索改动可能只移动其中一个而不动其他两个。本文围绕 入口文档 讲解如何为不同评测目的选择 harness、如何读输出表、三个指标各自的坑并结合 scripts/agent-eval/parse-run.mjs 的源码说明每个指标是如何从既有 stream-json 转录日志中解析出来的。读完你可以独立运行这三套评测、解读 ARM COMPARISON 表并在数字异动时定位到具体该修哪一段检索逻辑。三个指标各答一个问题互不替代入口文档给出的核心分工如下表。三者都是harness-only指标全部从评测框架自己写出的转录日志中解析而来产品侧不输出任何遥测数据数据也不离开本机。指标回答的问题深入文档Residual context occupancyCG-7运行结束时该臂的检索结果还占着窗口里的多少 token——即后续每一轮都要在多大的剩余空间里工作residual-context-occupancy.mdExplore sufficiencyCG-8响应够不够读 Agent 紧接着做了什么再 explore、Read 文件还是直接作答explore-sufficiency.mdAllocation efficiencyCG-9响应花掉的字节里有多大比例给了答案真正引用的文件explore-allocation-efficiency.md入口文档还强调了一个阅读纪律Efficiency is not value, and occupancy is not sufficiency.一个响应可以 100% 高效却毫无用处比如只有一个被顺带提到的小文件残差小也只是在答案仍然正确的前提下才有意义。把三个指标接在同一次运行里输出正是为了强制三者一起读。选择 harness按你要问的问题挑三个指标在两套 A/B harness 中都会打印按问题类型选择1. 隔离一次检索改动ab-new-vs-baseline.sh新构建HEAD对比基线构建任意 git ref两臂都挂载 codegraph跑同一个实现任务。这是这三个指标的设计目标场景——两臂 codegraph 都在所有数字度量的都是改动本身而不是有没有用 codegraph。RUNS3 scripts/agent-eval/ab-new-vs-baseline.sh /tmp/codegraph-corpus/express \ Add a charset option to res.send and wire it through main从 ab-new-vs-baseline.sh 的脚本实现看它的运行机制有几个关键点脚本先把目标仓库rsync出两份干净副本t-new/t-base排除 node_modules/.git/dist/.codegraph分别用 HEAD 构建和基线 ref 构建各自索引并运行基线臂通过逐文件git checkout ref -- file还原旧构建src/无差异时会直接拒绝运行nothing to A/B每次运行前对目标副本预温热一个常驻 codegraph daemon并等待daemon.sock出现同时用CODEGRAPH_WASM_RELAUNCHED1跳过启动再执行。这一步load-bearing不可删除没有它Agent 会在 codegraph 完成约 2–3 秒启动前就扑向 Read/grep整次运行测的是 attach 延迟而不是检索质量两臂都设置CODEGRAPH_NO_PROMPT_HOOK1禁用环境里 ambient 的 UserPromptSubmit 前置钩子——否则会经第二条不受控通道注入上下文污染工具调用计数RUNS环境变量控制每臂运行次数默认 1。由于两臂各自只构建/索引一次提高RUNS远比重新调用脚本便宜而运行间方差很大文档明确要求RUNS2并报告区间。2. 有无 codegraph 对比run-all.shCodegraph-on 臂仅 codegraph MCP对比空 MCP 配置臂。它回答的是另一个问题位移displacement与采用adoption而非改动效果。内置 Read/Grep/Bash 在两臂中均可用所以without臂获取同样字节的方式是读文件和搜索。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?多回合语法是||分隔第一回合正常运行后续每个回合用--resume续接同一 session前一回合的工具输出仍在窗口里——这正是残差占用真正被记账的地方单问题运行结构性地看不到这个成本。从 run-all.sh 源码看每段落在run-label.jsonl、run-label.t2.jsonl… 中parse-run.mjs会把它们拼回一个 session--resume不重放历史消息所以各段可干净拼接。CG_ARMSwith|without可只重跑一臂而不重做另一臂对比表仍会对着$AGENT_EVAL_OUT默认/tmp/agent-eval中已有的日志渲染。3. 完整战役bench-readme.sh7 个 README 仓库vscode、excalidraw、django、tokio、okhttp、gin、alamofire每个 3 回合每臂RUNS次全部经由run-all.sh驱动——因此战役中每次运行都携带三个指标。从 bench-readme.sh 看仓库需预先克隆并索引到$CORPUS默认/tmp/codegraph-corpus每行固定为主问题 两个不离开同一流程的追问CG_TURNS1可退回原始单问题 A/B。聚合用parse-bench-readme.mjsCORPUS/tmp/codegraph-corpus RUNS2 scripts/agent-eval/bench-readme.sh node scripts/agent-eval/parse-bench-readme.mjs /tmp/ab-readme已运行过一次战役2026-08-05 基线sonnet3 回合每臂 4 次。文档提醒比较任何东西之前先读它上面的 regime box且注意它不是 README 表格发布时所用的 regime。4. 已有日志随时可解析parse-run.mjs run.jsonl [run.tN.jsonl …]对任意 stream-json 日志打印三个指标块--brief去掉带编号的调用转录保留其余--envelope额外报告 explore 响应在文件间的字节分配--answer glob可重复标记真正答题的文件parse-session.mjs project-dir对交互式session 做 sufficiency 和 allocationcompare-arms.mjs out-dir label…随时从磁盘日志构建对比表任意标签。模型策略两套 harness 通用不可协商每臂都用--model sonnet --effort high两臂同模型。Sonnet 是有意的下限——能在它上面落地的 affordance 可以上泛到任何宿主模型只在更强模型上有效的改动无法下泛到多数用户实际拥有的 Agent。读懂输出对比表回答动没动逐运行块回答为什么每次运行先打印自己的三个指标块块形状见各指标文档然后一张表把两臂并排。这是真实的 CG-22 express 运行输出也是三个指标一起读的完整示例 ARM COMPARISON — /private/tmp/cg22/ab-express new baseline runs 3 3 behavior duration (s) 24 [18–35] 26 [24–30] Read 0 1 codegraph calls 2 [1–2] 2 residual context occupancy (CG-7) — tokens still resident at end of run codegraph residual (tok) 11,549 [7,193–12,591] 10,388 [10,373–10,447] file-access residual (tok) 231 [0–242] 1,661 [1,306–1,663] → retrieval residual (tok) 11,780 [7,193–12,833] 12,034 [11,753–12,051] → share of final context 23.3% [15.8%–24.9%] 23.8% [23.4%–23.9%] explore sufficiency (CG-8) — pooled over every answered explore call answered explore calls 5 6 explore again 2 40% 3 50% Read a file we returned 0 0% 3 50% Read a file we did not return 0 0% 0 0% Grep/Glob 0 0% 0 0% moved on / answered 3 60% 0 0% explore allocation efficiency (CG-9) — share of returned bytes the answer cited pooled efficiency 96.9% 82.0% per-run efficiency 100.0% [92.5%–100.0%] 81.9% [81.9%–82.0%] contamination — the CLI must never be how codegraph is reached CLI calls that RETURNED output 0 0 CLI attempts blocked 0 0这个例子的读法基线臂把 18% 的 envelope 花在了一个答案从未引用的文件上因此 Agent 在6 次调用中的 3 次里 Read 了我们已经返回过的文件整次运行以82%效率收场新构建送出了正确的字节——该桶 5 次中 0 次、96.9%——而残差大体相当。只看 occupancy 会判定两臂等价这正是三指标并排的价值。对比表是did it move?逐运行块才是why?。只有逐运行块会指出哪个 query 落了空、Agent 转而去读了哪个文件通常足以用 scripts/agent-eval/probe-explore.mjs 复现一次 miss。compare-arms.mjs 的表格统一按median [min–max]渲染原因见下文小样本一节。哪个桶指向哪个修复Sufficiency 的桶被刻意设计成每个桶对应一个不同的修复方向其中两个直接挂钩其他指标Read a file we returned→ allocation分配问题文件对了字节错了被裁掉了。同一批运行上预期 allocation efficiency 也偏低。注意不对称性——效率指标会给一个被引用但裁剪掉了部分内容、Agent 不得不去读的文件其 section 记 100% 分这个桶就是为此而设的捕获器。Read a file we did not return/Grep/Glob→ recall召回问题文件根本没浮出来。Allocation efficiency 对此完全失明——envelope 只是缺了一块。explore again→ 构造上就是模糊的。它说明响应没有回答但不说明是分配还是召回问题后续 query 通常能分辨。moved on / answered→ sufficient充分但充分不等于正确。指标实现原理源码级补充以下三点是读懂指标块里那些数字的前提均在 parse-run.mjs 中实现。Occupancy测的是真 token不是估算。对每个 assistant 请求ctx_k input_tokens cache_read_input_tokens cache_creation_input_tokens是该请求完整 prompt 的精确 token 数相邻请求之差gap_k就是新追加内容的量按字符比例把 gap 拆给其中的各 tool_result。chars/token 比值只在字符 ≥80% 为工具结果的 gap 上校准避免 assistant 输出在转录中欠代表时把整个 delta 记到某个小结果上实测 explore 输出约 2.2–2.3 chars/tokenbytes/4 的经验值会低估约 40%。内容离开窗口有两条路都被跟踪compact_boundary事件清空此前的驻留集micro-compaction 下按 FIFO 逐出最老的 tool result短缺超过 max(200 tok, 5%) 容差才算逐出真实 shed 是数千 token 量级。SufficiencyAgent 的下一步动作是免费的地面真值。分类器把每次已应答的codegraph_explore按其后的第一个实质动作分桶并有三条保真规则同一条 assistant 消息里与 explore 并发发出的 Read 不构成裁决响应还不存在单独计为concurrentToolSearch/TodoWrite这类无信号工具被跳过subagent 的调用是独立线程转录里以parent_tool_use_id交错标记父线程的裁决是对委派本身的判断——按子 Agent 第一个实质动作来评否则会把子 Agent 的 grep 误记成父线程对某次 explore 的裁决。Bash 命令还会被意图解析sed -n 100,200p file读作 Readgrep/rg/find读作搜索带重定向/here-doc 的写文件命令不算读。Allocation按引用归因两个通道。computeAllocation从渲染后的 markdown而非诊断 sidecar——sidecar 只存在于较新构建无法测基线臂解析出 explore 的 per-file section然后从 Agent 的最终答案中提取引用PATH 通道答案点出文件含lib/response.js:126-220与裸 basename——裸名只在扩展名确实出现在 envelope 中时放行避免res.send被误认作文件和 SYMBOL 通道代码 span 中的符号且该符号只由目标文件的 section 头列为定义才计分出现在 ≥3 个返回文件中的名字过于通用弃用——否则send/get会把半个 envelope 标成已用而乐观偏差是这个指标唯一不能倾斜的方向。被返回两次的文件计两次——因为它占用了窗口两次。汇总视图下仍然成立的注意事项各指标文档有完整清单以下是会改变你对表格本身的读法的那几条Allocation efficiency 是相对量不是绝对量。归因靠引用而 Agent 可以用了但从未点名一个文件用它来排除或据此建立模型。误差单向只能在同一问题上比较构建绝不能把数字引用为codegraph 浪费了 N% 的返回内容。语料中位数落在 80% 区间是因为这些 flow 类问题的答案要遍历整条链区分度在 p25 及以下。Occupancy 的占比不跨宿主迁移。基准是 Claude Code、名义 200k 窗口CG_WINDOW_TOKENS可覆盖。窗口大小、系统提示、压缩策略在别处都不同能迁移的是两臂之间的比值百分比不是对 Cursor 的主张。比对的必须是正确的一对。在 with/without A/B 中是 codegraph 残差对 without 臂的file-access残差Read Grep/Glob Bash——Agent 把同样字节读进脑子的两种方式。只数 Read 工具会把经 Bashcat取文件的运行记成没读任何东西。充分不等于正确一次 Read 是票不是证明。桶仍是对的信号——Agent 去读说明有东西缺失——但单次调用有噪声。小样本永远。一次运行只有 1–5 次 explore 调用单运行的百分比很粗。表格打印median [min–max]正是为此报告区间。RUNS2下结论用战役。Subagent 上下文不计入 occupancy——Task子 Agent 有自己的窗口只有摘要回流。而 sufficiency会跟随子 Agent 线程委派按子 Agent 的第一个动作评判。两个指标对委派的差异化处理是刻意的。延迟工具 schema 计入 occupancy 的basecodegraph_explore是延迟加载的ToolSearch稍后拉取 schema那次注入不是工具结果fixed-overhead 行只计价一开始就存在的部分。Contamination先看这一行两套 harness 都让每个臂运行在一个屏蔽 codegraph CLI的环境里PATH 中把二进制符号链接摘除的净化目录外加一个PreToolUse钩子拦截绝对路径调用no-cli-shim.sh两套 harness 共用。两层都必要——曾有 Agent 在 PATH 上拿不到codegraph后执行find / -iname *codegraph*找到二进制并用绝对路径调起。Contamination 行是检测的一半与预防的一半不冗余预防在下一次二进制落到新位置时会静默失效计数器不会。在with/withoutA/B 中一次 CLI 调用意味着 without 臂并非without。某次 7 仓库遍历中 15 次 without 臂运行有 14 次通过 Bash 跑了codegraph explore——shim 之前的所有旧结果都应假定已被污染。在new/baselineA/B 中两臂都是 codegraph-onCLI 调用不是泄漏而是归因失败会同时破坏三个指标经 Bash 到达的输出在 occupancy 表里被记到 Bash 头上经 CLI 发出的 explore 根本不是工具调用永远到不了 sufficiency 分类器和 allocation 解析。运行会静默地把调用从上方每个数字里丢掉。CLI attempts blocked是良性的——Agent 试了但没有任何内容进入窗口。CLI calls that RETURNED output不是。parse-run.mjs 用只匹配命令位置而非任意提及的正则识别 CLI 调用grep codegraph x、ls .codegraph、which codegraph都是看而不是用放行。测试指标数学本身的回归用内建 selftest 覆盖node scripts/agent-eval/parse-run.mjs --selftest # 68/68它对带已知答案的合成转录做断言occupancy 的完整算术校准、FIFO 逐出、compaction 清空、sufficiency 的每个桶以及 same-message/thread/delegation 三条规则、allocation 的引用通道及其守卫歧义上限、prose 不计引用、per-call 与 pooled 的口径。selftest 特意放在 parse-run.mjs 内部而不是独立测试文件——新写的scripts/agent-eval/*.mjs会进入 self-query eval fixture 自己的语料污染被评测对象。各指标的用例清单见对应指标文档。小结这套三指标体系的设计逻辑一句话概括occupancy 管留了多少sufficiency 管够不够allocation 管送得准不准三者接在同一次运行上互相制衡——任一指标单独向好都可能被另外两个证伪。运行侧记住三件事即可按问题选 harness隔离改动用ab-new-vs-baseline.sh采用/位移用run-all.sh战役用bench-readme.shRUNS2并报区间输出表先看 contamination 行再看其余数字。【免费下载链接】codegraphPre-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考