让编程 Agent 看懂仓库依赖关系

让 AI 编程 Agent 修复单个文件里的 bug，大多数工具都能处理得不错。但如果让它追查：为什么修改支付服务中的一个函数，会导致隔着三个微服务的地方出问题，很多工具就会悄无声息地失灵。它们能读代码，但要理解整个代码库如何协同运作，理解其中的关系、依赖，以及深入三个文件之后才看到的某段古怪变通代码为什么存在，就是另一个难度高得多的问题了。业界开始将解决这一问题的一整套方法称为 repository intelligence（代码库智能）。

简要回答：代码库智能是一组技术，包括向量嵌入、AST（抽象语法树）解析和知识图谱，让 AI 编程 Agent 能够理解整个代码库的结构、依赖和关系，而不只是当前打开的文件。到 2026 年，大多数成熟工具都会结合使用其中至少两种方法。研究表明，与逐个文件探索代码库的 Agent 相比，基于图的索引可以将 token 用量降至原来的约十分之一。

为什么“换个更大的上下文窗口”解决不了问题

一个听上去很直接的办法，是把整个代码库塞进模型的上下文窗口。但这会遇到上下文工程中讨论过的同一个问题：原始文本更多，并不意味着理解得更好。上下文窗口可以装下大型代码库的文本，但装下文本，不等于理解哪些函数调用了哪些函数、修改一个共享类型会破坏什么，或者某段看起来奇怪的代码为什么会因为几个月前发生的事情而存在。这是结构问题，不是容量问题，需要从结构上解决。

工具真正建立这种理解的三种方式

2026 年，大多数代码库智能系统都会组合使用以下三种技术。每一种都能捕捉到其他技术遗漏的信息。

向量嵌入会将代码片段转换为数值表示，再检索出与 Agent 当前任务在语义上最相近的片段。这是最早出现、也最常见的方法，本质上是将检索增强生成应用于源代码，而非文档。即使措辞不同，它也擅长找到概念上相关的代码。

AST 解析的工作方式不同。它不会把代码当作待搜索的文本，而是将代码解析为实际的语法结构，包括函数、类、调用和继承关系。这样，工具就知道某个片段是一个完整函数，而不是随意截取的一段文本。一个简单的例子就能说明区别：假设某个函数先调用 getUser()，再检查 verified 标志，最后调用 stripe.charge()，具备 AST 感知能力的工具知道，这三个调用在结构上相互关联，属于同一个整体。普通文本搜索看到的，则只是恰好挨在一起的三行独立文本。

知识图谱更进一步，会将这些结构化输出转化为一张明确的关系图：用节点表示文件、函数和类，用边表示调用、导入和引用关系。这样，Agent 就能沿着依赖链追踪多个文件，而不必每次都重新阅读所有文件。一个采用这种方式为 31 个真实代码仓库建立索引的研究系统，为 Django 构建了包含约 49,000 个节点和 196,000 条边的图，并在大约三分钟内，为整个 Linux 内核建立了索引，规模约为 210 万个节点。

这是一个精简版本。完整文章还介绍了基于图的索引在实际使用中能节省哪些开销，Cursor、Augment Code 和 Sourcegraph Cody 有何不同，以及在相信工具的宣传之前应该检查什么。完整文章刊载于 NextGentech-official。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。