三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

Is Grep All You Need?Agent 搜索里,Harness 比检索方法更重要

Is Grep All You Need?Agent 搜索里,Harness 比检索方法更重要

今天来解读下论文「Is Grep All You Need? How Agent Harnesses Reshape Agentic Search」。论文的作者们均来自 PwC U.S. 的 AI 研究团队,研究方向偏企业内部 AI 工程与 Agent 应用。这个背景也解释了为什么这篇论文没有只停留在检索算法对比上,而是把重点放在了 Harness、工具返回方式,以及端到端 Agent 表现。

虽然论文本身研究的是 Agent 搜索里的一个具体问题:在长文本检索任务中,grep 和向量检索到底谁更有效?但论文真正想说明的不是“grep 优于向量检索”,而是 Agent Harness 会显著改变检索方法的最终效果。

图注:论文中的表 1 比较了 grep 和向量检索(vector)在不同 Agent Harness 下的表现。它想强调的不是某个检索器单独有多强,而是检索方法和 Agent 运行环境之间会互相影响。

论文研究的核心问题

这篇论文的核心问题有两个:一个是在 Agent 搜索任务里,grep 和向量检索哪个效果更好?另外一个是同一种检索方法,放进不同 Agent Harness 里,效果会不会不一样?

这里的 Harness,主要是 Agent 执行任务时的外部环境。比如,模型能用什么工具、工具结果怎么返回、返回的结果是直接进上下文,还是写到文件再让模型来读取。

因此,这篇论文不是在做一个传统 RAG 检索器评测。它更关注端到端 Agent 的表现:模型拿到任务之后,自己调用搜索工具、读取结果、组织证据,到最后的交付结果。

这也是它和普通 RAG 评测不太一样的地方。普通 RAG 测评里,我们通常会单独看“找资料”这个检索操作做得好不好;但在 Agent 系统里,检索过程受到工具调用方式、上下文组织方式、模型的搜索策略的影响。

实验设计

论文用了 LongMemEval 中的 116 个问题子集。LongMemEval 是一个面向聊天助手长期记忆的评测集,主要考察信息抽取、多 session 推理、时间推理、知识更新和拒答等能力。

论文中作者把对话内容存成本地语料,让 Agent 分别使用 grep 和向量检索来查找资料,最后看它们各自的回答准确率。

他们比较了两种 Harness:

  • 自定义 Harness:Chronos,作者团队自建的长对话记忆 Agent 运行环境;

  • AI 厂商原生 CLI Harness:Claude Code、Codex、Gemini CLI。

除了比较不同 Harness,这篇论文还特别看了一个细节:搜索结果是怎么返回给 Agent 的。

一种是inline,就是搜索结果直接进入模型上下文;另一种是file-based / programmatic,就是搜索结果先写到文件,模型按需打开和读取。

搜索结果返回的方式很重要,它会影响 Agent 后面怎么读资料、要不要继续查,也会改变 grep 和向量检索最后跑出来的效果。

实验结果

inline 场景下,grep 表现更好

论文的实验 1 主要是在比较不同 Harness、不同模型、不同工具返回方式下,grep 和向量检索的整体准确率。

第一个比较直观的发现是:**在 inline 工具返回模式下,grep 整体表现优于向量检索。**当搜索结果直接进入模型上下文时,grep 在多组 Harness 和模型组合里都拿到了更高的准确率。论文摘要里也提到,在实验 1 中,grep 的准确率整体高于向量检索。

图注:表 1 显示 inline 模式下,grep 的表现普遍更好。

这个结果并不难理解。LongMemEval 这种任务,很多时候检索系统要找的不是抽象语义,而是长对话里的某个具体事实。比如,用户之前提到过的偏好、某个日期、某次状态变化,或者某个明确表达过的选择。

这类信息通常就在原文里,Agent 只要能猜到合适的关键词,grep 就能直接把相关资料找出来。

向量检索更擅长处理语义相近的问题,在这个测试用例下它会遇到一个问题:在长对话中,很多片段主题会很相近,但不一定真的能回答当前问题。向量检索可能会找到“看起来相关”,但不是最终答案需要的那句话。

因此,在这个任务里,grep 的优势不是更“聪明”,而是更直接。它不做太多语义联想,只要关键词命中,相关资料就会比较清楚地浮出来。

Harness 对结果的影响很大

这篇论文值得注意的地方还有 Harness 对最终结果的影响非常明显。

这个结论和上面一样,主要来自实验 1。实验 1 不只是比较 grep 和向量检索,还把它们放进了不同 Harness 进行测试,包括 Chronos、Claude Code、Codex 和 Gemini CLI。同样的检索方法、同样的数据,只要换一个 Agent 运行环境,最后的准确率就可能发生变化。论文摘要里也提到,即使用的是同一批对话数据,最终得分会强依赖具体的 Harness 和工具调用方式。

这也说明了 Harness 不是一个透明外壳,它会实际改变 Agent 的搜索能力。这个很好理解。Agent 搜索不是一次性检索。模型会自己决定搜什么、怎么搜、要不要继续查、怎么读返回结果,以及什么时候停止。Harness 会影响这些过程里的每一个环节。比如:

  • 工具描述写得清不清楚;

  • 搜索结果返回得是否完整;

  • 结果是不是被截断了;

  • 模型能不能看到原文上下文;

  • 工具调用记录会不会污染上下文;

  • file-based 结果能不能被模型正确打开和读取。

这些因素都会影响最后准确率。

file-based 返回会让问题变复杂

论文还比较了 inline 和 file-based 两种工具返回方式。

inline 的好处是直接:搜索结果进入上下文,模型马上就能看到相关资料。它的问题也很明显,结果一多就会占上下文,挤压其他信息。file-based 则相反。它会先把搜索结果写进文件,模型需要的时候再打开读取。这样做可以节省上下文,但代价是链路变长了。

模型不再只是“看到结果然后回答”,而是要多走几步:先理解搜索结果被放在哪里,再打开对应文件,再从文件里找到相关内容,最后把这些内容整合进答案。这条链路里任何一步出错,都会影响最终准确率。

这一点也可以从前面的表 1 里看出来:同样是 grep 或向量检索,只要工具返回方式从 inline 换成 file-based / programmatic,准确率就会发生明显变化。

这点对工程实践很有参考价值。很多时候,我们会把“结果写进文件”看成一种上下文优化。但从 Agent 的角度看,这其实也是在增加任务步骤。如果 Harness 没有设计好,模型不一定能稳定完成“找到文件—读取文件—筛选内容—回答问题”这整条链路。

所以 file-based 不是天然更优。它是适合处理大量搜索结果,但前提是 Agent 得可靠地使用文件工具。

噪声变多以后,结论不是简单线性的

实验 2 主要是在看另一个问题:当无关信息变多以后,grep 和向量检索的表现会怎么变化?

作者的做法是逐步加入更多无关对话,也就是增加噪声 distractor。这样一来,Agent 面对的就不再是比较干净的对话历史,而是更接近真实生产环境的长期记忆场景:里面有相关信息,也有大量和当前问题没关系的历史内容。

一般来说,我们可能会认为:语料小的时候 grep 好用;语料变大以后,向量检索会更有优势。但论文结果显示,情况没这么简单。

随着系统不断地加入无关的历史对话,grep 和向量检索并不是简单地一个下降、另一个上升。它们的表现会受到 Harness、模型和工具调用方式的共同影响。

图注:随着无关 session 增加,grep 和向量检索并不是呈现简单的线性变化。不同 Harness、不同模型下,二者的相对优势会发生变化。

如果再看表 2 和表 3 的详细数据,这种差异会更明显。比如在 full setting 下,有些组合里 grep 更高,有些组合里向量检索更高:

图注:表 2 和表 3 是实验 2 的详细数据。可以看到:噪声增加后,grep 和向量检索的优势并不固定,而是会随着 Harness 和模型变化。这个结果也说明,当无关信息变多时,问题不只是“资料有没有找对”,还要看 Agent 后面怎么继续搜索、怎么读结果、怎么判断哪些内容有用。

这篇论文没有给出一个简单结论:语料越大越该用向量检索,或者 grep 永远更稳。

它真正强调的是:Agent 搜索是一个系统问题。

论文的实践启发

这篇论文对日常开发最直接的提醒是:不要一上来就把向量检索当成唯一答案。

如果你的任务是查日志、查配置、查历史对话、查用户记录、查报错、查函数名,那么 grep、BM25、regex 这类词法检索仍然很值得保留。它们便宜、直接、可解释。在“答案本来就在原文里”的任务上,效果反而可能比一套复杂的检索链路更稳。

我们最好的选择,可能不是在 grep 和向量检索之间二选一,而是让 Agent 同时拥有两类工具。

比如,查明确字段、日期、错误码、函数名时,用 grep;查概念相近但表达不完全一致的内容时,用向量检索;遇到重要结果,再用 reranker 或让模型自己做二次判断。

另外,Harness 本身也要被认真评估。

很多时候,我们说一个 Agent “检索能力不行”,不一定是模型不行,也不一定是检索方法不行,可能是 Harness 没有把搜索工具设计好。工具描述、返回格式、上下文组织、文件读取方式、搜索结果截断策略,都会影响最后效果。

这也是论文标题后半句真正值得注意的地方:How Agent Harnesses Reshape Agentic Search。

Agent 搜索能力不是一个单点能力,而是由模型、检索方法、工具接口和 Harness 一起组成的。

一句话总结

这篇论文表面上是在比较 grep 和向量检索,但它真正讨论的是 Agent 搜索的系统设计问题。

在 Agent 场景里,检索方法当然重要;但同样重要的是,Agent 怎么调用搜索工具、怎么看到搜索结果、要不要继续查,以及最后怎么把资料整理成答案。

所以这篇论文给出的提醒可以概括成一句话:Agent 能不能找到答案,不只看它用了 grep 还是向量检索,也要看它所在的 Harness 有没有把搜索这件事设计好。

参考资料

  • LongMemEval https://github.com/xiaowu0162/longmemeval

  • Is Grep All You Need? How Agent Harnesses Reshape Agentic Search https://arxiv.org/pdf/2605.15184

← 返回列表