rag系列文章目录

---

目录

rag系列文章目录

前言

一、GitNexus 与 Graphify简介

1.1 Graphify：代码结构导航工具

1.2 GitNexus：AI Agent 的代码神经系统

二、基本原理

2.1 Graphify架构

第一层：AST解析

第二层：关系构建

第三层：图谱生成

第四层：图遍历查询

2.2 GitNexus架构

第一阶段：Repository Scanner

第二阶段：AST解析

第三阶段：关系推导

第四阶段：社区发现

第五阶段：执行流分析

第六阶段：MCP能力层

三、两者对比与适用场景

Graphify适用场景

GitNexus适用场景

总结

---

---

前言

随着 Claude Code、Cursor、Codex 等 AI 编程助手的普及，一个新的问题逐渐暴露出来：

AI 能写代码，但不一定理解整个代码库。

当项目规模达到数十万行代码时，仅靠向量检索（RAG）或文件搜索（grep）已经难以让 AI 建立完整的上下文认知。因此，GitNexus 和 Graphify 这类基于知识图谱（Knowledge Graph）的工具开始受到关注。

虽然两者都构建代码知识图谱，但定位和目标并不相同。

一、GitNexus 与 Graphify简介

1.1 Graphify：代码结构导航工具

Graphify 的核心理念是：

Navigate by Structure, Not Similarity

即：

不要通过相似度理解代码
而要通过结构关系理解代码

传统 RAG 的工作方式：

代码
 ↓
Embedding
 ↓
Vector DB
 ↓
Similarity Search

例如搜索：

支付流程

可能返回：

PaymentService.java
PaymentController.java

但无法告诉你：

PaymentController
   ↓
PaymentService
   ↓
CardValidator
   ↓
Gateway

之间的完整调用链。

Graphify认为：

代码最重要的不是文本相似度，而是依赖关系。

因此它将代码转换为知识图谱，通过图遍历（Graph Traversal）而不是向量检索来帮助 AI 理解代码结构。简单来说：

Graphify = RepoMap + Code Graph + Visualization

目标是：

让人和AI快速看懂项目

1.2 GitNexus：AI Agent 的代码神经系统

GitNexus 提出的理念更加激进：

Give AI Agents a Nervous System

作者认为：

AI Agent 最大的问题不是不会写代码。

而是：

不知道改动会影响谁
不知道业务流程如何传播
不知道依赖链在哪里

例如：修改：

UserService.validate()

Agent 很可能：

修改成功
单元测试通过

但实际上：

47个调用方
12个模块依赖
支付流程受到影响

最终导致线上故障。

GitNexus认为：

AI缺少的是结构化上下文，而不是代码能力。

因此它不仅构建图谱，还直接提供：

Impact Analysis
Refactoring
Rename
Dependency Query
Change Detection

等能力。

简单理解：

GitNexus = Knowledge Graph + MCP Server + Impact Analysis

目标是：

让Agent真正理解整个系统

二、基本原理

2.1 Graphify架构

第一层：AST解析

Graphify使用 Tree-sitter 解析代码。

提取：

Class
Function
Method
Import
Interface

等结构化信息。

例如：

OrderController

会被识别为：

Node: Class

而：

orderService.submit()

会被识别为：

Edge: CALLS

---

第二层：关系构建

建立：

CALLS
IMPORTS
EXTENDS
IMPLEMENTS
USES

等关系。

形成：

OrderController
      ↓
OrderService
      ↓
PaymentService

这样的依赖网络。

---

第三层：图谱生成

生成：

graph.json

保存全部知识图谱。

同时生成：

graph.html

用于可视化浏览。

以及：

GRAPH_REPORT.md

用于自动分析项目结构。

---

第四层：图遍历查询

用户查询：

支付流程

Graphify直接从图中寻找：

Controller
↓
Service
↓
Repository

的执行路径。

而不是进行Embedding搜索。

---

2.2 GitNexus架构

GitNexus架构比Graphify复杂得多。

---

第一阶段：Repository Scanner

扫描整个仓库：

Java
Python
Go
TypeScript

等代码。

---

第二阶段：AST解析

同样基于Tree-sitter：

Class
Method
Function
Import

全部提取。

---

第三阶段：关系推导

构建：

CALLS
IMPORTS
EXTENDS
IMPLEMENTS
USES

关系。

形成代码图谱。

---

第四阶段：社区发现

GitNexus增加了一个关键步骤：

Leiden Community Detection

自动发现：

支付模块
订单模块
认证模块

等业务聚类。

这一步是Graphify相对缺失的。

---

第五阶段：执行流分析

分析：

HTTP Request
 ↓
Controller
 ↓
Service
 ↓
Repository

形成业务流程图。

例如：

创建订单流程
支付流程
退款流程

都可以被自动识别。

---

第六阶段：MCP能力层

这是GitNexus最大的特色。

向Claude Code暴露：

impact()
context()
rename()
query()
cypher()
detect_changes()

等工具。

例如：

impact(UserService.validate)

直接返回：

调用方
影响范围
风险等级

无需Agent自己遍历代码。

三、两者对比与适用场景

维度	Graphify	GitNexus
核心目标	项目理解	Agent增强
主要用户	开发者	AI Agent
图谱构建	是	是
可视化	强	一般
MCP支持	弱	强
Impact Analysis	弱	强
重构支持	无	有
图查询	基础	高级
Agent Workflow	辅助	核心

Graphify适用场景

场景1：接手遗留项目

例如：

20万行SpringBoot项目
没人维护
文档缺失

Graphify能够快速生成：

graph.html

帮助开发者理解：

模块关系
调用链
依赖结构

---

场景2：架构分析

例如：

系统耦合度分析
模块边界分析
依赖关系分析

Graphify非常适合。

---

场景3：知识沉淀

生成：

GRAPH_REPORT.md

可以作为团队架构文档。

GitNexus适用场景

场景1：Claude Code长期维护项目

例如：

Claude Code
+
大型Java项目

GitNexus能够提供：

impact()
context()
rename()

能力。显著提升AI修改代码的准确率。

---

场景2：大规模重构

例如：

接口改名
DTO变更
方法迁移

GitNexus可以自动分析影响范围。避免遗漏。

---

场景3：Agent自主开发

未来Agent模式：

需求
 ↓
分析
 ↓
修改
 ↓
测试
 ↓
提交

GitNexus更适合作为底层基础设施。

总结

• 如果目标是理解项目架构、梳理依赖关系，优先选择 Graphify；
• 如果目标是提升 Claude Code、Cursor 等 AI Agent 的开发能力，优先选择 GitNexus；
• 如果条件允许，两者结合使用效果最好：Graphify负责“看懂”，GitNexus负责“干活”。

我个人觉得graphify可以用于知识库构建，将沉睡的位于设计文档中的业务知识复活。而gitnexus最大的用处是代码影响分析，以及bm25检索代替grep。