用 grep 打败向量搜索？这篇论文让 AI 圈重新审视一个 40 年前的老命令
大家都在卷嵌入模型、卷向量库、卷重排序，但一篇新论文告诉你：在 AI Agent 里，那个古老的 grep 可能才是隐藏王者。
🔍 微信扫码或搜索「AI在学」关注公众号
如果你在做 RAG 系统，大概率已经把向量搜索当成了标配——搞个嵌入模型、建个向量库、加个重排序，感觉不这样做就跟不上时代。
但有研究团队最近发了一篇论文，用实验数据告诉你：在 AI Agent 的真实场景里，一个 1973 年就存在的老命令行工具，在多数情况下赢了你精心调优的语义搜索。
💡 论文核心结论： 在 116 道长记忆问答题的测试中，当搜索结果直接返回给模型（即 inline 模式）时，grep 对向量搜索全面胜出——覆盖了所有测试的 Agent 框架和模型组合，无一例外。
🔍 先说清楚：这篇论文在测什么
研究问题说白了就是：在 AI Agent 里，你用 grep（关键词精确匹配）还是向量搜索（语义近邻检索），到底哪个更管用？
而且他们不只比较两种检索方式，还同时考察了两个被业界长期忽视的维度：
⚙️ Agent 框架（Harness）： 用哪套工具来跑 Agent？他们对比了自研框架 Chronos，以及 Claude Code、Codex CLI、Gemini CLI 三个大厂原生 CLI。
📤 结果返回方式（Tool Calling Method）： 搜索结果是直接塞进对话上下文（inline），还是先写到文件让模型自己去读（file-based）？
测试用的是 LongMemEval 基准的 116 道题，涵盖知识更新追踪、多轮会话聚合、时间推理等六类任务。模型阵容包括 Claude Opus 4.6、Claude Haiku 4.5、GPT-5.4、Gemini 3.1 Pro 和 Gemini 3.1 Flash-Lite。
📊 实验一：数字说话
先看 inline 模式（搜索结果直接进入对话）下的准确率对比：
| 框架 + 模型 | grep | 向量搜索 | 差距 |
|---|---|---|---|
| Chronos + Claude Opus 4.6 | 93.1% | 83.6% | +9.5pp |
| Codex CLI + GPT-5.4 | 93.1% | 75.9% | +17.2pp |
| Gemini CLI + Flash-Lite | 87.1% | 67.2% | +19.9pp |
| Chronos + Gemini Flash-Lite | 86.2% | 62.9% | +23.3pp |
| Claude Code + Claude Haiku 4.5 | 55.2% | 44.0% | +11.2pp |
结论很清晰：在所有框架和模型的组合下，inline grep 的准确率都高于 inline 向量搜索，差距从将近 10 个百分点到超过 23 个百分点不等。
但这篇论文真正精彩的发现不止于此。
🤯 更深的洞察：换框架比换检索方式的影响更大
注意这组数据：同样是 Claude Opus 4.6 + grep，在 Chronos 框架下准确率是 93.1%，而在 Claude Code 框架下只有 76.7%。
差了整整 16.4 个百分点——这个差距比你从 grep 换成向量搜索造成的损失还要大。
| 操作 | 准确率变化 |
|---|---|
| 同框架，grep → 向量搜索 | 约 −10pp |
| 同检索，Chronos → Claude Code | 约 −16pp |
换句话说，你精心挑选的检索策略，可能还没有你用的 Agent 框架对结果的影响大。
论文把这个现象归结为：框架决定了系统提示词、工具描述、结果格式化方式，以及模型决定“什么时候停止搜索”的整个上下文——这些加在一起，才是“检索”真正发生的地方。
🧩 在 Agent 系统里，“检索”从来不是孤立的一个模块，它是检索 + 调度 + 上下文管理的综合结果。
🔄 File-based 模式：反转来了
结果返回方式从 inline 换成 file-based（搜索结果写入文件、模型自行读取）之后，情况变得复杂了。在 10 个框架-模型组合中，有 5 个出现了向量搜索反超 grep 的情况。
最极端的案例是 Codex + GPT-5.4：
| 模式 | 准确率 |
|---|---|
| inline grep | 93.1% |
| file-based grep | 55.2% ⬇️ 跌了近 38pp！ |
| file-based 向量搜索 | 67.2% ⬆️ 反超 |
这说明把结果写到文件这个“额外的一步”，对某些框架来说是一个真实的能力考验——如果模型不能稳定地完成“找到文件 → 打开 → 整合 → 回答”这条链路，再好的检索都白搭。
论文的结论是：file-based 架构本质上是在用上下文空间换工具调用能力，这笔账只有当模型能可靠地完成整条链路时才划算。
🔊 实验二：加入噪音，谁更抗压？
第二个实验把无关会话（干扰项）从 5 个逐步增加到 66 个，测试两种检索方式在“大海捞针”场景下的鲁棒性。
有意思的发现是：向量搜索在噪音较少时往往表现更好，而当噪音增多时，grep 反而能保持甚至逆转。
以 Chronos + Claude Opus 4.6 为例：
| 噪音级别 | grep | 向量搜索 |
|---|---|---|
| s5（5 个会话） | 89.3% | 94.0% |
| s10 | 89.7% | 94.8% |
| s20 | 90.5% | 92.2% |
| s30 | 85.3% | 84.5% |
| full（全量） | 89.7% | 92.2% |
论文的解释是：语义搜索容易被“话题相近但内容无关”的干扰项带偏，而 grep 的精确匹配在大量噪音场景下反而更稳。
不过这个结论不是绝对的——它依赖于具体的框架和模型组合。比如在 Gemini CLI + Gemini 3.1 Pro 这组，向量搜索在所有噪音等级下都持续领先。
💡 为什么 grep 能赢？
论文给出了一个直白的解释：LongMemEval 里的答案，往往依赖于“字面证据”——具体的日期、人名、数字、精确的表述。这类证据在文本里是字面存在的，grep 能直接命中，不需要经过嵌入模型这一层。
反过来，向量搜索的“语义理解”在这里成了负担：它把语义上相似的内容都拉进来，但如果问题的答案是“2023年3月15日”，你不需要语义相似，你需要精确匹配。
一个类比：
🎯 grep 是个追踪者——只要你给出准确的线索，它能找到确切的那条记录。
🌐 向量搜索是个联想者——它能把相关的内容都网罗过来，但网得越大，混进来的干扰也越多。
在“大海捞针”场景下，如果你知道针的形状，追踪者比联想者更可靠。
论文也明确指出，这个结论不能泛化：如果你做的是科学论文综合、代码语义理解这类任务——答案并不以字面形式存在于文本中——向量搜索和混合方案可能会有截然不同的表现。
🎯 这篇论文对你意味着什么？
🛠️ 如果你在做 RAG/Agent 系统： 不要默认向量搜索是唯一答案。如果你的任务是精确信息提取（特定日期、人名、数值），先试试 grep，成本更低，效果可能更好。
🏗️ 如果你在选 Agent 框架： 框架本身对最终效果的影响，不比检索策略小。在真实 benchmark 上评估不同框架，比反复调嵌入模型更值得投入。
📏 如果你在搭建评测体系： 评测不能只报“BM25 vs ANN”，必须同时报告 Agent 框架和结果返回方式——否则你看到的数字没有可复现性。
👀 如果你只是对 AI 进展感兴趣： 这篇论文的价值在于打破了一个直觉——“更复杂的技术 = 更好的效果”。有时候，工程上最朴素的选择，在端到端系统里才是最鲁棒的。
📚 参考文献
Sen, S., Kasturi, A., Lumer, E., Gulati, A., & Subbiah, V. K. (2026). Is Grep All You Need? How Agent Harnesses Reshape Agentic Search. arXiv:2605.15184 [cs.CL]. https://arxiv.org/abs/2605.15184