今年 3 月底，AI 编程圈出了件事：npm 包里残留了一个 .map 文件，Claude Code 的完整源码被公开了。知乎有人花了一天把 51 万行代码全部读完，然后在知乎提了个让很多人愣住的问题——这个被业内公认「目前最好用」的 AI 编程工具，根本没用 RAG。
没有 embedding 模型，没有向量数据库，没有索引管道。它检索代码库的方式，就是给模型三个工具：用 glob 找文件，用 grep 搜代码片段，用 read 读全文。就这么朴素。
这不是个例。知乎的讨论里有人指出，OpenAI 的 Codex 底层用的也是 ripgrep（grep 的加速版）。知乎两家最头部的 AI 编程产品，不约而同放弃了「行业标准」的向量检索。
知乎上那个「为什么现在 Agent 重新用回 Grep，而不是先做 RAG？」的问题，7 月初提出，目前 14 万浏览，直到 8 月 21 日还有新的高赞答案在更新。知乎8 月初开发者云风的一场「SQLite vs Grep」之争，相关讨论也拿到了 45 万+浏览——「Agent 时代该怎么检索」这个话题，是真的烧起来了。
那么问题来了：RAG 这个「AI 应用第一课」，真的被最先进的产品抛弃了吗？你的团队做知识库，向量库还值不值得建？
我把两派的论据都翻了一遍。先说结论：别急着拆，也别无脑建，他们吵的根本不是同一个问题。
grep 派为什么说可以拆掉向量库
第一个论点很扎心：RAG 的检索能力是「租」来的，而且租约和模型升级不同步。
8 月 21 日的一条新答案说得直白：主流大模型调用走 OpenAI 协议，你拿不到 LLM 内部的 embedding 信息，所以几乎所有 RAG 方案都得靠外部 embedding 模型加向量数据库。知乎问题在于，基座模型每升级一代，代码能力更强、世界知识更多，而那个外部 embedding 模型纹丝不动。检索链路和生成模型，永远是两套互相追赶的系统。
第二个论点更进一步：检索本身是可以被训练进模型的技能。在 agentic RL 的训练范式下，「模型用 grep、glob 在文件里找信息」这个行为可以直接被强化学习接管，内化成模型能力。知乎而 RAG 工程师天天调的 chunk 策略、top-k、rerank，本质都是模型外面的 if-else。模型越强，这套外挂脚手架的性价比就越低。
第三，把文档打碎成 chunk，本身就在丢信息。Mintlify 的工程实践被反复引用：他们做 AI 文档助手，最初也是标准 RAG——切块、向量化、相似度搜索，结果当答案散落在多个文档、或者用户要一段精确的代码语法时，系统直接失灵。他们的反思是：目录结构、章节、模块依赖，这些是人类专家精心组织的知识图谱，把它们拍平成无差别的文本块，等于主动制造信息熵增。知乎向量搜索擅长找「意思差不多的」，但找不了「精确的那一个」——查函数名、配置项、错误码，grep 比向量好用得多。
还有个现实的细节：Mintlify 算过，给 Agent 一个真实沙箱让它自己克隆仓库去搜，单次启动加准备要 46 秒，按每月 85 万次对话估算，一年基础设施费用超过 7 万美元。知乎Mintlify所以他们做了 ChromaFs——底层保留已有的向量数据库，上层包一层虚拟文件系统接口，Agent 像用 ls、cat、grep 一样浏览文档，命令在底层翻译成检索。两头都没牺牲。
最后是成本论。7 月底那条 135 赞的答案话说得比较狠：grep 最大的优势，是迭代效率和成本比 RAG 低几个数量级。知乎建向量库，你要折腾分块、选 embedding、维护索引，还得搭评测集盯着准确率；用 grep，你只需要一个整理好的文本目录，今天就能跑起来。
但 grep 不是银弹，反方的反驳都打在了真实边界上
边界一：规模。
云风那场争论的本质，是「一个人能维护的小聪明」和「十亿人都在用的系统」的差别。知乎单机、小团队、读写简单，文本追加加 grep 确实轻量；但一碰到并发写入、索引、历史记录回溯，「随便拎一个出来，都不是 grep 能优雅解决的」。知乎上一个做百万文档级知识库的工程师说得更直接：这个量级必须「先准后快」，纯靠 Agent 一步步搜不现实，系统化的检索架构依然不可少。知乎
边界二：命名规范和语义模糊。
grep 在代码场景好使，前提是代码命名严格、唯一。那条高赞答案自己也承认，假设你的数据里有多个功能和命名类似的对象，grep 到谁几乎纯运气。知乎更要命的是，真实用户不按关键词提问——他问的是「上次那个登录的配置怎么弄的」。这种语义模糊的问题，grep 连入口都找不到。
边界三是很多人没想到的：Bash 对大模型本身就难。
4 月份「Bash 即一切」的讨论里，有条 1197 赞的答案从理论上泼了冷水：Bash 的引号和转义本质是 Dyck-k 配对问题，而 Transformer 的电路复杂度类别是 TC0，天生不擅长维持任意深度的状态。知乎换句话说，Agent 写复杂 shell 命令很容易被引号坑，「让模型用 grep 检索」这条路本身有能力上限，检索对象越接近模型擅长的代码和规整文本，它才越顺。
边界四：延迟和流量。
Claude Code、Codex 都是你自己用的工具，一个问题搜十几轮、等几十秒，你可以接受。但你要是做对外的在线客服、站内搜索框，用户每问一句就触发多轮工具调用，延迟和 token 成本根本过不了评审。高 QPS、低延迟场景，向量检索毫秒级返回 top-k，仍然是唯一解。
那你的向量库到底要不要建？对一下这 4 个问题
两派吵的其实不是同一个问题：grep 派说的是「模型足够聪明、数据足够规整」的 Agent 工具场景；RAG 派守的是「语料大、问题模糊、流量高」的服务场景。判断你自己的项目，就问四个问题：
一问数据量。 文件数在万级以内、目录结构干净，直接让 Agent 搜，省掉整个向量化管道；十万级往上，老老实实建索引。中间地带看下一问。
二问提问方式。 用户的问题带明确关键词（函数名、文件编号、配置项），grep 式天然合适；全是「去年那个关于 XX 的报告」这类语义模糊的问法，还是得靠向量接住语义。
三问服务形态。 Agent 对话、能接受多轮检索延迟、优先迭代速度，走 grep 式；对外 API、高 QPS、毫秒级响应，走向量检索。
四问维护人力。 这是最容易被忽略的隐性成本：embedding 模型要跟着业务升级，索引要跟着文档更新重建，评测集要有人盯。没有这份人力，与其建一个没人维护的 RAG，不如把目录整理干净交给 grep——至少诚实。
还有一种中间路线，也是 Mintlify 验证过可行的：底层保留检索引擎，给 Agent 暴露文件系统接口；或者两段式，先用向量或 BM25 粗筛出少数几个文件，再让 Agent 精读。Anthropic这两种是目前企业知识库最稳的落地姿势。
最后说说值得继续盯的信号
这场争论的本质是一句话：检索能力该放进模型里多少，该留在工程里多少。
三个观察点：第一，下一代编程 Agent 的检索工具设计，是继续纯 grep 还是混入语义检索，这是模型能力最直接的风向标；第二，知识库产品的走向——今年 RAGFlow 这类产品都在往图谱化和 Agentic 方向加功能，纯向量检索的卖点正在失效；第三，长上下文的价格，一旦上下文窗口大到能把整个库塞进去还便宜，grep 和 RAG 可能一起失业。
对大多数团队，我的建议很朴素：别因为「行业标配是 RAG」就开工，也别因为 Claude Code 用 grep 就急着拆库。先把上面四个问题答一遍，答案自己就出来了。
