rag系列文章目录
目录
[一、GitNexus 与 Graphify简介](#一、GitNexus 与 Graphify简介)
[1.1 Graphify:代码结构导航工具](#1.1 Graphify:代码结构导航工具)
[1.2 GitNexus:AI Agent 的代码神经系统](#1.2 GitNexus:AI Agent 的代码神经系统)
[2.1 Graphify架构](#2.1 Graphify架构)
[2.2 GitNexus架构](#2.2 GitNexus架构)
[第一阶段:Repository Scanner](#第一阶段:Repository Scanner)
前言
随着 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。