代码库不是文档库：三大核心区别与正确用法

上一节我们讨论了Agent在已知信息中进行语义压缩的方法。现在要面对一个更具挑战的场景——当Agent遇上陌生的代码库、未知的合同文本或数亿行事故日志时，它无法预知关键信息的位置，必须自行探索。

这种策略被称为“渐进发现”（Progressive Discovery），然而它做出的首个判断就足以让我们重新评估RAG系统。至少我在研读完这部分内容后，对RAG的适用边界有了截然不同的认识。

一、代码库绝非文档仓库

某电商系统偶尔会误发订单确认邮件，其中夹杂了其他客户的订单信息。团队先后尝试了三种排查方案。

首先尝试将整个代码库（15000个文件）一次性注入Agent——Token额度迅速耗尽。随后将代码切分成100段并行输入，每段均反馈“未发现bug”。接着改用RAG语义检索——召回结果全是与“订单”“邮件”语义接近的内容，但真正引发问题的变量名为merge_user_state，注释中并未出现order或email，语义检索完全失准。

最终采用grep + read方案：搜索send.*confirm，获得30个候选文件，从中筛选出5个可能性最高的，逐一阅读后梳理出调用链MailerWorker → Cache.get_user → render。进一步阅读Cache.get_user，发现缓存键使用了order_id而非customer_id——Bug定位成功。前后仅四轮探索，消耗约18K Token。

该Bug与语义无关，根源在于代码结构。 关键信息往往隐藏在变量命名、调用链路、缓存键设计、配置文件以及测试路径中，而非语义相似度所能覆盖。

二、Forage / Focus / Deepen：三阶段循环机制

渐进探索的工程框架正是这一三阶段循环，其理论基础源于Pirolli与Card在1999年提出的信息觅食理论（Information Foraging Theory）。

动物觅食并非将整个森林翻遍，而是先进行广域扫描，发现食物聚集区（斑块），然后集中深挖，直到该区域资源耗尽再转移至下一个斑块。这一模型最初应用于人类信息检索领域，如今再次被迁移至Agent系统设计中。

广扫阶段借助低成本工具（grep / glob / find）快速获取候选集；聚焦阶段从候选集中选取5-10个文件完整阅读，构建局部理解；深挖阶段则沿着可疑的调用链逐层追查，直至找到信号最强的异常链路。

每个阶段均配备量化判断指标：广扫阶段关注information_gain（单次搜索获取的信号量），聚焦阶段评估patch_quality（哪个区域最值得深入），深挖阶段衡量marginal_value（额外投入1000 Token后是否仍能获得新线索）。这三个指标将Agent的探索决策从“凭经验直觉”升级为“有计算依据”。

这套机制与操作系统调度器的工作集理论几乎同构：先探索出有效的工作集（working set），再对该工作集进行精读分析。

三、Agentic Search颠覆了RAG的传统认知

Claude Code的创始人Boris Cherny曾公开表示：agentic search generally works better（Agent式搜索通常表现更优）。

这句话直接撼动了业界对Agent上下文的默认假设——此前普遍认为“长上下文装不下就用RAG”是不二法则，OpenAI、Pinecone、LangChain等整个生态体系都在沿着该方向推进。然而最常用的Coding Agent却站出来指出：此路不通。

然而grep + read并非终极方案。Augment Code将Context Engine构建为工业级代码索引系统：支持400K文件、45秒增量更新以及跨仓库依赖追踪。

这两条路径并非对立关系。Boris强调“generally works better”中的“generally”一词本身就暗示并非绝对。核心决策应依据代码库规模进行划分：5K文件以内，agentic search足以应对；50K至400K文件则需要代码库索引支撑；超过400K文件且涉及跨仓库场景，持久化索引成为必需品。Cursor所采用的混合路线才是工业级解决方案：小规模代码库现场探索，大规模代码库依赖索引兜底。

四、Sub-Agent隔离深挖策略

最后一条关键的工程纪律是：深挖过程绝不能污染主Agent的上下文环境。

长期运行的Agent主上下文相当于主进程。探索过程中产生的中间垃圾会不断堆积，最终令真正有价值的信息被淹没。更合理的做法是将深挖工作隔离到Sub-Agent或独立的search worker中，主Agent仅接收压缩后的发现与证据链。

这与服务端架构中“主进程不承担重活，重活交由worker/sidecar/沙箱处理”的工程纪律完全同构。如今，DeepAgents的subagents.py、DeerFlow的schema化Action，本质上均是在实施探索过程的命名空间隔离。

另一个核心判断是：满意决策（satisficing）而非最优化（optimizing）。探索的目标并非寻求理论上的全局最优，而是在有限时间与有限Token预算内找到一个足够好的解。Herbert Simon早已提出的原则——边际收益是否仍能覆盖边际成本——在Agent时代重新彰显其价值。