你的 AI 编程账单有一半在浪费——CodeGraph 试图解决这个问题

📌 闭环笔记 = AI Agent 时代个人的信息闭环系统，调研→实践→输出，直到你遇见我。

关注我，获取更多AI观察与个人思考 🧰☕

AI 编程的隐形成本

用 Claude Code 或 Cursor 写代码的人，大概率经历过这样的场景：你让 AI 改一个功能的实现，它先花十几秒 grep 了一堆文件，读了半天代码，然后给你一个方案——但改错了地方。你又让它重试，它又从头 grep 一遍。等到它终于改对了，你看一眼账单，发现这一轮消耗的 Token 够写十个同样难度的函数了。

这不是模型不够聪明的问题。这是"发现"的问题。

AI Agent 在你的代码库里找东西，和你在陌生城市找路本质上一样——没有地图，只能一条街一条街走。更麻烦的是，它每次"失忆"之后都得重新走一遍。因为大模型的上下文窗口是有限的，当你开一个新会话，之前积累的对代码库的理解就全部清零。Agent 必须从第一行代码开始重新认识你的项目。

让我们算一笔账。以 Claude Sonnet 4 的 API 定价为例：输入 Token 3 美元/百万，输出 Token 15 美元/百万。看起来很便宜对吧？但"找东西"这件事的消耗量惊人。

假设你的项目有 500 个文件，平均每个文件 2000 Token。你要让 AI 改一个涉及 3 个模块的功能，它大概需要：先 grep 找到相关文件（消耗 5-10 次工具调用，每次读取 2-3 个文件），再理解调用关系（可能再多读 10 几个文件），最后才能动手改。这个过程光是"读代码"就会消耗约 4-6 万个输入 Token。

如果改错了需要重试——这在 AI 编程中非常常见——整个"发现"过程再来一遍。一次功能修改，光是让 AI "找对地方"，就可能花掉 10 万个 Token。按 Claude Sonnet 4 的价格，折合人民币大约 2-3 元。

2-3 元听起来不多？但如果你每天和 AI Agent 交互 20 次，每次修改都经历类似的"发现"过程，一个月下来光是"找东西"的 Token 费用就接近 2000 元。这还只是单个开发者的开销。一个 5 人团队，每月在 AI 编程的"搜索费"上可能就要花掉近万元。

更关键的是，这些 Token 里的大部分并没有在"创造价值"——它们花在了重复扫描已经被扫描过无数次的文件结构上。就像你每天上班都要重新认一遍办公室的门牌号，然后才能开始干活。

一个 2026 年初开源的项目试图解决这个痛点。它叫 CodeGraph，四个月拿了 2.2 万个 Star。

CodeGraph 的思路：给代码建一张图

CodeGraph 的核心想法很朴素：与其让 AI 每次都从零开始翻文件，不如先给它建一张"地图"。

具体做法是：用 tree-sitter 对代码做静态分析，提取函数、类、变量之间的调用关系和结构关系，存成一张知识图谱（底层用 SQLite）。当 AI Agent 需要了解代码结构时，它不需要 grep 全部文件，而是直接查这张图谱。

官方 Benchmark 数据看起来很漂亮：

• 成本降低 35%
• Token 消耗减少 57%
• 执行时间缩短 46%
• 工具调用减少 71%

这个数据来自 7 个开源项目的中位数。把 Token 节省换算成费用：以 Claude Sonnet 4 定价计算，一个中型项目每次 AI 辅助修改平均能省 2-5 元。如果你是重度用户，每天交互 20 次以上，一个月省下来的 Token 费用在 1000-3000 元之间。

拆开来看，大型项目的效果尤其显著——Tokio（Rust，790 个文件）省了 86% 的 Token 和 92% 的工具调用，Excalidraw（640 个文件）省了 90% 的 Token。在 Tokio 这种规模的项目上，一次跨模块修改可能涉及几十个文件的调用链，Agent 传统方式要读的代码量是海量的——没有图谱的辅助，光"发现"环节就可能消耗几十万个 Token。

但小项目的效果就没那么夸张了。Gin（Go，约 110 个文件）只省了 21% 的成本和 34% 的 Token。这很合理——小项目本来就没几层关系需要索引，Agent 自己翻文件也翻不了多久。就像给一个三室一厅装导航系统，你最多省走两步路的时间。

这个数据差异本身就说明了一个问题：CodeGraph 的价值与项目复杂度正相关。项目越大、模块越多、调用链越深，预先索引带来的收益就越明显。但对于大量中小型项目，它的边际价值可能没有 Benchmark 看起来那么惊艳。

几个关键特性值得一提：100% 本地运行、不需要 API Key、支持 19 种以上编程语言、文件变更后自动增量更新。支持的 AI 工具包括 Claude Code、Cursor、Codex CLI、opencode 和 Hermes Agent。

社区为什么买账

2.2 万 Star 说明这个方向踩中了真实需求。几位深入评测的开发者从不同角度验证了它的价值。

独立开发者 dibi8 的评测可能是目前最全面的一篇。他指出了一个被大多数人忽略的关键点：AI Agent 的慢不在模型推理，而在"发现"环节。每次 Agent 重新扫描文件结构，是整个流程中最大的时间浪费。CodeGraph 把这个过程从 4-9 秒压缩到 50-200 毫秒——这个量级的差距在日常使用中的体感是明显的。

他还做了一个有价值的对比：LSP（语言服务器协议）和 CodeGraph 都在做代码分析，但设计目标完全不同。LSP 是为人类编辑器设计的，单语言、实时响应、适合光标跳转。CodeGraph 是为无头 Agent 设计的，多语言、批量查询、适合"告诉我这个函数被谁调用了"这类宏观问题。

另一个经常被拿来对比的产品是 Sourcegraph 和 Continue。但这两者是云服务，要么需要自建服务器，要么需要付费订阅。CodeGraph 的定位更轻——一个二进制文件，本地跑，开箱即用。

俄语技术社区 Habr 的一篇评测把 CodeGraph 和同赛道的 SocratiCode 做了对比。SocratiCode 用 Qdrant 向量数据库做语义搜索，需要 Docker 环境；CodeGraph 用 tree-sitter + SQLite 图结构，单二进制部署。两者的能力边界恰好互补：CodeGraph 擅长确定性查询（"函数 A 调用了哪些函数"），SocratiCode 擅长模糊搜索（"找类似 X 的东西"）。

不过这篇评测也揭露了一个值得注意的现象：有人在 Telegram 上为 CodeGraph 做推广，编造了不存在的"Hermes Agent"使用案例。开源项目的社区推广，也需要打假。

一个经常被忽视的独立价值：评测者 arshtechpro 发现，CodeGraph 提供的 codegraph affected 命令可以用来跑 CI——只测试被代码变更影响的测试用例。这个功能和 AI 编程完全无关，但对大型项目的 CI 效率提升是实打实的。

真实使用中暴露的问题

Benchmark 数据好看，但真实世界的故事不太一样。

最引人注目的一篇内容来自开发者 rentierdigital。他用了同类产品（graphify，非 CodeGraph，但技术路线相同）做了 14 天的实战审计。结果令人沮丧：60 个 AI 编程会话、触发了 1500 次 hook 提醒，图谱被主动调用 0 次。

Agent 不是不能用图谱，而是选择不用。原因很直接：grep 只需要一步就能拿到文件内容——它知道文件名，直接读就是了。查图谱需要两步——先读取图谱报告理解结构，再根据报告去读具体的源文件。Agent 的决策机制像一个实时套利者，它会评估每条路径的预期成本，然后选它认为"最短"的那条。你给了它一条更快的高速公路，但它发现旁边的小路也能到，而且不用先停下来查地图。

这背后还有一个更深层的原因：当前大多数 AI Agent 的工具调用策略是贪心的——它不会为了长期效率牺牲短期步骤数。即使查图谱在整体上能省更多 Token，但 Agent 的单步决策逻辑让它倾向于选"这一步最少操作"的方案。

这个发现引出了一个更深的问题：Benchmark 测试的是什么？ CodeGraph 的 Benchmark 是"强制让 Agent 使用图谱"的场景——相当于在导航测试里禁止司机凭直觉开车，必须跟着 GPS 走。但真实使用中，Agent 有选择权，它会比较不同路径的"成本"，然后选它认为最快的。

GitHub Issues 也反映了真实使用中的痛点。目前有 147 个 Open Issues，其中几类高频问题值得关注：

• 内存溢出（#293、#54）：大型仓库首次索引时内存消耗过大，直接崩溃
• Codex CLI 挂起（#295）：调用 codegraph_context 后卡死
• 大型仓库支持不足（#320）：当前设计不适合 monorepo 级别的项目
• 安装问题（#10、#38）：Linux 下安装后找不到命令
• 配置不同步（#270）：版本升级后 include/exclude 规则不自动迁移

这些问题说明 CodeGraph 目前更适合中小型项目。对于几万文件的大型代码库，它自身的索引过程本身就可能成为瓶颈——你用一个工具解决"扫描太慢"的问题，但这个工具自己的扫描也慢。这就有点尴尬了。

refft.com 的分析指出了图结构的固有局限：反射调用、运行时代码生成、复杂的宏和模板系统，都会产生假阴性——图谱里没有，但实际存在的关系。这是所有基于静态分析的工具的共同天花板。

几点独立思考

给 Agent 更多上下文，还是帮它少走弯路？

CodeGraph 的思路是前者——预先计算更多结构信息，让 Agent 查询时能更快找到答案。但 14 天审计的案例暗示了一个更根本的问题：当你给 Agent 更多选择时，它不一定选你希望它选的那个。

这让我想到了一个来自不同领域但原理相通的观察：在设计产品时，"减少选择"往往比"增加选项"更有效。Amazon 的一键下单之所以成功，不是因为它的购物车功能更强大，而是因为它把从"想买"到"买完"的路径压缩到了极致。

同理，更有效的方向可能是后者——直接从 Agent 的执行路径上移除冗余操作，而不是给它一个更好的替代方案让它自己选。

打个比方：与其给司机一份更详细的城市地图，不如把红绿灯优化一下，让主干道更通畅。前者需要司机主动翻地图，后者司机什么都不用做就能受益。

这并不意味着 CodeGraph 的方向错了。但它的价值释放可能依赖于一个前提条件：AI 编程工具需要在底层架构上更好地集成图谱查询，而不是把图谱当作一个可选的 MCP 工具让 Agent 自己决定用不用。

确定性 vs 概率性：两条路都会走通

CodeGraph 用的是确定性图谱（基于 AST 的函数调用关系），SocratiCode 用的是概率性向量搜索。这不是谁对谁错的问题，而是回答不同类型的问题：

• "这个函数被谁调用了？" → 确定性图谱，答案精确
• "有没有类似的功能已经实现了？" → 概率性搜索，答案模糊但有启发

长期来看，这两个能力大概率会合并。理想的代码索引工具应该同时支持"精确导航"和"模糊发现"。

赛道正在形成

CodeGraph 并不是唯一一个在做的。code-review-graph 号称 49 倍 Token 节省，Code-Graph-RAG 试图结合图谱和 RAG，Greptile 专注 PR review 场景。多个项目同时涌入，说明 AI 编程的上下文效率是真实痛点——Token 不是免费的，工具调用次数直接影响用户体验和成本。

但这个赛道的终极赢家可能不是某个具体的索引工具，而是能把索引能力直接内建到 AI 编程工具底层的方案。Cursor 已经在这么做——它的 codebase indexing 功能本质上就是把类似 CodeGraph 的能力直接嵌入到了产品内部，用户不需要额外安装任何东西。Claude Code 也在不断增强对代码库的内置理解能力。

就像今天没人单独买一个"文件搜索软件"一样——因为操作系统的搜索已经够用了——当代码索引成为 AI 编程工具的标准能力时，独立工具的存在价值就会从"必需品"变成"高级选项"。

对普通开发者的实际建议

如果你在考虑要不要用 CodeGraph，几个实用的判断标准：

值得尝试的场景： 项目文件超过 500 个、频繁让 AI 做跨模块修改、团队成员共用一个代码库。这些场景下，Agent 反复扫描文件结构的成本确实很高，图谱带来的效率提升是可感知的。

别期待太高的场景： 小型项目（不到 200 个文件）、大量使用反射或动态特性的代码、需要频繁重索引的 monorepo。这些场景下，要么效果有限，要么工具自身的稳定性还有待提高。

最重要的一个判断： 如果你的 AI 编程工具已经在底层做了类似的代码索引（比如 Cursor 的 codebase indexing），额外装 CodeGraph 的边际收益可能比你想象的小。

CodeGraph 做了一件对的事：它把"AI 编程的隐形成本"这个问题摆到了台面上，并且提供了一个可行的技术方案。但一个工具被 Star 2.2 万次和它每天被几百万开发者实际使用，中间还有很长的路。对这类工具保持关注，但不必急着把全部工作流押上去——这才是理性的态度。

参考来源

• CodeGraph GitHub 仓库：https://github.com/colbymchenry/codegraph^[1]
• dibi8 深度评测——AI Agent 的慢不在推理，在「发现」：https://dibi8.com/resources/dev-utils/codegraph-pre-indexed-knowledge-graph-2026/^[2]
• arshtechpro 实操分享——Stop your AI agent from grepping files 50 times：https://dev.to/arshtechpro/codegraph-stop-your-ai-agent-from-grepping-the-same-files-50-times-3bgm^[3]
• Habr 俄语评测——CodeGraph vs SocratiCode 技术路线对比：https://habr.com/ru/articles/1038474/^[4]
• refft.com 分析——静态分析的边界与实用建议：https://refft.com/en/colbymchenry_codegraph.html^[5]
• 14 天审计实战——同类产品 60 会话 0 次图谱调用的真实记录：https://dev.to/rentierdigital/i-installed-a-knowledge-graph-on-claude-code-14-days-later-the-audit-killed-my-enthusiasm-1p1n^[6]

引用链接