当"侦探"遇见"图书管理员"：Agentic Search与RAG的和解之路

读完这篇对Claude Code团队技术选型的深度剖析，我有一种似曾相识的感觉——这让我想起了当年"NoSQL将取代SQL"的狂热宣言。事实证明，关系数据库和文档数据库各有适用场景，最终走向了融合而非取代。Agentic Search与RAG的关系，很可能也会沿着相似的轨迹演进。

一个被忽略的问题：规模的天平

文章详细论述了RAG在大型、高频更新代码库中的困境，但较少讨论反向场景：当知识库相对静态、检索频率极高时，Agentic Search的效率劣势会被无限放大。

想象一个日处理百万次查询的文档问答系统。每次查询都让LLM进行多轮工具调用，即使每次成本只有0.01美元，日运营成本也将高达万美元级别。相比之下，向量检索的成本几乎可以忽略不计。

这里的关键洞察是：Agentic Search的"优雅"是有代价的，而这个代价在规模化的生产环境中可能无法承受。

结构化 vs 非结构化：问题域的边界

文章准确指出了代码的特殊性——语义边界清晰、格式严格。但我想补充一个更微妙的观点：代码的"可导航性"不仅来自其结构化，更来自其"可执行性"。

当Claude Code使用grep搜索时，它不是在模糊匹配语义，而是在搜索精确的标识符——这些标识符在运行时会被编译器验证。这种"可验证性"是代码领域的独特优势，但在自然语言文档中并不存在。

PageIndex尝试用层级索引结构来弥补这一差距，但其98.7%的FinanceBench准确率背后，是金融文档本身具有相对规范的章节结构。真正"野性"的长文档——比如一份散乱的企业内部知识库——可能连构建索引的起点都难以找到。

一个务实的预测：混合架构的未来

与其将Agentic Search和RAG视为非此即彼的替代关系，我更倾向于认为它们将形成分层协作的架构：

这种"漏斗式"架构已经在一些前沿系统中出现：先用便宜的向量检索过滤掉90%的无关内容，再让Agentic Search在剩余10%的高价值候选中进行深度探索。

对"透明度"的反直觉思考

文章将Agentic Search的"可追溯性"列为核心优势，但我持保留意见。当模型进行10轮工具调用后，人类审查者真的能理解每一步的意图吗？

相比之下，一个设计良好的RAG系统可以明确告诉你："这个答案基于文档A的第3节和文档B的第7节"。这种答案级别的可解释性，在合规审计场景下可能比"过程透明"更有价值。

结语

Claude Code团队的技术选择无疑是正确的——对于他们的场景。但将这种选择推广为"RAG已死"的结论，可能为时过早。

就像SQL和NoSQL最终在NewSQL中找到和解，Agentic Search和RAG也很可能在未来走向融合。真正的智慧，不在于选择哪一方，而在于理解每方的边界，并在合适的场景下做出合适的组合。

毕竟，优秀的工程师既需要侦探的探索精神，也需要图书管理员的系统思维。