架构未来，你来不来？
这两年做过 RAG 的团队，大多经历过同一个落差。
演示时，文档切块、生成 Embedding、召回 Top-k，模型很快就能答得像模像样。接进业务以后，麻烦才露出来：制度已经改了，索引还没更新；明明知道函数名，语义搜索却带回一堆“意思相近”的代码；答案引用了一份旧文档，看着合理，却没人敢据此修改订单状态。
“向量数据库已死，Claude Code、Cursor 集体抛弃 RAG”因此听上去很顺，也确实说中了不少项目的难处。
我重新查了这几条说法的出处，结论没有这么整齐。Claude Code、Cursor 和关键词搜索论文，讲的是三个不同条件下的选择。
Claude Code 的早期版本试过现成的 RAG，后来改为让 Agent 用 glob、grep 等工具查找文件。负责人 Boris Cherny 在访谈中说，Agentic Search “领先很多”。他也很坦率，这个看法主要来自团队内部的使用感受，外加一些内部基准，并不是一组公开的严格对照实验。
Cursor 走的是另一条路。它在 2025 年 11 月公布了一组实验：给 Agent 加上语义搜索后，离线代码问答准确率平均提高 12.5%；线上 A/B 测试里，千文件以上代码库的代码保留率提高 2.6%。Cursor 也观察到 Agent 会大量使用 grep，但两种搜索配合时效果更好。
《Keyword Search Is All You Need》比较的是一套固定配置的 RAG 基线，以及一个能够反复改写查询、调用 rga 和 pdfgrep 的 Agent。在五组文档问答数据上，Agent 的平均忠实度达到 RAG 基线的 94.52%，上下文召回率为 88.05%，答案正确率为 91.48%。这些数字是相对基线的达成比例，并非三项指标的绝对得分。
作者同时列出了几项限制：文档变大后性能会下降，多媒体内容不容易处理，上下文窗口和模糊问题也会影响结果。这项实验说明，多轮关键词检索在部分文档问答任务上可以接近固定 RAG 基线。它还不足以回答语义搜索是不是已经失去价值。
至少从这些公开资料看，我会把结论收窄一些。
我现在更倾向于这样理解：检索正在进入 Agent 的运行过程。过去由系统在调用模型前准备一次上下文；现在，Agent 会根据刚找到的证据继续搜索、换工具，再决定下一步。
向量数据库仍然在场，只是它在架构图里的位置变了。
一次召回，跟不上排查过程
传统 RAG 处理的通常是一轮“提问、检索、回答”。查询在开始时已经给定，系统负责从资料库里挑出几段相关内容。
Agent 接到的往往是一项任务。搜索只是其中一步，而且后一个问题常常要等前一条证据出现后才知道。
比如排查“支付请求偶发重复执行”。最初只有一句故障描述，Agent 先搜错误码；日志把线索带到 HTTP 超时；配置里又出现消息队列重试；顺着调用链往回追，最后才需要核对幂等键与事务边界。
每找到一条证据，下一轮搜索的关键词、范围和工具都会变化。此时只在开场生成一次查询、召回几个片段，很难覆盖整个排查过程。
SWE-bench 早期的两组数据也常被放在一起：最初的 RAG 基线解决率是 1.96%，后来能使用工具、修改代码并运行测试的 SWE-agent 做到 12.47%。我不太会把它们当成两种检索方案的直接对照，因为模型、工作流和执行能力都变了。不过，这个差距至少说明，软件工程任务不止是找到相关文件。Agent 还得沿着证据行动，并验证修改有没有生效。
这里还有一个麻烦：Agent 会修改自己正在检索的代码。刚改完配置，后续搜索如果仍在读旧索引，分析就会落到旧版本上。Cursor 为 Agent 做快速正则索引时，会把用户和 Agent 的未提交修改叠加到 Git 基线上，让搜索能覆盖刚刚写入的内容。
这时，检索已经不再是模型调用前的一道工序，而是排查和修改过程的一部分。
图 1：固定 RAG 在开场完成检索，Agent 会根据新证据继续查找
grep 和向量搜索，各有合适的线索
代码库里的线索并不只有一种。
拿到函数名、路径、配置键或错误码，精确搜索通常最省事。问“退款权限校验大概放在哪里”，原文措辞未知，语义搜索更容易找到入口。要看定义、引用和调用关系，LSP、AST 或图索引又更合适。
Claude Code 与 Cursor 的选择看起来不同，放到各自的产品里却都说得通。
Claude Code 把文件系统和通用工具放在主路径上，少了一套预建索引，也绕开了索引更新、安全和维护上的不少麻烦。代价同样存在：运行时探索可能更慢，会消耗更多 Token，也可能沿着错误线索绕远路。
Cursor 面对大量大型代码库，保留语义索引，又给 Agent 配了快速正则搜索。两套工具同时存在，不同查询可以走不同路径。
Anthropic 后来把这类做法概括为 Just-in-Time Context Loading，也就是按需加载上下文。系统先保留文件路径、查询和链接等轻量线索，需要时再让工具取回内容。Claude Code 的文档把自己的方式称为“混合策略”：CLAUDE.md 预先进入上下文，具体文件则由 glob 和 grep 按需寻找。
一个偏向运行时搜索，一个保留语义索引。这里很难排出统一的先后顺序，代码库规模、更新频率和延迟预算都会改变选择。
把向量数据库放回索引层
做数据库架构时，索引和主库的边界并不陌生。索引加快读取，出了问题可以重建；业务事实仍由拥有它的系统保存。
放到 Agent 系统里，我更倾向于沿用这条边界：向量数据库是一种检索投影，它提供候选，事实仍要回到原始系统确认。
这条链路大致可以分成五层：
权威来源 → 检索投影 → 运行时选路 → 当前工作集 → 执行与验证
图 2：Agent 上下文系统的五层边界
最左边放能确认事实的来源。当前代码在工作树和 Git 中，订单状态在业务数据库里，发布结果要看制品、部署状态和回执。Markdown 里写着“服务已发布”，不能证明线上正在运行这个版本；知识库里写着“订单可以退款”，也不能证明眼前这笔订单满足条件。
向量索引、倒排索引、正则索引、AST、知识图谱和缓存放在第二层。它们帮 Agent 缩小范围，可以异步更新，也可以重建。索引内容与原文冲突时，以权威来源为准。
任务运行起来以后，Agent 再按手里的线索选择工具。函数名适合精确搜索，自然语言描述可以先用语义搜索找入口，实时余额则要查询受控 API。Harness 在这里限制权限、返回大小、调用次数和超时，免得探索过程不断扩散。
搜索拿回来的内容也不用全部塞进上下文。当前目标、相关源码、必要的工具结果和阶段状态组成一份工作集。大文件分段读，长日志先看错误附近，暂时用不到的资料留在外面。工具带回新证据后，工作集再跟着调整。
Agent 修改代码后运行测试、查看差异；调用业务接口后检查回执与当前状态；给出结论时保留原文出处。一次失败又会带来新的线索，搜索也随之进入下一轮。
这样画以后，RAG 没有被删掉，只是回到了检索投影这一层。
Markdown 解决的是另一件事
Claude Code 和 OpenClaw 都用 Markdown 保存项目规则或长期记忆。它的长处很朴素：人可以直接读，编辑器可以直接改，Git 能留下变化，Agent 也能通过路径和文本工具访问。
项目约定、任务笔记、失败记录和决策说明都适合这种形式。它们需要人工检查，偶尔要撤回，也需要知道是谁在什么时候改了什么。如果内容只藏在索引背后，维护和追责都会变难。
Markdown 并不擅长实时状态和高并发写入。文件一多仍然需要索引，多人同时修改仍然会冲突，事务和细粒度权限也不是它的强项。
OpenClaw 的公开设计把两者放在了一起：长期记忆写入 Markdown；配置 Embedding 后，memory_search 组合向量相似度与关键词匹配。文件保存内容，索引帮助发现内容。
在这类场景里，Markdown 与向量索引更像搭档，而不是替代关系。前者保留可读、可改、可追溯的内容，后者减少查找成本。
放到具体场景里看
在代码库里，我会先确认搜索结果能不能覆盖当前工作树。精确搜索和符号索引适合已知线索，语义搜索适合寻找陌生代码的入口。如果 Agent 读不到刚改的文件，离线召回率再高也解决不了眼前的问题。
面对几十万份相对稳定的文档，用户的问法和原文差异又大，向量召回仍然有价值。关键词、元数据过滤和重排可以补足精确性，版本与权限也要进入检索条件。
库存、订单、监控和权限属于另一类数据。它们变化快，也有明确的系统 Owner。让 Agent 通过受控工具查询原系统，通常比定时复制到知识库少绕一层，也少一次读到旧状态的机会。
图 3：不同线索适合不同工具，行动前仍要核对权威来源
到了方案评审，分歧通常会落在三个问题上：
哪个系统持有最终事实，索引过期后能不能回源？ Agent 手里的线索是精确符号、自然语言，还是实时状态？ 检索结果出错，只会答偏一句，还是会触发真实操作？
答案往往不会只指向一种技术。前两个问题影响检索路径，最后一个问题关系到验证需要做到什么程度。
召回率解释不了任务有没有做完
Recall@k、Precision@k、MRR 和延迟仍然值得看，只是它们描述的是某一次召回。Agent 可能第一轮没找到目标文件，第二轮顺着错误码找到了；也可能第一轮拿到的片段很相关，最后却依据旧版本改错了代码。
Cursor 的实验除了离线问答准确率，还观察代码是否被保留、用户是否继续追问。它把检索结果放回了完整任务中，而不是只看相似度。
如果评估自研 Agent，我会更关心一批真实任务从头跑完后的情况：它有没有找到当前证据，经过多少轮搜索，工具失败后能否换路，修改是否通过测试，最后还需要多少人工返工。把成本和耗时放在同一组结果里，取舍也会更清楚。
跑完以后，有些任务用 grep 就够了，有些离不开向量召回，还有一些本来就不该去查知识库。
我会把向量数据库画在哪里
回到标题，Claude Code 没有宣布向量数据库过时，Cursor 也没有放弃语义搜索。关键词搜索论文说明的是另一件事：在限定任务和配置下，Agent 依靠多轮关键词检索，也能接近那条固定 RAG 基线。
对我来说，更有意思的变化是，应用不再试图在第一次模型调用前准备好全部上下文。Agent 会根据新证据继续找，检索工具也会跟着任务变化。
落到架构设计，剩下的都是很具体的问题：事实存在哪里，索引多久更新，Agent 能用哪些工具，当前上下文保留什么，执行后怎样确认结果。
以后再画 Agent 架构图，我仍会保留向量数据库，只是不再把它放在正中间。正中间更适合留给那条不断查找、行动和验证的运行循环。
参考资料
Latent Space：Claude Code 团队访谈（https://www.latent.space/p/claude-code） Shreyas Subramanian 等：Keyword Search Is All You Need（https://arxiv.org/abs/2602.23368） SWE-bench：Original benchmark（https://www.swebench.com/original.html） Anthropic：Effective context engineering for AI agents（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents） Claude Code：How Claude remembers your project（https://code.claude.com/docs/en/memory） Cursor：Improving agent with semantic search（https://cursor.com/blog/semsearch） Cursor：Fast regex search: indexing text for agent tools（https://cursor.com/blog/fast-regex-search） Cursor：Securely indexing large codebases（https://cursor.com/blog/secure-codebase-indexing） OpenClaw：Memory overview（https://docs.openclaw.ai/concepts/memory）
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：[email protected]