AI 编程 Agent 的四张代码地图：CodeGraph、code-review-graph、Graphify、GitNexus 怎么用、怎么选、能不能组合？

最近代码图谱这条线，真的热起来了。

以前我们让 AI 编程工具理解一个项目，基本靠三板斧：

ls
find
grep
Read

看起来很朴素，也确实能用。

但项目一大，问题就来了。

Agent 可能先读错目录，再 grep 一堆无关文件，然后打开十几个文件，最后还是没摸到真正的业务链路。你看着它在那里转圈，token 在烧，时间也在烧，最要命的是：它还挺自信。

所以这一波 code graph / project graph 工具火起来，不是偶然。

它们本质上都在解决同一个问题：

不要让 AI Agent 像刚入职的新人一样乱翻代码。先给它一张地图。

这段时间我连续看了几个项目，也写过单篇分析。今天把其中四个放在一起讲：

• CodeGraph：https://github.com/colbymchenry/codegraph
• code-review-graph：https://github.com/tirth8205/code-review-graph
• Graphify：https://github.com/safishamsi/graphify
• GitNexus：https://github.com/abhigyanpatwari/GitNexus

这四个项目经常会被放进同一个讨论里，但严格说，它们不完全是同一种东西。

更准确的说法是：

它们都是面向 AI 编程 Agent 的代码/项目图谱工具，
但各自解决的问题不一样。

如果一句话概括：

CodeGraph：日常代码导航地图
code-review-graph：PR 审查和风险分析地图
Graphify：项目知识图谱
GitNexus：工程化代码智能平台

这篇文章不做花活，直接讲四件事：

1. 这四个项目分别是什么；
2. 基础怎么用；
3. 横向怎么比；
4. 能不能组合，如果能，怎么组合最稳。

先给结论，免得你看到最后才发现不适合自己。

先给简单选型答案

如果你只想要最简单的答案，可以先看这里。

只想让 AI Agent 少读代码、快点改代码：选 CodeGraph

主要痛点是 PR review、变更影响分析：选 code-review-graph

项目资料很多，代码之外还有文档、PDF、架构图、视频：选 Graphify

要做企业级代码智能平台、多仓库、API 影响分析：评估 GitNexus

再按角色说一遍：

普通开发者：CodeGraph
技术负责人 / Reviewer：code-review-graph
架构师 / 知识库场景：Graphify
平台团队 / 大型工程组织：GitNexus

如果你问我“普通项目里只选一个给 AI 编程 Agent 常驻”，我的答案还是：

先选 CodeGraph。

原因很简单：它够轻、够聚焦、工具面克制，最贴近日常编码里的高频需求：查符号、看调用链、找相关源码、分析影响范围。

但如果你的痛点不是“让 Agent 快点改代码”，而是“团队怎么做 PR 审查”“项目知识怎么沉淀”“多仓 API 改动怎么评估”，那答案就会变。

一、为什么 AI 编程 Agent 需要“代码地图”？

以前人理解项目，大概靠：

• README；
• 目录结构；
• IDE 跳转；
• 全局搜索；
• 老同事口口相传。

AI Agent 也差不多，只是它没有老同事，只能自己在仓库里翻。

于是经常出现这种情况：

Agent：我先 grep 一下 auth。
Agent：结果太多，我再 grep UserService。
Agent：我读一下这个文件。
Agent：不对，我再读另一个文件。
Agent：我猜这里应该是入口。

然后你就看见它把上下文窗口塞满了，但真正要改的点还没找到。

代码图谱工具想解决的是：

• 函数在哪里；
• 类继承谁；
• 谁调用了谁；
• 哪些文件属于同一个模块；
• 某个 API route 被谁消费；
• 改一个 symbol 会影响哪些流程；
• 新人应该按什么路径理解项目；
• PR 会影响哪些模块和测试。

这不是为了画一张漂亮大图，而是为了让 Agent 少走弯路。

以前 Agent 的工作流是：

grep → find → Read → 再 grep → 再 Read → 猜

接入图谱后，理想状态变成：

问图谱 → 拿到相关源码/符号/调用关系 → 再修改

这就是这些工具的核心价值。

二、CodeGraph：最适合常驻的代码导航地图

项目链接：

https://github.com/colbymchenry/codegraph

CodeGraph 的定位很清楚：

给 Claude Code、Codex、Cursor、OpenCode、Gemini、Antigravity 这类 AI 编程 Agent 一个本地代码索引，让它少 grep、少 Read、少浪费 token。

它不是一个项目知识库，不处理 PDF、视频、会议资料，也不强调 PR 审查流程。

它最关心的问题是：

Agent 要改代码时，能不能快速拿到正确上下文？

CodeGraph 怎么用？

官方推荐安装方式：

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh

# Windows PowerShell
irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 | iex

如果你已经有 Node/npm：

npm i -g @colbymchenry/codegraph

安装后连接 Agent：

codegraph install

进入项目后初始化并建图：

cd your-project
codegraph init -i

这里 -i 的意思是初始化后立刻索引。如果不加，也可以手动跑：

codegraph index

常用命令：

codegraph init [path]          # 初始化项目，创建 .codegraph/
codegraph index [path]         # 全量索引
codegraph sync [path]          # 增量同步
codegraph status [path]        # 查看索引状态
codegraph query <search>       # 搜索符号
codegraph files                # 查看项目文件结构
codegraph context <task>       # 为任务构造上下文
codegraph callers <symbol>     # 找调用方
codegraph callees <symbol>     # 找被调用方
codegraph impact <symbol>      # 分析变更影响
codegraph affected [files...]  # 找可能受影响的测试文件
codegraph serve --mcp          # 启动 MCP server

MCP 工具相对克制：

• codegraph_explore
• codegraph_search
• codegraph_node
• codegraph_callers
• codegraph_callees
• codegraph_impact
• codegraph_files
• codegraph_status

这里最重要的是 codegraph_explore。

它不是简单搜索一个字符串，而是尽量把 Agent 要完成某个任务时需要的相关源码、符号和关系一次组织好。

这点非常实用。

因为真实开发里，Agent 最常浪费的不是“写代码”，而是“找代码”。

CodeGraph 适合谁？

适合：

• 个人开发者；
• 小团队；
• 想给 Claude/Codex/Cursor 加一个常驻代码索引的人；
• 不想引入太重平台，只想让 Agent 更快读代码的人。

不太适合：

• 想处理 PDF、会议视频、架构图的人；
• 重点做 PR 审查流程的人；
• 要做多仓库企业级 contract impact 的团队。

我的判断：

CodeGraph 是这四个里最适合“先上手”的一个。

不是它功能最多，而是它最贴近日常高频问题。

三、code-review-graph：面向 PR 审查的风险地图

项目链接：

https://github.com/tirth8205/code-review-graph

code-review-graph 的核心标语是：

Stop burning tokens. Start reviewing smarter.

它和 CodeGraph 底层趋势很像：本地、Tree-sitter、SQLite、MCP、多语言。

但它的产品重心明显不一样。

CodeGraph 更像：

Agent 现在要改代码，先帮它找上下文。

code-review-graph 更像：

我已经有一批改动了，帮我分析影响范围和 review 风险。

code-review-graph 怎么用？

基础安装：

pip install code-review-graph
code-review-graph install
code-review-graph build

我个人更建议用隔离环境：

pipx install code-review-graph
# 或者按 MCP 配置走 uvx

安装后可以指定平台：

code-review-graph install --platform codex
code-review-graph install --platform cursor
code-review-graph install --platform claude-code
code-review-graph install --platform gemini-cli
code-review-graph install --platform kiro
code-review-graph install --platform copilot

常用命令：

code-review-graph build             # 全量构建图谱
code-review-graph update            # 增量更新，只解析变更文件
code-review-graph status            # 查看图谱统计
code-review-graph watch             # 文件变化后自动更新
code-review-graph visualize         # 生成交互式 HTML 图谱
code-review-graph wiki              # 根据社区结构生成 markdown wiki
code-review-graph detect-changes    # 风险评分 + 变更影响分析
code-review-graph register <path>   # 注册多仓库
code-review-graph daemon start      # 启动多仓库 watch daemon
code-review-graph serve             # 启动 MCP server

它的 MCP 工具很多，偏工具箱式。核心方向包括：

• 构建/更新图谱；
• 获取最小上下文；
• 影响半径分析；
• query graph；
• review context；
• 语义搜索；
• graph stats；
• detect changes；
• affected flows；
• architecture overview；
• community / hub / bridge nodes；
• wiki；
• refactor。

我最看重的是：

code-review-graph detect-changes

这个命令的场景非常清楚：

我改了一批代码，帮我看哪里可能炸。

它会围绕 diff 计算：

• 哪些函数/类被直接改；
• 哪些调用链可能受影响；
• 哪些测试可能覆盖不到；
• 哪些模块风险更高；
• review 应该优先看哪里。

这和 CodeGraph 的日常探索不同。它更像 reviewer 的辅助工具。

code-review-graph 适合谁？

适合：

• 有 PR review 流程的团队；
• 技术负责人；
• 想让 Agent 做 review 前先看影响范围的人；
• 想生成架构概览、社区结构、wiki 的项目。

不太适合：

• 只想要一个轻量常驻工具的人；
• 希望 Agent 每次改代码都只用一个主工具的人；
• 不想管理 Python CLI 环境的人。

我的判断：

如果 CodeGraph 是日常导航，code-review-graph 就是审查雷达。

它更适合接在“改完之后 / PR 之前”。

四、Graphify：把整个项目资料夹变成知识图谱

项目链接：

https://github.com/safishamsi/graphify

Graphify 很容易被误认为是另一个 CodeGraph。

但看完之后，我更愿意把它叫：

项目知识图谱工具。

它不是只看代码。它想把这些东西都放进同一张图里：

• 源码；
• SQL schema；
• Markdown；
• PDF；
• Office 文档；
• Google Docs；
• 图片；
• 音频；
• 视频；
• YouTube；
• PR 队列。

也就是说，它解决的问题不是：

Agent 怎么更快读代码？

而是：

Agent 怎么理解整个项目？

Graphify 怎么用？

注意，PyPI 包名是：

graphifyy

不是 graphify。

推荐安装：

uv tool install graphifyy

也可以：

pipx install graphifyy

安装后注册到 Agent：

graphify install

也可以指定平台：

graphify install --platform codex
graphify install --platform opencode
graphify install --platform cursor
graphify install --platform gemini
graphify install --platform claw
graphify install --platform hermes
graphify install --platform kimi

最常见用法：

/graphify .

或者命令行：

graphify extract .

它会输出：

graphify-out/
├── graph.html       # 交互式图谱
├── GRAPH_REPORT.md  # 报告：核心节点、意外连接、建议问题
└── graph.json       # 完整图谱，后续查询用

常用查询：

graphify query "show the auth flow"
graphify query "what connects DigestAuth to Response?"
graphify path "UserService" "DatabasePool"
graphify explain "RateLimiter"

导出架构页：

graphify export callflow-html

处理外部资料：

graphify add https://arxiv.org/abs/1706.03762
graphify add <youtube-url>

团队协作：

graphify hook install

Graphify 还鼓励把 graphify-out/ 提交进仓库：

一个人跑 /graphify .
提交 graphify-out/
其他人 pull 后，助手可以直接读图

这个思路和 CodeGraph 很不一样。

CodeGraph 更像本地索引服务。Graphify 更像项目知识产物。

Graphify 的最大价值

一个真实项目的知识并不只在代码里。

经常是这样：

代码：业务逻辑
SQL：数据模型
README / ADR：设计决策
PDF：方案、论文、竞品资料
图片：架构图、流程图、截图
视频/音频：会议、培训、需求讨论
PR：正在变化的未来状态

Graphify 的价值，就是把这些放进同一张图里。

如果你做的是 AI 产品、复杂业务平台、企业内部系统，它的价值会比纯 code search 更大。

不过也要注意风险。

代码 AST 可以本地抽取，但文档、图片、PDF、transcript 的语义抽取通常会走模型。这会带来：

• 成本；
• 数据出境；
• 隐私边界；
• 抽取质量稳定性。

所以在企业私有项目里用 Graphify，一定要认真配置 .graphifyignore，别把不该进模型的东西送出去。

Graphify 适合谁？

适合：

• 架构师；
• 技术负责人；
• 做项目知识库的人；
• 项目资料很多的团队；
• 需要 onboarding / 架构报告 / GraphRAG 的场景。

不太适合：

• 只想让 Agent 日常改代码快一点；
• 不想处理 LLM 抽取和隐私边界；
• 不想维护 graphify-out/ 产物。

我的判断：

Graphify 是这四个里最不像“纯代码工具”的一个，也是最适合做知识沉淀的一个。

五、GitNexus：更像企业级代码智能平台

项目链接：

https://github.com/abhigyanpatwari/GitNexus

GitNexus 是这几个里工程化味道最重的。

它不是只想做一个代码图谱，也不是只想提供几个 MCP tools。

它想做的是：

本地代码图谱 + MCP + CLI + HTTP bridge + Web UI + hooks + skills + wiki + multi-repo group

一句话：

GitNexus 更像 Agent 时代的代码理解基础设施。

不过，先说最关键的点：

GitNexus 的 License 是 PolyForm Noncommercial 1.0.0，不是 MIT。

这意味着个人研究、学习、非商业项目可以试；但如果要放进公司研发流程、商业项目或内部平台，必须认真看许可证，最好拿商业授权。

这点非常重要。

GitNexus 怎么用？

主线是 CLI + MCP。

在项目根目录：

npx gitnexus analyze

它会：

1. 扫描代码库；
2. 用 Tree-sitter 抽取函数、类、方法、调用、import、route、tool 等；
3. 构建本地知识图谱；
4. 写入项目里的 .gitnexus/；
5. 注册到 ~/.gitnexus/registry.json；
6. 可选生成 AGENTS.md、CLAUDE.md、skills；
7. 后续通过 MCP 给 Agent 调用。

配置 MCP：

npx gitnexus setup

或者启动 MCP：

gitnexus mcp

启动 Web UI 本地服务：

gitnexus serve

默认地址：

http://localhost:4747

常用命令：

gitnexus analyze [path]
gitnexus analyze --force
gitnexus analyze --embeddings
gitnexus analyze --skills
gitnexus analyze --index-only
gitnexus mcp
gitnexus serve
gitnexus list
gitnexus status
gitnexus doctor
gitnexus clean
gitnexus wiki [path]
gitnexus query "auth flow"
gitnexus context UserService
gitnexus impact createUser
gitnexus detect-changes
gitnexus cypher "MATCH ..."

多仓库 group：

gitnexus group create platform
gitnexus group add platform backend/api backend-repo
gitnexus group add platform frontend/web frontend-repo
gitnexus group sync platform
gitnexus group query platform "auth flow"
gitnexus group impact platform
gitnexus group contracts platform

GitNexus 的核心能力

GitNexus 的 ingestion pipeline 很完整，有 12 个阶段：

scan
  → structure
  → [markdown, cobol]
  → parse
  → [routes, tools, orm]
  → crossFile
  → mro
  → communities
  → processes

它不只是抽函数和调用，还关心：

• API route；
• tool handler；
• ORM query；
• cross-file 类型传播；
• 方法重写；
• functional communities；
• execution flows；
• multi-repo contract。

MCP tools 也非常完整：

• list_repos
• query
• context
• impact
• detect_changes
• rename
• cypher
• route_map
• tool_map
• shape_check
• api_impact
• group_list
• group_sync

我最看重三个：

detect_changes：分析当前 git diff 影响哪些流程
api_impact：修改 API route 前看 consumer 和 response 字段依赖
shape_check：检查 API 返回 shape 和 consumer 访问字段是否匹配

如果你做前后端分离项目，api_impact 和 shape_check 很有吸引力。

很多 bug 不是代码逻辑错，而是后端字段改了，前端还在读旧结构。

GitNexus 试图把这种风险提前暴露出来。

GitNexus 适合谁？

适合：

• 平台团队；
• 大型工程组织；
• 多仓库系统；
• 前后端分离复杂项目；
• 想做企业内部代码智能平台的人。

不太适合：

• 想要轻量常驻工具的人；
• 不想处理 native dependency / Node / LadybugDB / embedding 的人；
• 商业场景但没有许可证授权的人。

我的判断：

GitNexus 是这四个里最像“平台”的一个，但也是最重、最需要认真评估 license 的一个。

六、四个项目横向对比

先看一张总表。

再用更口语的话讲一遍。

CodeGraph：先解决高频问题

高频问题是：

Agent 不知道该读哪些代码。

CodeGraph 的答案是：

别先 grep，先 explore。

它不追求什么都做，而是让 Agent 更快拿到相关代码上下文。

code-review-graph：让 review 更聪明

它解决的是：

这次改动到底影响哪些地方？review 应该先看哪里？

如果你们团队 PR 多、review 压力大，它比 CodeGraph 更对症。

Graphify：代码之外也要纳入图谱

它解决的是：

项目知识不只在代码里。

如果你的项目有大量文档、方案、PDF、架构图、会议视频，Graphify 的价值就出来了。

GitNexus：工程关系平台化

它解决的是：

一个复杂工程组织里，代码、API、工具、多仓库之间的影响怎么管理？

它是最像平台的，但也不是随手就该上的。

七、能不能组合使用？

能。

但我不建议一上来四个全上。

更准确地说：

可以组合，但不要把四套工具都同时暴露给同一个 Agent 常驻。

原因很现实：

• MCP 工具太多，Agent 会选择困难；
• 上下文噪音变大；
• 多套索引维护成本高；
• 同一个问题可能被不同工具重复回答；
• 图谱结果可能口径不一致。

最稳的原则是：

一个常驻工具 + 一个按需工具

常驻工具负责高频开发，按需工具负责特定场景。

下面给几个组合方案。

组合方案一：轻量开发组合

CodeGraph + Graphify

适合：

• 个人开发者；
• 小团队；
• 想让 Agent 日常改代码快一点；
• 又想偶尔生成项目知识图谱。

用法：

CodeGraph 常驻 MCP
Graphify 按需运行

平时：

codegraph init -i
codegraph install

让 Agent 用 CodeGraph 查代码、找调用链、构造上下文。

需要做项目梳理时：

/graphify .

或者：

graphify extract .

生成：

graphify-out/graph.html
graphify-out/GRAPH_REPORT.md
graphify-out/graph.json

这套组合很舒服。

CodeGraph 管日常效率，Graphify 管阶段性知识沉淀。

推荐指数：高。

组合方案二：代码审查组合

CodeGraph + code-review-graph

适合：

• 有 PR review 流程的团队；
• 改动风险比较高的项目；
• 想让 Agent 平时能改代码，PR 前又能审风险。

用法：

CodeGraph 常驻 MCP
code-review-graph 用于 review / detect-changes

平时开发：

codegraph explore / query / impact

PR 前：

code-review-graph detect-changes
code-review-graph get_review_context

这套组合的分工很清楚：

CodeGraph：帮 Agent 找代码
code-review-graph：帮 Reviewer 看风险

推荐指数：中高。

如果团队已经有比较严肃的 review 流程，这套会很实用。

组合方案三：知识沉淀组合

code-review-graph + Graphify

适合：

• 技术负责人；
• 架构师；
• 想同时做代码审查和项目知识库的人。

用法：

code-review-graph 看代码改动风险
Graphify 做项目知识图谱和报告

它不一定适合 Agent 常驻编码，但适合阶段性做：

• 架构复盘；
• 项目体检；
• onboarding；
• PR 质量分析；
• 技术债梳理。

推荐指数：中。

这更像管理/架构场景，不是普通开发者第一选择。

组合方案四：企业平台组合

GitNexus + Graphify

适合：

• 大项目；
• 多仓库；
• 有平台团队；
• 有内部代码智能平台诉求；
• 既要工程关系，也要知识沉淀。

分工：

GitNexus 管代码工程关系、API impact、多仓 contract
Graphify 管文档、PDF、图片、视频、项目知识图谱

这套组合最强，但也最重。

尤其 GitNexus 有非商业许可证限制，商业项目里必须先处理授权问题。

推荐指数：视团队成熟度而定。

我不会建议小团队一上来就这么玩。

组合方案五：四个都上，可以吗？

理论上可以。

但我不建议。

除非你有明确的平台团队，愿意维护：

• 多套索引；
• 多套 MCP 配置；
• Agent 工具选择策略；
• 文档同步；
• 隐私边界；
• CI 更新流程；
• 商业授权。

否则四个都上，大概率变成：

每个都很强
但没人真正稳定使用

更好的路线是渐进式增加。

八、推荐的渐进式路线

我建议按痛点逐步来。

第一阶段：先上 CodeGraph

如果你还没有任何代码图谱工具，先从 CodeGraph 开始。

原因：

• 安装使用相对简单；
• 目标非常聚焦；
• 常驻 MCP 价值明显；
• MIT license；
• 不需要先建立复杂流程。

先验证一个问题：

Agent 是否真的少读文件、少 grep、更快找到代码？

如果这个问题都没改善，后面上更重的工具意义不大。

第二阶段：PR 痛点明显，加 code-review-graph

如果你发现：

• PR 经常改漏；
• reviewer 压力大；
• 影响范围难判断；
• 测试覆盖不清楚；
• AI review 经常泛泛而谈；

再加 code-review-graph。

让它服务 review，而不是替代 CodeGraph。

第三阶段：资料很多，加 Graphify

如果你的项目知识散落在：

• README；
• ADR；
• PDF；
• 竞品分析；
• 架构图；
• 会议视频；
• 需求文档；

那 Graphify 就有用了。

它不是为了高频改代码，而是为了让项目知识能被看见、被查询、被沉淀。

第四阶段：多仓库/平台化，再评估 GitNexus

如果你已经到了：

• 多 repo；
• 多服务；
• 前后端 contract；
• API impact；
• 企业内部平台；
• 自动 wiki；
• Agent hooks；
• 代码智能统一入口；

再评估 GitNexus。

但一定先看 license。

这是硬前提。

九、按场景快速选择

场景 1：我就是想让 Claude/Codex 改代码更靠谱

选：

CodeGraph

理由：轻、准、常驻友好。

场景 2：我有一堆 PR，review 看不过来

选：

code-review-graph

或者：

CodeGraph + code-review-graph

理由：一个服务日常编码，一个服务审查。

场景 3：我要给新人讲项目架构

选：

Graphify

理由：GRAPH_REPORT.md、graph.html、项目知识图谱更适合 onboarding。

场景 4：我有很多非代码资料

选：

Graphify

理由：代码之外的 PDF、图片、视频、文档，是 Graphify 的主场。

场景 5：我有前后端分离和 API shape 风险

选：

GitNexus

前提：license 没问题。

理由：api_impact、shape_check、route_map 很对症。

场景 6：我有多仓库系统

选：

GitNexus

或先轻量尝试：

CodeGraph 单仓常驻 + GitNexus 小范围评估

理由：GitNexus 的 group / contract bridge 更适合多仓影响分析。

场景 7：公司不能接受非商业 license

避开：

GitNexus OSS 直接商用

优先：

CodeGraph / code-review-graph / Graphify

或者联系 GitNexus 商业授权。

十、不要忽略这些坑

1. Code Graph 不是编译器

这些工具都很强，但不要把它们当绝对真理。

动态语言、框架魔法、反射、运行时注入、宏、模板、高阶函数，都会影响静态分析准确率。

图谱是地图，不是地形本身。

2. MCP 工具越多，不一定越好

Agent 不是人。

你给它 30 个工具，它未必会更聪明，反而可能不知道该用哪个。

所以常驻工具要克制。

我更喜欢：

CodeGraph 常驻
其他工具按需

3. 图谱需要更新

代码在变，图谱也要变。

如果索引 stale，Agent 基于旧图谱做判断，可能比不用还糟。

所以要注意：

• watch；
• sync；
• git hook；
• CI 更新；
• stale index 提示。

4. 文档/图片/PDF 的隐私边界要管

Graphify 这类工具一旦处理非代码资料，尤其要小心。

.graphifyignore 不是装饰品。

商业合同、客户数据、内部会议纪要、密钥截图，这些东西不要随手丢给 LLM 语义抽取。

5. License 不能后补

尤其 GitNexus。

非商业 license 不是“等用起来再说”的小事。

如果你要进公司流程，先问法务/采购/负责人。

十一、我的最终推荐

如果只给一个默认路线，我会这么走：

先上 CodeGraph
PR review 有痛点，再加 code-review-graph
项目资料很多，再加 Graphify
企业平台、多仓、API contract，再评估 GitNexus

不要一开始追求全家桶。

真正有效的工具链，不是看起来最豪华，而是每个工具都有清楚分工。

四个项目最后可以这样记：

CodeGraph 解决：Agent 怎么读代码
code-review-graph 解决：PR 改动有没有风险
Graphify 解决：项目知识怎么沉淀
GitNexus 解决：企业工程关系怎么平台化

如果你是个人开发者，先别纠结太久，直接试 CodeGraph。

如果你是团队负责人，看看 code-review-graph 能不能放进 PR 流程。

如果你是架构师，Graphify 可能比纯代码索引更有价值。

如果你在做企业内部 AI coding 平台，GitNexus 值得认真拆，但 license 和复杂度要先算清楚。

最后一句话：

AI Agent 不缺写代码的能力，它缺的是看清项目的地图。

这四个工具，本质上就是四种地图。

选哪一张，取决于你现在到底迷路在哪里。

相关链接

• CodeGraph：https://github.com/colbymchenry/codegraph
• code-review-graph：https://github.com/tirth8205/code-review-graph
• Graphify：https://github.com/safishamsi/graphify
• GitNexus：https://github.com/abhigyanpatwari/GitNexus

补充阅读：

• MCP：https://modelcontextprotocol.io/
• Tree-sitter：https://tree-sitter.github.io/tree-sitter/
• GraphRAG 概念：https://microsoft.github.io/graphrag/