GitHub开源Graphify爆红：仓库变图谱，不靠向量

这组数据来自项目团队的内部评测，样本只有 6 道问题，还不足以证明 Graphify 在所有代码任务中都更好。但它提出了一种值得关注的技术路线：当 Coding Agent 面对大型仓库时，能否提前把函数、类、模块以及它们之间的关系组织起来，让 Agent 直接查询依赖，而不是每次都从搜索文件开始？

Graphify 就在尝试解决这个问题。它通过 Tree-sitter 解析源代码，把调用、导入、继承等关系组织成知识图谱，支持沿关系查找代码、追踪节点路径，并保留关系的来源信息。代码结构提取可以在本地完成，不必调用大模型，也不要求先搭建向量数据库。

代码找到了，Coding Agent 为什么还是改不对？

让 Coding Agent 修改一个函数并不复杂，难的是确认这次修改会影响哪些地方。以订单取消功能为例，开发者可能只要求调整一个接口，但这项操作背后涉及支付退款、库存恢复、优惠券状态、订单事件以及相关测试。某个模块的代码可以很快找到，与它存在关系的其他模块却未必能一次定位。

目前，Claude Code、Codex、Cursor 等开发工具已经具备较强的代码搜索能力。它们可以使用 grep 查找符号、读取文件、查询定义和引用，再根据搜索结果继续追踪其他函数。但大型项目的调用关系往往跨越多个文件，Agent 找到一个函数后，还需要判断下一步应该检查哪里。每多一层依赖，就可能增加一轮工具调用和上下文读取。

向量检索能够缓解部分问题。系统将代码切分成 Chunk，通过 Embedding 找到与当前问题语义接近的内容。对于名称不明确、需要根据自然语言查找业务逻辑的任务，这种方式很有用。不过， 两个函数在语义上相似，并不代表它们存在调用关系；真正相关的下游模块，也不一定与目标函数具有较高的文本相似度。

代码本身其实已经包含大量结构信息。函数调用了哪些方法、模块导入了哪些对象、类继承了哪些父类，这些关系就存在于源码中。传统检索通常在需要时才去寻找这些信息，而 Graphify 尝试提前完成结构提取，形成一份能够持续查询的代码关系图。

这样一来，Agent 处理复杂任务时，可以先从目标函数出发，沿着图查找相关模块，再选择需要深入阅读的文件。它依然需要理解代码、执行测试，但不必完全依赖一次次关键词搜索来发现关系。

不用 LLM 读代码，Graphify 如何构建知识图谱？

Graphify 的核心建立在 Tree-sitter 和 AST（抽象语法树）之上。与普通文本切分不同，AST 保留了代码的语法结构。例如，解析 Python 文件时，可以识别类定义、函数定义、方法调用和导入语句，再将这些内容转换为具有明确类型的节点与连接关系。项目目前支持约 40 种编程语言的相关解析能力，不同语言的支持深度有所区别。

图1｜Graphify 对 FastAPI 代码仓库生成的知识图谱，不同颜色代表识别出的代码社区。来源：Graphify 官方。

官方架构将建图过程组织为一条流水线：detect → extract → build → cluster → analyze → report → export。系统先扫描文件并判断类型，提取节点与边，再通过 NetworkX 建立图结构，完成社区发现和关系分析，最后生成报告与可查询的数据文件。开发者不需要为这一流程额外部署 Neo4j 或其他独立图数据库。

在数据结构上，Graphify 将代码对象表示为 Node，将对象之间的联系表示为 Edge。节点通常带有名称、标识符、源文件路径和代码位置；边则记录起点、终点、关系类型和可信度。例如，OrderService.cancel_order() 调用 PaymentService.refund()，可以在图中表达为一条 calls 关系。不过，跨文件调用目标并不总能直接从 AST 中确定，还需要符号解析和关联处理。

Graphify 为此设计了三类关系标签：EXTRACTED、INFERRED 和 AMBIGUOUS。EXTRACTED 表示源码明确包含相应关系，如直接导入或可识别的调用；INFERRED 表示经过进一步解析得出的关系，例如跨文件调用解析；AMBIGUOUS 则表示关系仍存在不确定性，需要检查。 这里的 INFERRED 不一定来自 LLM，也可能来自静态分析中的第二轮解析。

图2｜Graphify 跨仓库知识图谱界面，展示节点、关系及来源统计。来源：Graphify 官方。

这种区分很重要。假设 Agent 要分析某个公共接口的修改影响，直接提取的调用关系可以成为优先检查的线索，推断关系则需要进一步核对源码。Graphify 还会识别图中高度连接的节点，并通过 Leiden 等社区发现方法寻找联系紧密的模块。对于大型仓库，这有助于先定位相关子系统，再进入具体函数，而不用直接面对整张图。

建图完成后，项目默认提供三个主要文件：graph.json 保存图结构，graph.html 用于交互式浏览，GRAPH_REPORT.md 则汇总关键节点、社区和值得检查的关系。代码部分可以完全在本地解析；设计文档、PDF、图片等非结构化内容如果需要语义抽取，则可能调用配置的模型。Graphify 将它们接入同一张图，但不同数据类型的提取方式并不相同。

从 FastAPI 到 APIRouter，Agent 如何沿着图找到代码关系？

Graphify 官方使用 FastAPI 代码库展示了图查询能力。项目并没有停留在生成一张可视化关系图，而是提供 query、path、explain 三类查询命令，供开发者和 Coding Agent 从不同角度访问图数据。三种查询使用的是已建立的知识图谱，不需要每次重新解析整个仓库。

其中，graphify explain “APIRouter” 是一个比较直观的例子。官方展示的结果显示，APIRouter 位于 routing.py 第 2210 行，属于编号为 2 的图社区，Degree 为 47，也就是该节点在图中有 47 条关联连接。结果还列出了与它相连的对象，包括 RequestValidationError、Dependant、.get() 方法及相关导入文件。

值得注意的是，这些连接并没有被当成完全相同的事实。Graphify 将 APIRouter 与部分对象之间的 uses 关系标记为 INFERRED，而方法或导入关系中包含 EXTRACTED 标记。这让开发者不仅能看到 APIRouter 与谁有关，还能判断哪些关系需要进一步核对。对于需要修改基础路由逻辑的 Agent，这些节点可以成为后续检查的入口。

另一个例子是 graphify path “FastAPI” “ModelField”。官方结果展示了一条三跳路径：FastAPI → DefaultPlaceholder ← get_request_handler() → ModelField，其中包含 uses 和 references 等关系。这类查询适合帮助开发者定位两个代码概念之间的连接。但图中的最短路径只是已识别关系上的连接，并不等于运行时真实执行的调用顺序，更不能直接当成完整调用链。

如果开发者不知道具体节点名称，还可以使用 graphify query 根据问题获取相关子图。查询支持 BFS、DFS 和预算控制，例如优先查看附近节点，或者沿着某条依赖链深入。这里有一个容易被忽略的细节：Graphify 当前 CLI 的查询匹配主要依靠节点名称的词项匹配与 IDF，而不是任意自然语言都能直接进行语义理解。官方 Skill 会尝试根据图中的实际词汇扩展问题，再执行遍历。

Graphify 还提供 Skill 与 MCP 接口，可以接入 Claude Code、Cursor、Codex 等工具。Agent 获得相关子图以后，能够继续读取对应文件、检查实现逻辑和运行测试。图查询在这里承担的是定位关系与提供上下文的工作，代码判断和修改仍然需要后续工具配合。

不用向量索引，Graphify 与传统 RAG 的区别在哪里？

Graphify 最容易引起关注的描述是「不用向量数据库」。不过，这里的关键并不只是省掉 Embedding 成本，而是代码关系的组织方式不同。

传统向量 RAG 主要依据语义相似度寻找内容。比如开发者问「哪里实现了用户请求限流」，向量检索可以在没有明确函数名的情况下，尝试定位相关代码。Graphify 的优势则更多体现在已经存在明确结构关系的场景，例如某个函数被哪些模块调用、一个类继承了哪些对象、两个模块之间如何通过导入与引用连接。

两者解决的问题存在差异。向量检索关注哪些代码与问题在语义上相近，结构化图检索则可以沿着已经提取的关系查找连接。对于「修改这个函数可能影响什么」一类问题，图遍历通常具有更直接的表达方式，因为调用、导入和继承本身就是代码中的关系信息。

与部分基于 LLM 的 GraphRAG 方案相比，Graphify 在代码建图阶段也采用了不同的方法。自然语言文档中的实体和关系往往需要模型抽取，代码则有相对明确的语法规则。Tree-sitter 可以直接获得大量结构信息，Graphify 再通过静态解析补充跨文件关系。这样既减少了代码建图对 LLM 的依赖，也让关系能够关联到具体的源码位置。

不过，不使用向量索引并不代表它能替代所有检索工具。动态调用、反射、依赖注入、运行时配置以及跨服务消息通信，都可能让静态图出现缺口。对于需求描述模糊、变量命名不直观、需要理解大量业务文档的场景，文本搜索和语义检索依然有价值。Graphify 官方的部分长期记忆 Benchmark 也采用了本地 Embedding 与混合检索，不能把所有成绩都归因于纯图遍历 。

更合理的应用方式是让 Coding Agent 按任务选择检索工具：已知符号时使用 grep 或 LSP，模糊需求使用语义搜索，跨文件依赖使用图查询，找到候选范围后再通过源码和测试验证。Graphify 的价值在于补充一类过去需要 Agent 多轮搜索才能拼接出的关系信息。

百万行代码实测提升 11.2 个百分点，Graphify 能走多远？

Graphify 官方公布的 ERPNext 测试提供了一个观察这种技术路线的窗口。ERPNext 是一个约百万行代码规模的生产级 ERP 项目。测试给固定 Coding Agent 提供 grep、read_file、list_dir 等基础工具，再分别增加不同的代码检索工具，让 Agent 回答跨文件的技术问题，最多执行 14 轮。

在这组测试中，纯 grep/read 基线的关键事实覆盖率为 70.8%，加入 Graphify 后达到 82.0%。其他配置中，codebase_memory 为 80.5%，CodeGraphContext 为 79.2%，基于语义搜索的 claude_context 为 79.1%。Graphify 取得了其中最高的覆盖率，但它相对其他结构化检索方案的优势并不悬殊。

图3｜Graphify Cloud 工作空间总览，集中展示多个仓库的图谱与构建状态。来源：Graphify 官方。

成本数据同样值得关注。团队披露的结果显示，Graphify 配置的 Token 消耗约为 grep/read 基线的 1.3 倍，单次任务模型费用约为 0.320 美元，基线约为 0.322 美元。这说明 Graphify 并没有在该测试中降低总 Token 消耗，而是在费用基本持平的情况下提高了回答覆盖率。相比每轮打包整个仓库上下文的 Repomix 配置，它则消耗了明显更少的 Token。

团队还在 FastAPI 示例代码上进行过一次跨文件 INFERRED 关系的人工检查。官方记录显示，2026 年 10 月 5 日的一次 AST-only 提取中，纳入检查的 12 条生产代码跨文件推断关系均被判断为正确。不过，这只是一组限定范围的人工检查，无法证明所有语言、所有仓库的推断关系都具有同样的准确性。

现有数据也有明确限制。ERPNext 的主测试只有 6 道问题，衡量的是回答中覆盖多少预设关键事实，并非真实 PR 的代码修改成功率。对企业团队来说，还需要验证其他指标：Agent 是否减少了漏改的调用点、能否更快定位问题、图谱更新是否及时，以及最终测试通过率有没有改善。Graphify 已提供增量更新和文件监控能力，但频繁提交的大型仓库依然需要管理图谱版本与代码版本的一致性。

Graphify 代表的技术方向值得继续观察。Coding Agent 已经能够阅读和修改大量代码，但在复杂仓库中，它仍然需要可靠的方法确定代码之间的联系。Graphify 选择先从源码中提取可以验证的结构关系，再把这些关系作为 Agent 的检索入口。

这并不会让 Agent 自动理解整个系统，也无法覆盖所有运行时行为。它提供了一种更有针对性的上下文获取方式：面对大型代码库，Agent 可以先沿着已经建立的关系寻找相关代码，再决定读取什么、修改哪里、验证哪些影响。

未来 Coding Agent 的代码理解能力，除了取决于模型本身，也可能越来越取决于它如何组织和使用代码仓库中的结构信息。Graphify 展示了其中一条具体的工程路线。

参考来源

Graphify 官方 GitHub 仓库

Graphify 官方技术架构 ARCHITECTURE.md

Graphify 官方 Benchmark 报告

ERPNext 跨工具测试及费用明细

Graphify Query / Path / Explain 官方实现说明

点个在看你最好看

SPRING HAS ARRIVED