{"notes":[{"id":"retrieval-augmented-generation/is-grep-all-you-need","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Is Grep All You Need","subtitle":"Grep 就够了？","author":"Z. Yuan","paperDate":"2026-05-14","publishedOn":"2026-08-29","paperTitle":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","paperUrl":"https://arxiv.org/abs/2605.15184","bibliography":{"title":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","authors":["Sahil Sen","Akhil Kasturi","Elias Lumer","Anmol Gulati","Vamse Kumar Subbiah"],"url":"https://arxiv.org/abs/2605.15184","pdfUrl":"https://arxiv.org/pdf/2605.15184v1","codeUrl":null,"preprint":{"id":"2605.15184","submittedOn":"2026-05-14","url":"https://arxiv.org/abs/2605.15184"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationisgrepallyouneed2026,\n  title = {{Is Grep All You Need? How Agent Harnesses Reshape Agentic Search}},\n  author = {Sahil Sen and Akhil Kasturi and Elias Lumer and Anmol Gulati and Vamse Kumar Subbiah},\n  year = {2026},\n  eprint = {2605.15184},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2605.15184}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/is-grep-all-you-need.4ebb3c804df8.bib"},"thumbnail":{"src":"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png","width":944,"height":422},"locale":"zh-hans","path":"/content/papers/zh-hans/retrieval-augmented-generation/is-grep-all-you-need.1b6f1d0bd284.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"任务在长对话里找回记忆","text":"任务：在长对话里找回记忆","depth":3},{"id":"两种检索工具","text":"两种检索工具","depth":3},{"id":"四种-harness","text":"四种 harness","depth":3},{"id":"两种结果传递方式","text":"两种结果传递方式","depth":3},{"id":"模型与评分","text":"模型与评分","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"实验一grepharness-与传递方式","text":"实验一：grep、harness 与传递方式","depth":3},{"id":"实验二干扰越多会怎样","text":"实验二：干扰越多，会怎样？","depth":3},{"id":"两个实验的数字对不起来","text":"两个实验的数字对不起来","depth":3},{"id":"作者自己划的界线","text":"作者自己划的界线","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"这两年用过 Claude Code、Codex 或 Gemini CLI 的人，大概都看过这个画面：你问它一个关于代码的问题，它先跑一串 `grep`，读几个文件，再回头回答你。\n\n这和过去几年的 RAG 标准做法不太一样。那时候的默认，是先把文档切块、转成向量，存进向量数据库，再用语义相似度去找。\n\n于是很多人开始问：既然 agent 自己会 grep，向量检索还需要吗？\n\n这篇来自 PwC（美国）的预印本，2026 年 5 月发表于 arXiv。标题问的是「grep 够不够」，但读完会发现，作者真正量到的是另一件事：**同一个检索工具，放在不同的 agent 外壳里，表现可以差很多。**\n\n\n> [!TIP]\n> \n> **Harness 是什么？**\n> \n> 这篇论文反复出现的 **agent harness**，可以想成「包在模型外面的那层程序」：它决定给模型哪些工具、系统提示怎么写、工具的结果用什么格式送回去、什么时候停下来。\n> \n> 同一个 Claude Opus 4.6，放在 Claude Code 里，和放在自己用 LangChain 写的 agent 里，就是两种 harness。模型一样，看到的提示、工具说明和返回格式都不一样。\n\n\n## 定义问题\n\n作者认为，过去比较检索方法的研究，大多假设一条固定的流水线：检索器找出文档，拼进提示词，交给模型回答。\n\n但 agent 不是这样用检索结果的。它会自己决定要搜什么、搜几次、结果够不够，不够就换个关键字再搜。这些行为都受 harness 影响。\n\n所以作者想回答三个问题：\n\n1. **grep 和向量检索，在不同 harness 里谁比较好？**\n2. **工具结果直接塞进对话，还是写成文件让 agent 自己去读，会改变结论吗？**\n3. **无关的数据越来越多时，两种检索的表现怎么变？**\n\n## 解决问题\n\n### 任务：在长对话里找回记忆\n\n评测数据是 LongMemEval 的 116 题子集。\n\nLongMemEval 测的是长期对话记忆：每题附带一大堆聊天记录（session），其中一个或几个 session 藏着答案，其他都是无关的干扰。题目分成六类：\n\n| 类别 | 测什么 |\n| --- | --- |\n| knowledge-update | 追踪状态随时间的变化 |\n| multi-session | 跨多段对话汇总信息 |\n| single-session-assistant | 回想助理自己说过的内容 |\n| single-session-preference | 用户的个人偏好 |\n| single-session-user | 用户说过的事实 |\n| temporal-reasoning | 计算时间长度、排列事件顺序、推算日期 |\n\n举个本文自拟的例子：题目可能是「我上次换工作是几个月前？」，答案就藏在几十段聊天记录的某一句话里。\n\n作者另外用他们先前提出的 Chronos 预处理，把对话里的日期、时间区间抽成结构化的事件记录，和原始对话一起存成每题各自的文件。作者的理由是，这篇要测的是「找不找得到证据」，不是「会不会从零碎的对话推算日期」。\n\n### 两种检索工具\n\n**grep**：把每题的对话与事件记录加载内存，直接用正则表达式比对原始文本，按命中次数排序。不需要 embedding 模型、向量索引或任何外部服务。\n\n**向量检索**：每一轮对话、每一笔事件都事先转成 embedding，存进每题各自的索引。查询时把问题转成向量，用近似最近邻搜索找出候选，再经过一次重新排序（rerank），返回前 $k$ 笔；$k$ 由 agent 自己决定。\n\n论文没有写明使用的 embedding 模型与 reranker 名称。\n\n### 四种 harness\n\n- **Chronos**：作者自己用 LangChain 写的 agent，有四个搜索工具（对话与事件各有 grep 和向量版本），依实验设置开关。系统提示会依题目类别动态调整，例如时间推理题和偏好题的提示不同。\n- **Claude Code**、**Codex CLI**、**Gemini CLI**：三家模型供应商自己的命令行 agent。作者给它们题目和一段动态产生的搜索策略，让它们通过 bash 调用包装好的 grep 或向量搜索脚本。\n\n\n> [!NOTE]\n> \n> **一个值得留意的设置细节**\n> \n> 依论文 §3.3.1 的描述，Chronos 在每题开始时会先放入一段「向量检索前 15 笔」的初始上下文，才进入工具调用的循环。论文没有说明在 grep-only 的设置下，这一步是否也一并移除。读 Chronos 的 grep 成绩时，可以把这点放在心上。\n\n\n### 两种结果传递方式\n\n- **Inline（标准）**：搜索结果直接输出到标准输出，或作为工具响应插进对话。模型马上看得到，但结果很多时会挤占上下文。\n- **Programmatic（文件式）**：搜索结果写进文件，模型只拿到文件位置，必须再调用一次工具去读或去 grep 那个文件。这能避免大量结果塞爆上下文，代价是多一个步骤。\n\n### 模型与评分\n\n受测模型有五个：Claude Opus 4.6、Claude Haiku 4.5、GPT-5.4、Gemini 3.1 Pro、Gemini 3.1 Flash-Lite。\n\n依照 LongMemEval 的评测方式，用 GPT-4o 当评审：看题目、标准答案和 agent 的回答，判断对或错。\n\n## 讨论\n\n### 实验一：grep、harness 与传递方式\n\n[![原论文 Table 1：五个模型在 Chronos 与各家 CLI 中，grep 与向量检索在 inline 与 programmatic 两种传递方式下的准确率](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)\n\n*原论文 Table 1，取自 [**v1 PDF 第 5 页**](https://arxiv.org/pdf/2605.15184v1#page=5)，CC BY 4.0。116 题、完整干扰数据；前两列为 inline，后两列为 programmatic。*\n\n每一行固定一组模型与 harness，四列分别是两种检索乘上两种传递方式。\n\n**先看前两列（inline）**。十组里，grep 全部高于向量检索。差距最大的是 Chronos 搭配 Gemini 3.1 Flash-Lite：86.2% 对 62.9%；最小的是 Claude Code 搭配 Claude Opus 4.6：76.7% 对 75.0%。\n\n**再看同一个模型、不同 harness**。Claude Opus 4.6 的 inline grep，在 Chronos 是 93.1%，在 Claude Code 只有 76.7%，差了 16.4 个百分点。同样在 Chronos 里，grep 和向量的差距是 9.5 个百分点。换 harness 造成的落差，和换检索方法相当，甚至更大。\n\n**最后看后两列（programmatic）**。改成文件式传递后，向量检索在十组里有五组反超 grep。最戏剧性的是 Codex CLI 搭配 GPT-5.4：inline grep 有 93.1%，和最好的成绩并列；改成 programmatic，grep 掉到 55.2%，向量也只有 67.2%。\n\n作者的解读有两点：\n\n1. **LongMemEval 奖励字面证据**。确切的日期、次数、偏好、原句，这些字符串在分词前后都很稳定，grep 可以直接找到，不需要经过 embedding 这一关。\n2. **文件式传递把任务变难了**。原本是「读工具返回的消息」，现在变成「找到文件、打开它、集成内容」。只要这多出来的一步不稳，准确率就可能和检索质量无关地崩掉。\n\n\n> [!TIP]\n> \n> **116 题，差一题是多少？**\n> \n> 一题占 $1/116\\approx0.86$ 个百分点。\n> \n> Claude Code 搭配 Opus 的 76.7% 对 75.0%，换算回题数是 89 题对 87 题，只差 2 题。论文每个设置看起来只跑了一次，也没有报告变异范围。差距只有几题的比较，最好别看得太重。\n\n\n### 实验二：干扰越多，会怎样？\n\n第二个实验调整每题能看到的 session 数量：5、10、20、30，以及完整的 39 到 66 个 session。含答案的 session 一定保留，其余名额用同一题的干扰 session 补满。\n\n常见的直觉是：数据少的时候 grep 就够了，数据一多，就需要语义搜索。\n\n结果没有这么单纯：\n\n- **曲线不是单调的**。例如 Chronos 搭配 Opus 的 grep，从 s20 的 90.5% 降到 s30 的 85.3%，到完整数据又回到 89.7%。\n- **数据少时，向量反而常常较好**。在 s5，Chronos 的 grep 落在 83.2% 到 89.7%，向量则是 87.9% 到 94.0%。\n- **谁比较好，取决于 harness**。Claude Code 搭配 Opus 和 Haiku，在每个设置都是 grep 较好；Gemini CLI 搭配 Gemini 3.1 Pro，则每个设置都是向量较好，完整数据时差距拉到 89.7% 对 78.5%；Chronos 则在不同设置间互有领先。\n\n作者也提醒，每换一个 session 上限，干扰 session 就会重新抽样。所以「30 个比 20 个简单」这种中段起伏，可能来自当次抽中的干扰内容。解读这些曲线时，要把各次随机抽样的影响一起考虑进去。\n\n### 两个实验的数字对不起来\n\n读这篇论文时，有一件事需要特别留意。\n\n实验一和实验二的「完整数据」设置，看起来是同样的 116 题、同样的干扰数据、同样的 inline 传递，但数字差很多：\n\n| 模型与 harness | 检索 | 实验一（Table 1） | 实验二 full（Table 2、3） |\n| --- | --- | ---: | ---: |\n| Opus＋Claude Code | grep | 76.7 | 94.0 |\n| Haiku＋Claude Code | grep | 55.2 | 81.9 |\n| Opus＋Chronos | 向量 | 83.6 | 92.2 |\n| Gemini 3.1 Pro＋Gemini CLI | grep／向量 | 81.9／75.0 | 78.5／89.7 |\n\n最后一行连胜负都反过来了：实验一是 grep 领先，实验二变成向量领先。论文没有解释两个实验的设置差在哪里。实验二也还缺 Codex 的数据行，作者自己标示为尚待补齐。\n\n所以结论说「grep 一致地比向量准确」，严格来说只对实验一的 inline 设置成立。\n\n### 作者自己划的界线\n\n作者在限制一节写得很清楚：这些结论绑定在长期对话记忆的问答上。这类题目的证据常常就是原文里的某一句话，对字面比对特别有利。换成科学文献的改写摘要、图片很多的文档，或代码语义这类证据很少原样出现的领域，结果可能不同。\n\n作者明说，他们**不主张 grep 普遍胜过向量检索**，只说在他们研究的任务与语料上，grep 可以在端到端的比较中胜出。\n\n## 结论\n\n这篇论文的标题问「grep 够不够」，答案是：**在这个任务、这几种设置下，常常够，但要看是谁在用、怎么用。**\n\n1. **Inline 时，grep 在十组里全胜**。长对话记忆的证据多半是可以原样找到的字符串，正好是 grep 擅长的。\n2. **Harness 的影响和检索方法一样大**。同一个 Claude Opus 4.6，在自制 harness 和 Claude Code 之间差了 16.4 个百分点。\n3. **改成文件式传递，胜负会重洗**。Codex 搭配 GPT-5.4 的 grep 从 93.1% 掉到 55.2%；十组里有五组变成向量领先。\n4. **干扰增加时，没有固定的赢家**。两种检索的优劣随 harness、模型与抽样起伏。\n\n这些结果来自 116 题、单次运行、未具名的向量模型，两个实验之间还有对不上的数字，适合当成「值得自己验证的方向」，不适合当成定论。\n\n作者在结论写了一句很实用的话：检索机制、harness 的编排、结果的传递路径，应该当成一个系统一起评估。\n\n换句话说，要比较 grep 和向量，最好在你自己的 agent 里比。\n","imageSizes":{"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png":{"width":944,"height":422}}}