为什么堆上下文窗口救不了 AI Agent 处理大仓库的效率？

最近在尝试用 Claude Code 处理一个中等规模的 monorepo 项目，虽然它在几万行的小项目里如鱼得水，但一旦规模稍微上去，痛点就非常明显。最典型的场景是：当你尝试 refactor 一个核心函数时，Agent 会在后台疯狂执行 grep 和 git log。因为它在第一次加载时虽然扫过文件列表，但由于缺乏结构化的索引，它必须通过反复的碎片化查询来确认调用链路。结果就是 token 消耗极快，响应延迟明显增加，这种体验让我想起早年间在没有索引的数据库里做全表扫描。

其实问题的根源不在于模型本身的推理能力，而在于喂给 Agent 的“上下文”缺乏结构。一个典型的 Git 仓库本质上就是一张巨大的知识图谱，里面记录了文件的变更历史、提交记录以及模块间的依赖关系。但目前的 Agent 逻辑大多是“线性读取”，它们把代码库当成一堆文本文件，而不是一个有向图。在这种逻辑下，单纯地把上下文窗口从 128K 堆到 200K 甚至更高，其实是在用暴力美学解决工程问题，效率极低。

这时候 OpenAI 关注 Git for large repositories 的方向就显得非常有前瞻性。我认为真正的突破口不在于替代 Git，而在于构建一层高效的“预索引层”。理想的状态应该是：将仓库的目录结构、符号引用（Symbol Reference）以及提交历史全部向量化或图结构化。当 Agent 接收到指令时，它不再是从头开始啃代码，而是通过这层索引按需拉取最相关的片段。这与目前市面上很多通过 RAG（检索增强生成）强行喂数据的插件有本质区别，因为代码的逻辑依赖是强耦合的，简单的向量检索经常会丢失关键的上下文链路。

当然，要把这套逻辑在超大规模仓库中跑通，挑战极大。首先是 Git 的分布式特性，每个 clone 都是一个完整的历史副本，这导致索引的同步和实时性很难处理。其次是那些极易导致 Agent 崩溃的边缘情况，比如复杂的 submodule 嵌套、巨大的二进制文件，以及那些动辄数万行的 legacy 文件。大仓库的复杂度不是线性的，而是一张纵横交错的关系网，如果索引层不能精准处理这些非线性关系，Agent 依然会在复杂的依赖链中迷路。

目前看来，无论是 Claude Code 还是 Copilot，在处理超大规模代码库时的策略仍然偏向于“实时搜索+缓存”。如果 OpenAI 能从系统层面将 Git 仓库的图结构直接集成到推理引擎中，那么 Agent 处理大项目的成本将大幅降低。比起继续追求更大的上下文窗口，这种从仓库根源入手、构建结构化索引的路径，才是让 AI Agent 真正具备“工程能力”的关键。