Graft的Benchmark比“让Agent更懂代码库”更有价值：Context Graph必须证明省Token时没有把旧理解固化

AH-0525讲Nanonets开源的Graft。

它把代码库构造成一组可读的linked markdown节点，让Claude Code、Cursor、Codex、Gemini等Agent先读“代码库地图”，而不是每次从零grep和翻文件。

截至2026-08-15，官方GitHub当前采用MIT，并且不是只说“更快更省”：README公开了162次受控benchmark、两类仓库、Cold/Graft/Pull不同变体，以及真实开源仓库任务。

这比很多“上下文神器”更值得研究。

但Benchmark本身也需要拆。

1. Graft解决的是Orientation Cost

Coding Agent每次进入陌生仓库都会做大量重复动作： 找入口； 看目录； 找调用关系； 理解模块； 重新回答“这个系统怎么工作”。

这些成本并不直接产出代码。

Graft把部分理解预生成成： 概念节点； API说明； 依赖关系； linked graph。

所以它更像 Codebase Orientation Cache。

2. 当前官方数据比原帖更复杂

原帖写： 工具调用↓46%； Token↓42%； 时间↓60%； 正确率65%→75%。

当前README的受控162-run表里： tool calls约-46%； uncached input tokens约-42%； latency约-60%； 而Graft push版本正确率与cold相当。

另一个pull variant正确率更高。

“65→75”来自不同SWE-bench/实现测试语境，不能把所有指标拼成一个万能Benchmark。

Metrics from Different Experiments ≠ One Combined Result。

3. “最多4×便宜、3×更快”是Max，不是平均

官方README自己解释： 4×/3×来自真实仓库 sweep中的单项最大优势。

最大值适合说明可能性。

不适合写成： “安装后平均4倍便宜。”

需要同时保存： mean； median； max； task type； repo size； model； cache pricing。

4. Context Graph最危险的不是生成错，而是“旧”

代码库每天变化。

如果Context Graph描述： 旧API； 旧文件； 旧依赖； 已经删除的行为；

Agent会少搜索，但可能更自信地走错。

所以预计算Context一定需要：

Source Commit → Build Time → Changed Files → Invalidated Nodes → Rebuild → Freshness Check。

Cached Understanding Has a Half-life。

5. LLM推断的关系要和静态解析关系分开

Graft当前可视化里会区分tree-sitter提取的edges和LLM-inferred edges。

这是非常好的设计信号。

因为： extends / imports / calls 可能来自代码静态结构；

“这个模块负责认证策略” 则可能是模型解释。

两者证据等级不同。

Parsed Edge ≠ Inferred Semantic Edge。

6. Graph不是项目事实的唯一来源

再好的上下文层也不能替代： 源码； 测试； 构建结果； 当前配置； 运行时行为。

当Graph与代码冲突时：

Source of Truth应该回到代码/测试。

所以Agent使用Graph的正确姿势是： Orient with Graph → Verify Critical Path in Source → Act → Test。

不是： Graph说了就直接改。

7. Benchmark还要看任务分布

162次受控实验很有价值，但仍要问： 单文件还是跨模块？ 问答还是实现？ 仓库规模？ 语言？ Agent模型？ 缓存价格？ Graph构建成本有没有计入？

一个context tool对陌生大仓库可能帮助巨大，对10个文件的小项目可能反而增加成本。

8. 本地Graph也不是没有治理成本

Graft当前把graph作为可再生local cache，并默认加入.gitignore，而不是把所有生成节点提交到Git。

这个设计降低了“把机器生成理解当长期项目事实”的风险。

但团队仍要考虑： 每个人Graph是否一致； 何时重建； CI是否需要验证； 生成过程是否访问外部模型； 敏感代码是否出网。

9. 商业机会：Context Layer Audit

任何Agent Context产品都可以统一审：

Coverage； Freshness； Source Mapping； Parsed vs Inferred； Token Saved； Build Cost； Correctness； Stale Failure； Recovery。

这能进入Codex Capability Drift Monitor / Evidence Research Workbench。

10. V3怎么测

选3类真实仓库： 小； 中； 大。

每类准备： 定位问题； 跨模块解释； 真实Bug修复； 小功能实现。

Cold与Context Layer对比： 总token； tool calls； wall time； 正确率； 错误文件修改； 人工review时间； Graph build cost。

如果省了token却增加review，就不是净收益。

Stop Rule

如果Context Layer频繁过期、关键解释无法定位回源码，或者团队开始相信Graph而不验证测试，就降低它的权限，只把它用于Orientation。

Agent真正需要的不是“更多上下文”，而是用更少上下文、更快抵达当前真实代码。