CodeGraph基准测试方法论：7大仓库A/B实验完整拆解
【免费下载链接】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
想验证"代码知识图谱真的能省 token 吗"？CodeGraph 基准测试给出的答案靠的是一套可复现的 A/B 实验方法论：同一个模型、同一个提示词，唯一变量是有没有接入 CodeGraph，在 VS Code、Excalidraw、Tokio 等 7 大仓库上对跑 74+ 次 Agent 实验，量化出成本、token、耗时与工具调用四组差异。本文完整拆解这套方法论：选仓库的逻辑、实验如何跑、数据怎么读，以及三个差点毁掉结论的测量陷阱。
一、为什么用 A/B 实验：只动一个变量的对照设计
评价"AI 编码助手 + 代码索引"这类工具，最忌讳拿"我觉得快了"当结论。CodeGraph 的基准测试核心思路非常朴素：单变量对照（A/B testing）。
| 对照组 | 配置 |
|---|---|
| with 组 | 挂载 codegraph 的 MCP Server，禁用其他一切 MCP |
| without 组 | 空 MCP 配置，Agent 只能用内置 Read/Grep/Glob/Bash |
两组使用同一模型、同一提示词、同一个问题，每次跑之前都对仓库做全新重建索引（rm -rf .codegraph && codegraph init -i），确保"with 组"反映的是当前代码的真实水平。
两个关键设计决定：
- 模型下限原则：所有实验臂固定
--model sonnet --effort high。Sonnet 是刻意选择的"地板"——一个在 Sonnet 上成立的能力可以泛化到更强的模型，反之则不成立。详见 agent-eval-feedback-metrics.md。 - 无头模式 + 流式日志：Agent 以 headless 方式运行，全部行为落在 stream-json 日志里，再由解析脚本离线统计——指标不靠人工看运行结果，而是从日志中"再挖掘"，同一批日志可以反复产出新分析（比如 call-sequence-analysis.md 就没有重跑任何实验）。
二、7 大基准仓库如何选：按体量分层，按语言覆盖
README 发布的基准选了 7 个真实流行仓库，覆盖前端、后端、Rust、Go、Swift、Java 等不同语言生态，每个仓库配一道规范化流程问题（canonical flow question），例如 Tokio 对应"tokio 如何在运行时上调度并运行异步任务？"。
当前构建（2026-05-24 复测，每臂 4 次运行取中位数）的 A/B 结果：
| 仓库 | 耗时 with → without | 工具调用 with → without | token 节省 | 成本节省 |
|---|---|---|---|---|
| vscode | 1m10s → 2m26s | 8 → 55 | 78% | 26% |
| excalidraw | 48s → 2m58s | 3 → 79 | 90% | 52% |
| django | 1m19s → 1m38s | 9 → 19 | 36% | 12% |
| tokio | 53s → 3m02s | 4 → 53 | 86% | 82% |
| okhttp | 42s → 1m01s | 6 → 11 | 13% | 2% |
| gin | 44s → 1m00s | 6 → 10 | 34% | 21% |
| alamofire | 1m17s → 2m27s | 12 → 69 | 64% | 47% |
平均节省：35% 成本 · 57% token · 46% 耗时 · 71% 工具调用。
数据里藏着一个值得新手理解的规律：节省幅度取决于问题的"发现成本"，而不是仓库大小。tokio、excalidraw 这类问题上，without 组要扇出 53–79 次工具调用去"大海捞针"，CodeGraph 的优势充分释放（成本省 52%–82%）；而 okhttp、gin 上 without 组 10 次调用左右就能到达答案，两边差距自然小。这也是为什么文档反复强调：单看一个仓库的数字没有意义，要看整组分布。
三、实验怎么跑：一条命令启动整个 A/B 矩阵
整套 harness 是纯脚本，核心两条命令：
- 启动实验：
bash scripts/agent-eval/bench-readme.sh—— 7 个仓库 × with/without 两组 × 每臂 4 次运行（RUNS=4可调），日志落到/tmp/ab-readme，入口脚本见 bench-readme.sh。 - 解析汇总：
node scripts/agent-eval/parse-bench-readme.mjs—— 从日志中提取每轮 assistant 的usage求和、total_cost_usd、duration_ms，输出中位数与节省百分比，见 parse-bench-readme.mjs。
单仓库快速验证则用scripts/agent-eval/run-all.sh <repo> "<question>" headless；换臂重跑只需CG_ARMS=with|without，不用重跑另一臂。
四、读懂数据：四个指标各回答什么问题
| 指标 | 回答的问题 | 常见误读 |
|---|---|---|
| 耗时（中位数） | 用户等多久拿到答案 | 单次运行波动大，必须取多次中位数 |
| 工具调用数 | Agent 浪费了多少"探索轮次" | 调用少 ≠ 答案对 |
| token 总量 | 处理了多少上下文 | 缓存读取很便宜，token 降幅 > 成本降幅是正常的 |
| 成本（美元） | 真金白银省了多少 | 短问题下 with 组要付 MCP 固定开销，成本可能打平 |
特别注意 token 与成本的关系：without 组的 token 大部分是便宜的缓存读取（cache-reads），所以 57% 的 token 节省只折算成 35% 的成本节省——机制是轮次更少、累积上下文更小，而不是缓存。
五、三个踩过的坑：测量可靠性比结论更重要
这份方法论最有价值的部分，其实是它公开记录的"差点出错"清单：
坑 1：token 统计只读了最后一轮。某版本 Claude Code 的result.usage只反映最后一个 turn，用它统计会严重低估多轮 Agent 的 token——曾导致 excalidraw 的 token 节省被误报为 34%（真实约 90%），还"无中生有"出两个仓库的 token 回归。教训：必须对每轮 assistantusage求和，该修复于 2026-08-05 合入 parse-run.mjs。且错误是单向的——总是低估 without 组，即总是低估 CodeGraph 的收益。
坑 2：CLI 污染对照组。without 组理论上"没有 codegraph"，但 15 次运行里 14 次的 Agent 绕过 PATH 屏蔽、用绝对路径偷偷调了 codegraph CLI——更早的历史数据基本应视为已污染。现在 harness 用"PATH 移除 + PreToolUse 钩子拦截"双保险，并在结果表中打印一行污染检测（CLI calls that RETURNED output必须为 0），见 no-cli-shim.sh 与反馈指标文档的 Contamination 一节。
坑 3：单次运行方差。37 格矩阵的文档明确要求：±1–2 次读取、±10 秒视为噪声，看跨格子的模式而非单点；正式结论一律RUNS>=2并取中位数，7 仓库 campaign 用 4 次/臂。
六、进阶：三个"反馈指标"把 A/B 结果落到归因
光有 with/without 的总分不够，CodeGraph 还定义了三个 harness-only 指标（全部从已有 transcript 解析，不产生额外数据、不离开本机），入口文档见 agent-eval-feedback-metrics.md：
- 残差上下文占用：运行结束时检索结果还"占着"上下文窗口多少 token——VS Code 仓库上约 67k，而文件读取组仅 18k。这是"吞吐快"的代价轴，文档坦诚说明它成本更高而非更低。
- Explore 充分性：看 Agent 拿到 explore 结果后的"下一步"——再次 explore / 去 Read 某个文件 / 直接作答，把"不够"细分为 allocation（给了对的文件但字节不对）与 recall（文件根本没出现）两类，各指向不同修复方向，见 explore-sufficiency.md。
- 分配效率：响应里返回的字节，多大比例被最终答案实际引用。
三者的关系被总结为一句话："表格回答'动没动'，逐运行明细回答'为什么'"。
七、动手复现：从 clone 到看到数据
# 1. 克隆项目 git clone https://gitcode.com/GitHub_Trending/co0degr/codegraph cd codegraph # 2. 构建（harness 依赖 dist/ 产物） npm run build # 3. 跑 7 仓库 A/B campaign（7 repos × 2 臂 × 4 次） bash scripts/agent-eval/bench-readme.sh # 4. 汇总中位数与节省百分比 node scripts/agent-eval/parse-bench-readme.mjs完整矩阵（37 个语言×体量单元格，74 次 Agent 运行，总计 $29.18）的原始数据与逐格解读，直接读 codegraph-ab-matrix.md；想深挖调用序列与 payload 分析，读 call-sequence-analysis.md。
写在最后
这套方法论对任何想给 AI Agent 工具做评测的团队都有参考价值：单变量对照 + 多次运行取中位数 + 污染检测行 + 从日志离线再挖掘。而它最诚实的一点是——CodeGraph 的文档里，"测量陷阱"和"胜出数据"享有同等篇幅：35% 的成本节省背后，是三次错误结果被自查捕获的记录。可复现、可质疑，才是基准测试该有的样子。
【免费下载链接】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），仅供参考
