代码知识图谱工具预先从仓库中抽取节点和关系，供 Agent 查询符号、依赖和调用路径。这样可以减少目录遍历和全文检索，但三个工具处理的输入、关系来源和查询方式并不相同。
本文比较三个公开项目：
- CodeGraph：本地预索引代码图谱和 MCP 服务。
- GitNexus：为编码 Agent 提供结构检索、影响分析和执行流查询。
- Graphify：把代码及相关文档、媒体材料抽取为可查询知识图谱。
三种产品任务
三者都生成图，但图在系统里的角色不同。
| 工具 | 主要任务 | 图的角色 | 适合的问题 |
|---|---|---|---|
| CodeGraph | 减少 Agent 在代码库里的逐文件探索 | 本地代码结构索引 | 某个符号在哪里、谁调用它、改动会涉及哪些代码 |
| GitNexus | 为重构、调试和接口变更准备可行动的上下文 | Agent 的结构检索与影响分析后端 | 调用链如何连通、一个接口变化可能波及哪里、路由由谁处理 |
| Graphify | 将代码和项目材料组织为关系网络 | 可版本化的知识地图 | 某个模块与文档中的设计理由如何关联、哪些材料共同描述一个概念 |
CodeGraph 和 GitNexus 以代码为主要输入。Graphify 还可以处理 Markdown、PDF、Office 文档、图片和音视频转写文本。三者覆盖的语料不同，不能只比较“图谱能力”。
PR 评审需要补哪些测试、哪些调用方需要检查时，GitNexus 的影响分析更接近这个任务。需要同时查找认证模块的代码、架构决策和会议材料时，Graphify 更合适。需要在本地向 MCP 客户端提供函数、类、导入和调用关系时，CodeGraph 的部署和输入范围更小。
比较维度
语言数量、MCP 工具数量和 GitHub Star 无法说明工具是否适合一个具体仓库。比较时需要回答六个问题：
- 任务边界：它在减少什么成本，帮助谁做什么决策？
- 图如何生产：节点和边来自 AST、类型索引、规则、启发式还是 LLM？
- 图如何查询：查询时是图遍历、关键字检索、向量检索、Cypher，还是让 LLM 自己读文件？
- LLM 在哪里参与：参与建图、检索排序、摘要，还是仅负责调用工具并组织回答？
- 准确性边界：哪些关系是源码直接事实，哪些是推断；漏边时系统是否提示？
- 如何维护：索引存在哪里，代码变更后怎么更新，图和原始代码是否可能不一致？
图中关系的正确性只构成候选上下文的一部分。Agent 的回答还取决于查询选择、结果解释和未被图覆盖的信息；最终改动还取决于实现、构建、测试、审查和运行时验证。图谱可以减少无关文件进入上下文，但不能替代这些验证步骤。
图从哪里来
CodeGraph：AST 抽取与关系解析
CodeGraph 将项目索引保存在 .codegraph/codegraph.db 中。它从 Tree-sitter 解析得到函数、类、方法、导入和调用表达式等结构，再将能够解析的引用连接到定义。它还实现了框架路由、回调、接口实现等规则，以及部分跨语言桥接。
图中边的证据强度并不相同。AST 可以直接抽取 import、函数声明和调用表达式。调用表达式对应哪个定义，尤其是跨文件、成员调用或多态调用时，还要解析导入、作用域、接收者类型或命名模式。CodeGraph 的边记录包含 provenance 与可扩展的 metadata。非 AST 直接抽取的关系只能作为候选路径。
CodeGraph 还提供 Rust 解析内核和可选的语言索引路径。它们可以改善覆盖和性能，却不意味着对反射、依赖注入容器、运行时拼接、代码生成或未索引依赖具备完整调用图。
参考：CodeGraph README、数据库 schema、关系解析实现。
GitNexus：将解析结果组织为任务查询
GitNexus 使用 Tree-sitter 解析代码，并处理跨文件符号、继承、依赖注入、路由、工具调用、模块社区和执行流。结果写入每个仓库的 .gitnexus/，由嵌入式 LadybugDB 保存。
查询层因此可以直接提供 context、impact、route_map、api_impact 等面向任务的操作，而不是只提供“读一个节点”或“执行一段查询”。执行流作为图中的 process 信息，可通过上下文查询和资源接口获取。它也支持 Cypher，但 Cypher 只是接口的一部分。
GitNexus 将 BM25、向量语义检索和 Reciprocal Rank Fusion 组合为混合检索。向量检索用于寻找名称不同但语义相关的候选实体；调用路径和影响范围仍通过图边遍历获得。跳过 embedding 后，混合检索不再包含语义向量分支。符号和文本候选仍可由 FTS/BM25 获得，但对名称差异较大、主要依赖语义相近性的查询，召回效果需要单独测试。
参考：GitNexus 架构文档、混合搜索实现。
Graphify：代码与项目材料使用不同抽取路径
Graphify 的代码路径使用 Tree-sitter 本地抽取。它会输出 graph.json、HTML 图谱和报告，并提供 query、path、explain 等局部图查询能力。代码调用关系存在二次推断过程，因此直接调用和跨文件推断不应被混为同一类证据。
Graphify 可以将 PDF、文档、图片和音视频转写文本放入同一张图。文件读取、文本提取、OCR 与转写能否离线运行取决于具体配置。语义关系抽取、摘要和概念对齐可能调用 Agent 或模型后端。代码 AST 路径可以离线运行；处理混合材料时，需要分别评估提取服务和模型调用的成本、数据流向与结果稳定性。
它将边分为 EXTRACTED、INFERRED 和 AMBIGUOUS：EXTRACTED 来自原始材料中的显式内容；INFERRED 是系统给出的合理推断，并附带置信分数；AMBIGUOUS 表示系统无法可靠判定、需要人工复核的关系。这一标记适合用于决定何时回源核实，而不表示某条边的统计正确率。
参考：Graphify 工作原理、Graphify 架构与置信度标签、隐私说明。
查询接口与返回结果
三者都可以通过 MCP 被 Agent 调用。比较时应关注调用返回的对象和查询原语，而非 MCP 本身。
| 查询层 | CodeGraph | GitNexus | Graphify |
|---|---|---|---|
| 数据访问接口 | CLI 与 MCP | CLI、MCP 与 HTTP | CLI、graph.json 与可选 MCP 服务 |
| 查询原语 | 符号、邻居、调用方、被调用方、路径 | 图遍历、FTS/BM25、可选向量检索和 Cypher | 节点、邻居、局部子图和最短路径 |
| 任务封装 | 符号探索与 impact | context、impact、route_map、api_impact | query、path、explain |
| 对 Agent 的主要价值 | 缩小需要阅读的代码范围 | 在重构或排障前给出候选依赖和调用链 | 将代码和相关材料限制在一个局部子图 |
MCP 工具数量不能直接比较。直接执行 Cypher 的接口覆盖范围较广，但调用方需要理解图模型。impact 这类接口封装了查询策略，也限定了工具内部采用的关系和范围。评估时应记录完成真实任务所需的调用次数、返回是否包含来源和限制，以及 Agent 能否据此找到正确源码。
LLM 的参与位置
“本地运行”不等于“不调用模型”。需要区分产品内部是否默认依赖模型，以及外部 Agent 如何将查询结果写成自然语言回答。
| 产品内部阶段 | CodeGraph | GitNexus | Graphify |
|---|---|---|---|
| 代码建图 | 默认不以 LLM 为必要条件 | 默认不以 LLM 为必要条件 | 默认不以 LLM 为必要条件 |
| 非代码材料 | 不是核心输入路径 | wiki 等可选能力可调用模型 | 语义抽取可调用模型；文本提取、OCR、转写需按配置核验 |
| 检索排序 | 图和全文索引 | 图与 BM25 为基础；向量检索可选 | 以本文快照的局部图查询为主；额外接入语义检索时应单独记录 |
三者经 MCP 调用时，最终的自然语言回答都由外部 Agent 或客户端决定。GitNexus 的 Web 端可以引入其自身的 Agent 编排；Graphify 的 Skill 只负责引导调用路径，并不自行生成回答。
因此，Graphify 的“纯代码建图无需 API Key”成立，但不能据此描述为“所有输入都不会离开本机”。GitNexus 的主索引流程无需生成式模型，也不代表启用远程 embedding、Web 服务或 wiki 后仍然没有外部数据流。CodeGraph 的索引可本地完成，但遥测、升级下载和 Agent 本身使用的模型仍是独立的数据边界。
对企业部署，应该分别登记：原始代码、索引数据库、向量、查询日志、MCP HTTP 服务和模型请求各自保存在哪里、保留多久、由谁访问。
关系证据与准确性边界
文本搜索用于查找包含某个词的材料，图谱用于在已建模关系中查找调用方、依赖路径或邻居。两者解决的问题不同。图谱结果是否可用，取决于关系如何产生。
关系可以按证据强度区分：
| 级别 | 关系来源 | 例子 | 使用建议 |
|---|---|---|---|
| A | 编译器或语义索引 | 有定义与引用绑定的语言索引结果 | 适合高置信导航和重命名候选；多态、反射、生成代码和运行配置仍需结合构建与运行证据核验 |
| B | AST 显式抽取 | import、函数声明、调用表达式 | 适合导航和初步核验；调用点不等于调用目标已经绑定 |
| C | 规则或启发式推断 | 跨文件调用目标、成员调用、DI、框架路由、回调 | 作为候选范围，回源代码确认 |
| D | LLM 语义推断 | PDF 中概念关系、材料摘要、设计意图关联 | 不能作为代码改动或安全结论的唯一依据 |
GitNexus 在未能确定 receiver 类型时会将某些影响分析标为 lower-bound，含义是“已返回的结果只是已知下界，实际影响可能更大”。Graphify 的 AMBIGUOUS 有类似用途。这样的提示应进入 Agent 的工作流：结果为空不等于没有调用方，低置信或下界结果不应自动用于删除代码、跳过测试或批准发布。
CodeGraph、GitNexus 和 Graphify 的公开 issue 都包含解析遗漏、别名解析失败、同名符号误绑定、增量索引陈旧等问题。这不是某个项目独有的缺陷，而是静态分析面对动态语言和工程约定时的共同边界。
索引更新与共享方式
图谱与源码版本不一致时，查询结果可能过期。三个工具的维护方式不同。
| 维度 | CodeGraph | GitNexus | Graphify |
|---|---|---|---|
| 默认存储 | .codegraph/codegraph.db | .gitnexus/ 中的图数据库 | graphify-out/graph.json 和报告 |
| 更新方式 | watcher 与 scoped sync | 检测仓库版本后重新分析 | --update、watch 或 Git hook |
| 索引服务共享 | 本地服务或共享索引策略 | 本地 registry、服务化或企业部署 | 本地 CLI 或共享 MCP 服务 |
| 图工件版本控制 | 需按数据库和索引策略设计 | 需按索引和服务部署策略设计 | 工件可复现、体积可控且不含敏感材料时，可纳入版本控制；否则作为 CI 产物或受控文件保存 |
| 常见风险 | watcher 失效、文件系统锁、局部更新未覆盖全局关系 | 大仓构建资源、embedding 成本、索引滞后 | 混合语料模型成本、增量图一致性、图文件体积 |
CodeGraph 以常驻 watcher 和文件级更新为中心。GitNexus 关注仓库索引、MCP 服务和多仓库查询；增量能力与大仓资源都需要按目标版本实测。Graphify 更像版本化的地图工件：团队可以把输出提交到 Git，但要额外处理图文件合并和更新时机。
验收时应要求查询结果或其元数据能关联到索引对应的 commit、工作树状态和构建时间；工具不提供时，可在索引封装层补充这些元数据。CI 或开发流程还应保留全量重建与差异检查的兜底路径。
不能直接比较的指标
语言数量
“支持 30 种语言”可能只表示能识别文件，也可能表示能抽取结构节点、解析跨文件引用、理解类型或识别框架约定。只识别文件时，调用图可能仍然很少。比较时应按目标语言和框架列出能力，而不是比较总数。
Token 节省倍数
Token 节省通常来自项目自己的任务集、模型、提示词、缓存状态和统计口径。一次建图消耗的时间、内存和模型成本也不应遗漏。更合理的指标是：同一模型、同一任务集、相同工具权限下，完成任务的成功率、工具调用数、输入 token、实际耗时和人工复核时间。
“完全本地”
本地 AST 解析只描述其中一个阶段。远程 embedding、LLM API、HTTP MCP 服务、遥测和提交到仓库的图文件都可能带来新的数据面。安全评估应根据实际配置，而不是产品口号。
日常开发中的分工
三种工具进入同一条开发流程后，差异会体现在使用时机上。
进入陌生模块时，通常需要找到入口、确认符号的定义和调用方，再阅读少量关键文件。这个阶段主要需要代码导航。CodeGraph 可以作为 Agent 的默认代码索引：先用图谱确定需要读哪些文件，再回到源码确认实现细节。它减少的是目录遍历、grep 和重复读取，不能替代源码阅读。
改动接口、拆分模块或处理跨目录问题时，需要确认还有哪些调用方、消费者和测试需要检查。GitNexus 的 impact、context、路由和 API 查询可以先给出候选范围。可以在写代码前用它补齐阅读范围，在发起 review 前用它检查 diff 是否遗漏关联模块和测试。lower-bound、未解析 receiver 和动态调用边界仍需通过代码和测试确认。
Graphify 不需要进入每一次代码修改流程。适用场景是代码库已经积累了架构说明、ADR、接口文档、会议记录或演示材料，并且这些材料需要与代码一起查找。它可以帮助定位模块的设计依据和相关资料，不能证明某个调用在运行时一定发生。纯代码仓库只使用 Graphify 的代码路径时，混合材料能力不会参与；处理混合材料前还需确认材料是否允许进入模型处理链路。
日常流程可以按下表分工：
| 开发阶段 | 优先使用 | 作用 | 仍需保留的验证 |
|---|---|---|---|
| 熟悉仓库、定位符号 | CodeGraph | 缩小阅读范围，找到定义、调用方和相邻代码 | 阅读源码，确认调用目标与当前索引一致 |
| 重构、排障、接口变更 | GitNexus | 汇总候选影响范围、调用路径、路由和消费者 | 检查动态调用、未解析关系，运行针对性测试 |
| 架构理解、交接、跨材料检索 | Graphify | 将代码与设计材料收敛到同一组概念和关系 | 回看原始文档和源码，核对推断关系 |
不宜同时让三个 MCP 承担默认代码搜索。这样会让 Agent 对同一个问题获得重复但格式不同的结果，也会增加工具选择的不确定性。可以确定一个默认代码导航入口：偏向符号和调用定位时使用 CodeGraph，偏向影响分析时使用 GitNexus。需要关联非代码材料时再使用 Graphify。
接入前的检查
这些建议以目标语言、模块系统和关键框架模式能够被正确解析为前提。首次接入时，可用仓库中发生过的任务检查以下问题：
- 对一个已知调用链，工具是否找到关键调用点和目标定义；对跨文件、成员调用、DI 或框架路由，遗漏会出现在哪里。
- 修改一个接口或入口函数后，影响分析是否至少覆盖人工评审认为必须检查的模块和测试；结果为空时是否明确提示索引陈旧或召回下界。
- 修改代码后，索引是否更新；旧边是否残留；watcher、hook 或手动重建失败时是否可见。
- 模型、embedding、查询日志、图文件和 MCP 服务分别在哪里运行；许可证、依赖来源和文件访问权限是否满足团队要求。
这些检查用于确认工具能否进入当前仓库的日常流程。代码图谱的覆盖会随语言、框架约定和仓库结构变化。未通过这些检查时，图谱结果不应参与高风险改动的判断。
三者也可以组合，但组合前先明确责任：例如 GitNexus 负责代码变更影响候选，Graphify 负责代码与设计材料的关联，而正式接口契约、运行手册和发布结论仍由版本化文档、测试和运行数据承担。
代码知识图谱可以将代码阅读起点和需要核验的关系整理为结构化查询。带有源码位置和明确提取证据的结构事实可以快速回源核验。推断边、空结果和低置信结果不能单独用于删除代码、批准发布或做安全判断。图谱不能替代源码阅读、类型检查、测试、代码审查和运行时观测。
