当大语言模型刚刚崭露头角之际，RAG（检索增强生成）几乎成了行业内的“救命稻草”。那时，模型的上下文窗口极为有限，而RAG恰好帮助我们模拟了记忆功能。坦白说，最初我也是RAG的坚定拥趸，亲手搭建过多套主流开源RAG系统，也为那些高速成长的AI公司优化过检索流程。
然而，现在必须承认——尤其是在构建能够像资深工程师一样自主编写代码的智能体这件事上，你应该离RAG远一点。
为什么？因为质量才是决定成败的关键。
如果你的首要目标是压缩成本，想尽办法榨干每一Token的价值，那RAG或许还算得上一项可选方案。将代码库切割成小块、进行嵌入计算、计算余弦相似度、再辅以重排序，挑选出最匹配的片段——Cursor、Windsurf等公司正是这样做的，也确实借此做成了生意。
但如果你追求的是顶级质量，希望打造一个能真正理解并编写复杂代码的智能体，那么RAG就像一个黑洞——它会吞噬你的资源、时间，还会严重削弱模型的推理能力。
Aman Sanger（Cursor联合创始人）曾指出：“代码库中最难的难题和查询，往往需要多步推理。传统的检索只能应对单一环节。”别再迷信RAG：尤其在构建自主编程智能体时请三思
如果你正在搭建编程智能体，请慎重考虑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在某些领域依然能发光发热——比如客服机器人、文档问答、通用知识记忆等。但如果你认真对待，想要构建一个高性能的自主编程智能体，建议你退一步，从一个完全不同的角度来审视这个问题。
与其构建那些需要你永远维护、并且会混淆智能体判断力的系统，不如从尽可能地移除开始。移除所有不必要的脚手架，别挡着那些旗舰大模型的道。
去构建记忆，构建工具。给你的智能体那些真实工程师会使用的便利设施。然后，让它们像人一样去工作。
我们终于走到了模型有能力做到这一步的阶段，那就让它们去做吧。
