GitNexus 核心引擎深度解析
索引流水线、社区检测与流程追踪、混合搜索与嵌入生成
架构概览
GitNexus 的核心引擎设计得很巧妙,主要由三个相互协作的子系统构成:索引流水线(Ingestion Pipeline)、社区与流程检测(Community & Process Detection)、混合搜索与嵌入(Hybrid Search & Embeddings)。这三个部分协同工作,将原始代码库一步步转换为可查询的知识图谱。
1.1 核心类关系图

1.2 关键数据结构
KnowledgeGraph:这是知识图谱的核心容器,管理着节点和关系集合。节点类型涵盖了 File、Folder、Function、Class、Method、Interface、Community、Process;关系类型则包括 CALLS、IMPORTS、EXTENDS、IMPLEMENTS、MEMBER_OF、STEP_IN_PROCESS。
SymbolTable:符号表,用于快速定位符号定义。键值对形式为 filePath:name,值为 {nodeId, type}。
ASTCache:AST 缓存机制,避免重复解析带来的性能损耗。采用 LRU 策略,默认缓存所有文件。
索引流水线详解
索引流水线是引擎的心脏,负责将代码库转换为知识图谱。整个流程大致可以拆分为 9 个阶段,每个阶段都有明确的职责和进度反馈。

阶段拆解:
- 文件扫描(0-15%):通过
walkRepository遍历文件系统,收集所有可解析的文件,并建立 File/Folder 节点。 - AST 解析(30-70%):利用 Tree-sitter 进行并行解析,提取符号定义。这里使用了 Worker 池来并行处理,如果失败会自动降级为顺序处理,保证稳定性。
- 导入解析(70-75%):针对不同语言实现感知解析。TypeScript/JavaScript 支持相对路径和 node_modules;Go 支持包路径解析;Python 支持相对导入和 sys.path。
- 调用解析(75-80%):通过 Tree-sitter 查询匹配函数调用点,建立 CALLS 关系。置信度计算基于精确匹配(名称 + 参数数量)、模糊匹配(仅名称)或全局匹配(未解析标识符)。
- 社区检测(85-90%):使用 Leiden 算法基于 CALLS 边进行功能聚类。构建无向 Graphology 图,运行 Leiden 算法(resolution=1.0),生成社区节点和成员关系。





