别再迷信RAG了，尤其在构建自主编程这件事上

别再迷信RAG了，尤其在构建自主编程这件事上

在大型语言模型（LLM）应用的初期，RAG（检索增强生成）就像一根救命稻草。那时，大模型的上下文窗口还没那么大，RAG帮我们模拟了记忆。我甚至也曾是RAG的早期拥趸，构建过流行的开源RAG系统，还帮那些高速增长的AI公司优化过它们的检索系统。

但现在，我得说，尤其在构建能像资深工程师那样自主编程的智能体这件事上，你应该离RAG远一点。

为什么？因为质量至关重要。

如果你追求的是低成本，想方设法压缩token用量来盈利，那RAG或许还能派上用场。把代码库切块、嵌入、算算余弦相似度，或许再加个重排序，挑出最匹配的几个片段——Cursor、Windsurf这些公司就是这么做的，也确实做成了生意。

但如果你追求的是顶级质量，想要打造一个能真正理解并编写复杂代码的智能体，那么RAG就是一个黑洞，它会吞噬你的资源、时间，并且严重拖累模型的推理能力。

Aman Sanger (Cursor 联合创始人)说过：“代码库里那些最难的问题和查询，往往需要好几步推理。传统的检索只能应付一步。”

如果你在构建编程智能体，请三思RAG

我曾帮助许多快速发展的AI公司优化RAG流程，带来了实打实的收入增长。我也写过不少文章分享其中的门道。但即便如此，我还是要告诉你：RAG是个无底洞。你可以无休止地投入资源、时间和才华，换来的可能只是边际上的微小改进。如果你的产品确实离不开RAG，这或许值得。

但对于自主编程智能体而言，RAG是一个巨大的干扰，不仅对你的团队是干扰，对智能体本身也是。

Quinn Slack (Sourcegraph CEO) 也曾指出：“行业里大部分人其实从未真正做好过RAG……99%的RAG实践甚至都没做过像样的切块处理，或者用严谨的方式进行过评估……而现在，我们早已过了RAG就足够的那个阶段了。”

RAG的叙事有一种奇怪的蛊惑性，像一种“思想病毒”。似乎人们在2022年脑子里装进了RAG，然后就试图把它硬塞进所有东西里，期望它能让事情变得更好。恰恰相反，它是个巨大的风险，会误导你的模型，用一堆杂乱无章的代码片段稀释它们的判断力。

我曾与一家大型企业的潜在客户开会。他们正在评估不同的编程智能体，想看看哪一个最适合他们的工程师团队。这是一家严肃的公司，拥有数千名工程师，但他们的决策过程却出奇地天真。他们似乎只是想要一个功能清单，而RAG是他们非常执着的一项。当我问他们为什么如此看重RAG时，他们只是说：“我不知道，它对大型代码库不是很好吗？”

想想看，一个资深工程师加入团队，打开一个庞大的代码库时，他们会怎么做？他们不会去读一堆孤立的代码片段。他们会浏览文件夹结构，查看文件，分析导入关系，然后再深入阅读更多的文件。

这才是你的编程智能体需要复制的思维模式，而不是一个由高维向量聚类的、精神分裂般的代码片段构成的思维导图。

优秀的编程智能体应该像人一样自然地探索代码库

Cline是市面上最昂贵的编程智能体之一。但它阅读代码的方式就像一个真正的人：遍历文件夹树，分析导入关系，解析抽象语法树（AST），并据此判断下一步该去哪里。Cline依赖大量的上下文，它是主动的（Agentic），也是昂贵的。但这就是智能的代价。检索是被动的；自主是主动的。

Ty Dunn (Continue 创始人) 也提到：“构建一个能即时自动判断哪些上下文是相关的系统非常困难……而且RAG可能需要大量你必须永远维护的集成。”

随着Claude Sonnet 3.5，乃至更新模型的出现，上下文窗口的大小和推理能力已经不再是瓶颈了。上下文的质量才是。

所以在Cline，我们给了智能体一个真实工程师所拥有的一切工具，然后让它去自由探索。

Shridhar Belagatti 在谈到Cline的自主记忆系统时写道：“忘掉RAG吧。像MCP这样的新架构，能够实现更自主、上下文感知更强、更高效的工作流。”

RAG并未消亡，但它用错了地方——至少在编程上是这样

RAG在某些领域依然能发光发热——比如客服机器人、文档问答、通用知识记忆等。但如果你是认真的，想要构建一个高性能的自主编程智能体，我建议你退一步，从一个完全不同的角度来审视这个问题。

与其构建那些你需要永远维护、并且会混淆智能体判断力的系统，不如从尽可能地移除开始。移除所有不必要的脚手架，别挡着那些旗舰大模型的道。

去构建记忆，构建工具。给你的智能体那些真实工程师会使用的便利设施。然后，让它们像人一样去工作。

我们终于走到了模型有能力做到这一步的阶段了，那就让它们去做吧。