代码图谱怎么帮 agent 省 token：什么仓库值得建
代码图谱怎么帮 agent 省 token：把「找」变成「查」，本文算建图成本、失效时机和 ctags/LSP 等价做法。
agent 在上万文件的仓库里回答一个架构问题，可能要 40 次工具调用。代码图谱怎么帮 agent 省 token，靠的是把「满仓库找」换成「查一张建好的符号表」，省下发现阶段的开销。
agent 在大仓库里找代码，账单长什么样
40 次工具调用、17 个文件读取，只为回答一句「请求怎么走到数据库」。这是 CodeGraph 自报的 VS Code 对照组，同一个 Claude Code 无头会话换成带图谱之后是 2 次调用、0 次文件读取。数字出自项目 README，标注 2026-07-21 在 Claude Opus 4.8 上重跑、4 轮取中位数，属于项目自评而非第三方复现。
贵在哪里，拆开是四段。第一段是宽匹配，Claude Code 的 Grep 工具建在 ripgrep 上，官方文档写明默认输出模式是 files_with_matches，只回路径不回内容，agent 拿到路径后几乎必然接着 Read，因为路径判断不出函数边界。第二段是整文件注入，800 行的 middleware 里可能只有 20 行相关，进上下文的仍是 800 行。第三段是试错重来，正则写宽了就换词重搜，每一轮结果都留在上下文里继续计费。第四段是跨文件追链，handleRequest 调了谁、谁调了它，grep 只能一层层展开。
图谱把「找」变成「查」，靠的是三类边
图里存三样东西：符号节点（函数、类、方法）、调用边（谁调用谁）、依赖边（import、继承、实现）。建完之后，「请求怎么走到数据库」从一次字符串搜索变成一次图遍历，返回的是相关符号的源码，外加它们之间的调用路径和改动影响面。
CodeGraph 的实现是 Rust 内核编译进 tree-sitter 语法，抽出节点和边后再解析一遍：函数调用连到定义、import 连到源文件、类继承连上父类，最后补一层框架约定路由。结果落进 .codegraph/codegraph.db，一个带 FTS5 全文索引的 SQLite 库，对 agent 只暴露一个 MCP 工具 codegraph_explore。
graphify 走另一条路，装成 Claude Code 的 /graphify skill：代码用 tree-sitter 做 AST 加一遍调用图，文档、PDF、截图交给 Claude 抽概念和关系，再用 NetworkX 加 Leiden 社区发现聚成 graph.json。每条边打上 EXTRACTED、INFERRED、AMBIGUOUS 标签，抽出来的和猜出来的分得开。
两个都是社区项目，没有任何厂商背书。2026 年 8 月 4 日查 GitHub API：CodeGraph 是 MIT 许可、64,297 star、387 个 open issue，建于 1 月 18 日；graphify 是 Apache-2.0、101,870 star、794 个 open issue，建于 4 月 3 日。两边最近推送都在 8 月 1 日。star 量级说明有人在看，说明不了它适配你的语言栈。
建图成本：一次全量，之后跟着文件事件走
cd your-project
codegraph init
一条命令建库并跑完全量索引。之后的增量挂在操作系统原生文件事件上，2 秒静默窗口去抖，只过滤源码文件，按 README 说法无需额外配置。
graphify 的增量分两档，这个分档决定钱花在哪。--watch 模式下代码文件一保存就立刻重建，纯 AST，不调模型；文档和图片改动只会提示你手动跑 --update，因为那一遍要过 Claude。它另外提供 graphify hook install 装 post-commit 钩子；缓存按 SHA256 记，只重跑变过的文件。
成本分界就在这里。纯代码建图是一次性 CPU 开销，几分钟量级，不产生 API 账单；把 PDF、设计稿、截图拉进同一张图之后，每次全量重建都在花模型调用的钱，这种图别配自动重建。
代码一改图就旧，静态分析还有天花板
图会过期，这是它相对 grep 的结构性劣势。grep 每次读磁盘上的当前状态，永远不过期；图是某个时刻的快照，重构一次就开始漂移。Claude Code 团队讲过早期版本用 RAG 加本地向量库、后来换成 agentic search，理由里就包括索引过期。这段话来自播客转述，多篇技术博客引用过，不算官方文档条目。
第二层限制是静态分析自己的天花板：动态派发、反射、DI 容器、框架约定入口，解析器看不到。CodeGraph 把这个残差公开量化了，按语言给出跨文件依赖的解析覆盖率，每种语言挑一个真实开源仓库当基准。Python 用 psf/requests 是 100%，Go 用 gin 96.6%，Rust 用 ripgrep 86.7%，Liquid 用 Shopify/dawn 只有 73.8%。框架路由同理，Express 和 Axum 都是 100%，约定与反射偏重的 Spring 83.3%、Django 74.1%。这些同样是项目自报，好在它肯把低分摆出来。
落到用法上：图给的答案当高召回候选用，别当完备结论。让 agent 用图定位入口，动手改之前再用一次 grep 或 LSP 的查找引用交叉验证，在那几个 80% 出头的语言栈里尤其要补这一步。
多大的仓库才值得上
收益随仓库规模单调变化，小仓库基本白装。CodeGraph 自报的七仓对照里，这个趋势很清楚：
| 仓库 | 语言与规模 | 工具调用（带图 vs 不带） | token | 成本 |
|---|---|---|---|---|
| VS Code | TypeScript，约 11k 文件 | 2 vs 40 | 少 83% | 省 75% |
| Django | Python，约 3k 文件 | 2 vs 29 | 少 78% | 省 69% |
| Tokio | Rust，约 790 文件 | 3 vs 57 | 少 91% | 省 86% |
| OkHttp | Java，约 645 文件 | 1 vs 5 | 少 33% | 基本持平 |
| Gin | Go，约 110 文件 | 3 vs 10 | 少 18% | 省 41% |
OkHttp 那一行最诚实：不带图的对照组运气好，5 次调用就答完，带图的 1 次调用反而多花约 0.03 美元。README 也承认小仓库有地板效应，Opus 4.8 在小树上 grep 快到能赢墙钟，代价是多烧 5 到 10 倍 token。
graphify 的数字指向同一方向。它自报在 52 个文件的混合语料（Karpathy 的仓库加 5 篇论文、4 张图）上，单次查询 token 是直读原文件的 1/71.5；4 个文件的语料降到 5.4 倍；6 个文件的项目约 1 倍，等于没收益，因为 6 个文件本来就塞得进上下文窗口。
一条能用的分界：源文件超过约 2000 个，或 agent 每天在同一仓库里跑十次以上探索，建图开始划算。几百个文件的服务，把目录结构和入口写进 AGENTS.md 更省事。检索之外还有哪些 token 在白烧，agent 怎么把 token 花掉 里拆过另外几个来源。
不装工具的等价做法：ctags、LSP、索引缓存
符号级导航不必依赖第三方图谱，Claude Code 的官方工具参考页里就列着一个 LSP 工具。文档对它的描述是：跳转到定义、查找全部引用、取某个位置的类型信息、在 workspace 里按名字搜符号、找接口实现、追调用层级，几乎覆盖了代码图谱的核心查询。前提写在同一页：它在你为该语言装上 code intelligence 插件之前处于 inactive 状态，插件只带语言服务器配置，二进制要自己另装。
比 LSP 更轻的一档是 universal-ctags：
ctags -R --languages=Python,Go,TypeScript --fields=+niKSl --exclude=node_modules .
生成的 tags 是纯文本符号表，一行一个符号带路径和行号，agent 一次 grep 就能把「这个函数定义在哪」问掉。短板是只有定义、没有调用边，追不了链；长处是零依赖、秒级生成、CI 里随手能跑。
第三条是把检索结果缓存下来，rg --json 的输出可以落盘复用，同一 session 里重复的问题不重复搜。再往上是在 AGENTS.md 里写死检索顺序，比如「查符号走 LSP，确认字面量才用 Grep，禁止无目标全库搜索」。这条不花钱，但得抽查 agent 的首步行为，否则只是写着好看。语义检索那条路线的账，Semble 给 agent 省搜索 token 里算过；省下的额度怎么排进窗口，Claude Code 上下文窗口管理 里另有一套做法。