Claude Code 在大型项目里有个老大难问题：它得一遍又一遍地扫描文件树、读取文件内容、搜索代码引用。每次对话，token 消耗像流水一样。
Codegraph 的思路很直接——提前把项目结构建成知识图谱，存在本地，Claude 用的时候直接查，不用每次重新读。
核心思路
传统的 Claude Code 工作流是这样的：
- 收到问题
- 读目录结构
- 根据目录决定读哪些文件
- 搜索特定符号的引用
- 反复迭代
Codegraph 把它变成了：
- 项目初始化时建好索引（只做一次）
- Claude 直接查询图谱，拿到文件关系和符号引用
- 省掉了反复扫描和搜索的步骤
最近一个 commit 很有意思：「refactor: Remove semantic search and vector embedding functionality」。作者删掉了语义搜索和向量嵌入功能，转向纯粹的结构化知识图谱。这个选择值得琢磨。
语义搜索听起来高大上，但在代码场景下其实不太实用。代码之间的关系是确定的——函数 A 调用函数 B，类 C 继承类 D。这种关系不需要「语义相似度」来判断，直接查图谱就行。砍掉向量搜索，减少了复杂度和维护成本，也降低了 token 消耗。
实测数据
项目文档里提到的核心收益：
- 更少的 token：不需要反复传输文件内容给模型
- 更少的工具调用：图谱查询一次到位，不用多轮搜索
- 100% 本地：所有索引数据存在本地，不经过任何外部服务
256 次提交，18 小时前还在更新。最近在做 Rust resolver 的 workspace crate resolution 支持，说明项目在扩展语言覆盖范围。目前支持的语言应该不止一种（CLAUDE.md 里提到了 Svelte language support）。
适用场景
特别适合：
- 大型代码库（几千个文件以上）
- 需要频繁在 Claude Code 里做跨文件分析的场景
- 对 API 调用成本敏感的团队
不太需要：
- 小型项目（几十到几百个文件，Claude Code 原生的工具调用已经够快）
- 项目结构变化极其频繁的场景（索引需要重建）
和其他方案的对比
Cline 有自己的一套上下文管理机制，但它是通用的，没有针对代码结构做专门优化。Codegraph 的差异化就在这里——它只做一件事：把代码结构变成图谱，让 Agent 查得更快。
这个思路对不对？我觉得大方向没问题。代码理解的核心是理解关系，不是理解「语义」。知识图谱天然适合表达关系，用在代码场景上比用在通用文本上更合理。
1300 多个 star，11 个 open issues，29 个 PR。项目处于活跃开发期，但还没到稳定 release 的阶段。如果你想用，建议先在小项目上试试水。
主要来源：