AI 编码工具最大的开销是什么？
不是 token 的价格——虽然那个确实不便宜。最大的开销是时间。
你让 Claude Code 或 Codex 帮你改一个功能，它要读文件、搜代码、看依赖、理解上下文……这个过程可能要来回几十次工具调用，每次都要等模型返回。对于一个不熟悉的大型项目，这个"热身"过程可能持续十分钟以上。
CodeGraph 的思路很直接：提前把项目的代码结构建成知识图谱，让 Agent 直接查询，而不是每次都从头扫描。
它做了什么
CodeGraph 由开发者 colbymchenry 创建，核心定位是：Pre-indexed code knowledge graph for Claude Code, Codex, Cursor, and OpenCode — fewer tokens, fewer tool calls, 100% local.
"预索引"是关键词。它在你开始用 AI 编码工具之前，先对整个项目做一次结构分析，生成一份代码知识图谱——哪些文件依赖哪些文件、函数之间的调用关系、模块之间的交互——全部预先建好。
当 Agent 需要理解某段代码时，它不需要再发一堆 tool call 去读文件、grep 搜索，而是直接查询知识图谱。一步到位。
数据说话
从最近的 commit 记录来看，CodeGraph 的性能优化方向很明确：
perf(mcp): answer-directly steering — ~35% cheaper, ~70% fewer tool calls——通过优化 MCP（Model Context Protocol）的交互方式，工具调用减少 70%，成本降低 35%release: 0.8.0——已经迭代到 0.8.0 版本，285 次 commitrefactor(eval): rename /audit skill to /agent-eval——内置了 agent-eval 评估技能- 测试覆盖扩展到了 Kotlin 和 Swift 语言
35% 的成本降低和 70% 的工具调用减少——如果你的项目比较大，这两个数字意味着实打实的钱和时间。
100% 本地运行的意义
CodeGraph 强调自己是 100% 本地运行。这不是一个噱头。
知识图谱包含的是你的项目结构信息——函数名、文件路径、依赖关系。这些数据如果传到云端，本质上就等于把项目架构暴露给了第三方。对于商业项目来说，这是一个安全问题。
本地运行意味着：
- 数据不出设备——知识图谱完全在你自己的机器上
- 零延迟查询——不需要网络请求，查询速度取决于本地性能
- 离线可用——即使没有网络，Agent 依然可以查询知识图谱
多 Agent 生态适配
CodeGraph 的适配范围覆盖了目前主流的 AI 编码工具：
- Claude Code：通过
.claude/skills目录提供技能插件 - Cursor：通过
.cursor/rules目录提供规则 - Codex 和 OpenCode 也都有对应支持
这种多工具适配的策略让它成为一个通用的基础设施层，而不是绑定在某个单一工具上的插件。
与 AgentMemory 的互补关系
有趣的是，CodeGraph 和最近同样爆火的 AgentMemory 解决的问题不同，但天然互补：
- CodeGraph 管的是项目的"结构记忆"——代码之间的依赖关系、架构设计
- AgentMemory 管的是"工作记忆"——之前的修改记录、架构决策讨论、bug 修复历史
两者结合的话，AI 编码 Agent 就同时拥有了项目的静态知识（CodeGraph）和动态历史（AgentMemory）。这基本上就是"认知式协作"的完整形态。
现实限制
CodeGraph 也不是没有短板：
索引质量取决于项目规范性。 如果项目本身结构混乱、命名不规范、缺少注释，知识图谱的质量会大打折扣。在高度规范化的项目中效果最好，在"野生"项目中可能需要额外的调优。
大型项目的索引时间。 对于一个百万行代码级别的项目，首次索引可能需要几分钟甚至更久。虽然这是一次性成本，但对于 CI/CD 流水线来说，需要把它纳入构建流程的考量。
更新策略需要设计。 代码是不断变化的，知识图谱需要同步更新。CodeGraph 目前的更新机制是基于文件变更触发的增量更新，但对于某些大规模重构场景，可能需要全量重建。
一个值得关注的信号
CodeGraph 的成功（11,500+ 星，一周 6,700+ 新增）反映了一个行业共识：AI 编码工具的下一阶段竞争，不是谁的模型更强，而是谁的上下文理解更快、更准。
当所有主流 Agent 都能访问同一个水平的模型时，差异化的关键就在于：谁能让 Agent 更快地理解你的项目。
知识图谱可能是这个问题的最优解之一。