PR 明明只改了几行，代码 Agent 还没开始判断有没有 bug，就先把一大堆文件塞进上下文。等它终于查清楚调用关系，上下文预算已经用掉一截。

我拿 httpx 做了次实测。准备交给 Agent 的上下文从 13666 tokens 降到 632 tokens，少了约 95%。

这种浪费其实很隐蔽。问题是，Agent 一开始根本不知道哪些文件相关，只能先在仓库里来回搜索，顺着调用关系把相关代码和单测一点点找出来。上下文看起来越来越满，真正用来判断 bug 的空间反而越来越少。

更大的上下文窗口解决不了这个问题，得先改变 Agent 读取代码的顺序。

以前 Agent 会先搜仓库、读文件，再逐步确认调用关系。现在我让它从 diff 开始，先确认可能受影响的函数，再读取调用链上的代码和单测。这样一来，它不用为了理清调用关系打开太多文件。

7 月 22 日登上 GitHub Trending 的 tirth8205/code-review-graph，做的就是这件事。它先在本地建立代码关系图。拿到 diff 后，图谱会找到改动函数和它的调用者，让 Agent 先读这些位置。

安装后执行 code-review-graph install 写入 MCP 配置。

配置生效后，我给 httpx 仓库建图，再用一个小 diff 跑了次检测。这次只改了一个处理 URL 结尾斜杠的函数。图谱先确认被改的是哪个函数，再顺着调用关系查到两个直接调用者。Agent 可以先读这三处代码，需要时再往外查，不用一开始就把这个函数所在的整个文件都打开。

如果按 git grep 搜改动函数，会连带命中它所在的整个文件。把这个文件完整交给 Agent，要占 13666 tokens。图谱返回的结果只有 632 tokens，少了约 95%。

仓库和依赖都准备好后，从建图、准备 diff 到看懂输出，大约需要 8 到 10 分钟。工具从建图到返回结果不到 12 秒。

小仓库用 grep 可能已经够了；大仓的首次索引时间要另算，调用图也可能漏掉动态调用。这里的 95% 只是跟前面的 grep 做法比出来的，不能直接套到其他项目上。

这张图值不值得建，我主要看以后还能不能反复用。中大型仓库如果经常有 PR 要审，同一张图可以反复使用；一次性脚本和小仓库，直接 grep 就够了。

我用图谱缩小 Agent 要读的范围，代码有没有问题，还是看源码和单测结果。

下次 Agent 又准备把整个仓库都读一遍时，先别急着加上下文。先问一句：

这次改动，到底影响谁？