📌 项目地址：vitali87/code-graph-rag | ⭐ 4,418 颗星 | 🔧 Python | 📜 未标注
问题在哪
问 LLM“这个函数被谁调用”，它要么拒绝，要么编。上下文窗口装不下真实代码库，向量检索召回的是文本相似片段。调用关系、影响范围、死代码——这些是结构问题，需要的是节点和边，不是嵌入。
vitali87/code-graph-rag（4418 star，Python）的做法：用 Tree-sitter 解析代码库，把函数、类、方法、模块及其关系存进 Memgraph 图数据库。之后你在 CLI 里用自然语言提问，AI 把问题转成 Cypher 查询，在图上执行，结果基于真实的结构边。
Source Code -> Tree-sitter Parser -> AST Analysis -> Memgraph Knowledge Graph
|
User Query -> AI Model (Cypher Gen) -> Cypher Query -> Graph Results -> Response
架构和图 schema 有单独文档：docs/architecture/overview.md 和 docs/architecture/graph-schema.md，上手前值得先读。
一套 schema 吃下多语言 monorepo
完全支持的语言：Python、TypeScript、TSX、JavaScript、Rust、Go、Java、C、C++、C#、PHP、Lua、Dart。Scala 开发中。Ruby、Kotlin、Swift、Elixir、Haskell、Solidity、Bash、Nix 有结构性支持，即模块、函数、类这类基础结构能进图。
关键点：所有语言共用一个 schema。Java 的方法和 Go 的函数在图里是同类节点，跨语言找调用链就是一次图遍历。维护“Python 后端 + TypeScript 前端 + Go 网关”这种仓库的人，问“改这个接口影响多少上游”，只有统一图答得上来。单语言小项目用这套没必要。
两个值得停下来的功能
AST 级编辑。 agent 改代码时，patch 基于 AST，改动前有 diff 预览。LLM 改代码的风险是改动范围失控——diff 预览是闸门，AST patch 保证改的是代码结构，不是文本位置。
运行时行为叠加。 cgr trace 追踪一次测试运行，也能拉生产环境的 eBPF profile，把实际发生的调用合并进图。接口背后真正走了哪个实现，静态分析看不到，代码跑起来才知道。静态边加动态边，图会准得多。我认为这是项目里最有想象力的一步。
其余功能：按名字或意图取回任意函数源码；按语言最佳实践或自定义规范做代码优化；用 ast-grep 按 AST 模式做结构化搜索和重写；从入口点沿调用边和引用边走，找出死代码——死代码检测本质是图可达性问题，grep 做不了。
近期更新的信号
三条更新：
- 图索引：name 属性建了索引，加快读路径查询；SQL 例程也建了索引，解析在字符串里写目标名的调用
- 重复代码检测：基于 AST，修了跨多仓库的重复检测
- benchmark：加了 agentic QA 的评测框架和索引耗时 benchmark
一个项目开始给自己做 benchmark，说明作者在认真对待质量退化。
成本要想清楚
一，要跑 Memgraph。不是 pip install 就完事的工具，先部署一个图数据库实例。
二，数据在库里，不在文件里。代码一改，图就过期，需要重新索引。索引 benchmark 的存在说明作者清楚这个问题，但成本还是你的。
判断
这个项目的路线：代码理解的本质是关系，关系的最佳存储是图。向量库丢结构，LSP 单语言，文本索引答不了可达性问题。做这条路的人不多，但逻辑成立。4418 star 对一个需要自建图数据库的工具来说不是小数字。
建议先在非核心仓库跑一遍，确认你的语言组合下解析质量可接受，再考虑铺开。