代理搜索是执行环境问题

一篇 5 月 14 日发布的 arXiv 论文，在 Chronos、Claude Code、Codex 和 Gemini CLI 上，用 116 个 LongMemEval 问题测试了 grep 与向量检索。论文第一个实验中，内联 grep 在每一组框架-模型组合上都优于内联向量检索。但更重要、也更反常的发现是：执行环境对结果的影响，几乎和检索器本身一样大。¹

代理搜索质量并不只存在于“grep 还是向量检索”的二选一里。它存在于完整的执行环境中：提示词、工具接口、shell 交互体验、结果格式、上下文压力、交付路径、重试行为，以及模型完成工具调用闭环的能力。

摘要

Sen、Kasturi、Lumer、Gulati 和 Subbiah 比较了词法搜索与向量搜索。测试对象包括一个名为 Chronos 的自定义框架，以及 3 个提供商原生 CLI 框架：Claude Code、Codex 和 Gemini CLI。¹研究使用了包含 116 个问题的 LongMemEval-S 子集，并分别测试了内联工具结果和基于文件的工具结果。¹在实验 1 中，内联 grep 在所有框架-模型组合上都超过了内联向量检索；其中，Codex CLI 搭配 GPT-5.4 时，内联 grep 达到 93.1%，内联向量检索为 75.9%。¹这篇论文并没有证明 grep 总体上优于向量搜索。作者明确把结论限定在长记忆对话问答场景中，在这类任务里，答案往往依赖字面片段。¹对代理构建者而言，真正有用的结论更明确：检索方法、代理执行环境和结果交付方式构成一个系统。应该把它们放在一起做基准测试。

关键结论

• 对代理构建者：请把 grep 当作严肃基线。论文结果说明，在基于聊天历史的长记忆问答中，尤其涉及字面姓名、日期和用户事实时，“默认用向量检索”显得草率。¹
• 对 Codex 和 Claude Code 用户：不要把提供商 CLI 当作搜索原语外面的一层中性包装。论文报告显示，即使底层对话数据相同，不同框架也会带来显著差异。¹
• 对 RAG 团队：不仅要报告检索器，还要报告交付路径。内联结果与基于文件的结果会产生不同表现，因为文件交付又增加了一项工具使用任务。¹
• 对迁移工作：保留让搜索可靠的执行环境行为。从 Claude Code 迁移到 Codex 时，应先测试检索、会话记录形态和验证循环，再声明达到等效。
• 对大量依赖引用的系统：最终引用并不是完整的证据故事。另一篇 Agentic GraphRAG 论文指出，来源脉络可能取决于访问过但未引用的图上下文，而不只是最终引用的节点。⁴

这篇 grep 论文到底测试了什么？

论文提出的是一个很实际的问题：当 LLM 代理需要基于很长的对话历史回答问题时，检索效果有多大程度取决于搜索方法，又有多大程度取决于包裹它的代理系统？¹

作者比较了两类检索方式：

他们在两类执行环境中测试了这些检索器：

他们还改变了结果到达模型的方式。内联交付会把搜索命中直接插入对话。程序化交付则把结果写入文件，然后要求模型定位、打开并整合这些结果。¹听起来这只是实现细节。但数据表明，它本身就是任务的一部分。

为什么 grep 在这里赢了？

被测任务偏向字面恢复。LongMemEval 要求基于很长的多会话对话回答问题。许多答案依赖姓名、时间表达、个人事实或过去的原话。在这种场景下，高精度词法工具可以击败语义检索器，因为答案常常藏在一个很有辨识度的字符串后面。¹

论文表 1 清楚呈现了这一模式：

这张表并不是在说“删掉您的向量数据库”。论文自己也提醒不要这样解读。作者表示，他们的结论与长记忆对话问答场景绑定；在科学综合、视觉文档或代码语义等领域，稠密检索或混合检索可能会有不同表现。¹

更合理的解读是：在任何严肃的代理执行环境中，精确搜索都应该占有一席之地。如果您的代理能够搜索文件系统、读取日志、检查过往会话记录，或恢复一个字面的用户事实，词法搜索可能就是工具箱中成本最低、信号最强的工具。

执行环境改变了结果

论文里最有用的一句话不是“grep 赢了”。而是：更换框架所造成的上限变化，可能和更换检索器的影响处于同一量级。¹

一个例子是：Claude Opus 4.6 使用内联 grep 时，在 Chronos 下达到 93.1%，在 Claude Code 下只有 76.7%。¹同一模型家族，同一基准子集，不同执行环境。另一个例子是：Codex CLI 搭配 GPT-5.4 时，内联 grep 达到 93.1%；但当 grep 结果通过程序化文件交付路径传递时，准确率降到 55.2%；程序化向量检索则为 67.2%。¹

这不只是检索结果。这是执行环境结果。

模型要做的不只是找到证据。它还必须理解工具契约、选择搜索词、解释 stdout、决定何时重试、在结果非内联时读取文件，并把证据整合进答案。每一步都属于代理执行环境。只要其中一步变得脆弱，强检索器也可能产出弱答案。

为什么基于文件的交付是在测试工具使用能力

基于文件的交付有明显吸引力。它可以把大量搜索结果留在即时会话记录之外，直到模型主动请求读取，从而降低上下文压力。当内联向量检索输出挤占窗口时，这本应有所帮助。

论文展示了其中的取舍。程序化向量检索在多组结果中超过了程序化 grep，这支持了上下文压力这一解释。¹但 Codex/GPT-5.4 这一行也展示了另一面：文件交付会把廉价检索变成多步骤工作流。代理必须找到产物、打开它、提取有用片段，并在第一次读取不够时重试。¹

也就是说，程序化交付用上下文带宽换取工具循环能力。只有当执行环境能够可靠完成闭环时，这笔交换才划算。

这对真实工作很重要。本地代理的搜索失败，不只是因为索引错了。它也可能因为 stdout 分块不佳，因为结果文件路径很容易漏看，因为命令返回了太多噪声，因为提示词把任务框定错了，或因为模型少读了一次就停止了。

这对 Codex 迁移意味着什么

我自己的 Claude Code 到 Codex 迁移，一直把重点放在迁移操作契约，而不是复制文件树。这篇论文强化了这一选择。

如果搜索质量取决于执行环境，那么迁移质量就不只是“Codex 有没有搜索工具？”迁移必须保留那些让搜索有用的行为：

• 代理知道什么时候应先用精确搜索，再用语义搜索；
• 命令输出足够小，能够被读完；
• 证据路径能进入最终答案；
• 基于文件的产物易于定位和检查；
• 搜索失败会触发更好的查询，而不是过早给出答案；
• 公共写作使用来源验证，而不是看似合理的检索结果。

这份清单有意保持公开和通用。它不披露私有钩子、私有提示词或本地工作流内部细节。重点在于操作契约：让代理证明它找到了什么，而不是仅仅对自己执行的搜索显得信心十足。

这篇论文也解释了为什么一次迁移可能在所有显眼功能都存在时仍然感觉变差。Claude Code 和 Codex 可能都暴露 shell 工具。两者都可能读取文件，也都可能搜索。但如果会话记录格式、文件结果处理、停止行为或重试模式不同，同一个搜索原语就可能产出不同的工作结果。

另外三个信号指向同一方向

同一次扫描中，另外三篇 5 月 14 日的论文也指向同一个更大的模式：代理质量正在从孤立模型调用转向执行环境架构。

APWA 把高度并行的代理工作视为分布式执行问题。作者把工作流分解为互不干扰的子问题，让独立资源无需交叉通信即可处理，然后在更大任务上评估扩展能力；这些任务是先前系统会失败的地方。²这是执行环境主张，不是提示词技巧。

MeMo 把记忆视为独立的模型组件。它保持执行 LLM 固定，把新知识编码进专门的记忆模型，并报告其具备抗检索噪声能力，同时可即插即用地兼容开源与闭源 LLM。³这是记忆架构主张，不是更长上下文主张。

Agentic GraphRAG 溯源论文认为，最终引用可能必要但不足。准确答案可能依赖未引用的遍历上下文、图结构，以及访问过但未引用的实体。⁴这是来源脉络主张，不是引用格式主张。

把这些与 grep 论文放在一起，会出现一个清晰轮廓：

共同主题是：包装层就是产品。执行环境决定模型能力能否变成有用工作。

我会如何调整代理技术栈

从朴素基线开始。给代理提供针对关键文件、日志、会话记录或笔记的精确搜索。在加入语义检索之前，先测量它的效果。

然后测试 4 种组合，而不是 2 种：

记录每次运行的工具会话记录。最终答案不够。您需要知道代理是否搜索了正确的词、打开了正确的文件、注意到了正确片段、在漏检后重试，并引用了真正支撑答案的证据。

当领域需要恢复改写表达、做概念综合，或处理非字面证据时，再加入向量搜索。当领域包含姓名、ID、文件名、日期、日志行、命令输出、用户偏好或历史指令时，保留精确搜索。任务同时混合两者时，使用混合路由。

对公共写作而言，检索路径应更严格。一篇带引用的文章应该保留来源 URL、主张与来源的对齐关系，以及仍未验证的记录。如果系统使用了图、记忆层或中间检索路径，最终引用不应是唯一痕迹。溯源论文是在 Agentic GraphRAG 场景中提出这一点，但产品层面的教训适用范围更广：证据应解释路径，而不仅是终点。⁴

更好的基准问题

薄弱的基准问题是：

哪个检索器更好？

更强的问题是：

在这个执行环境、这个模型、这个语料库、这条交付路径和这套重试策略下，哪种搜索行为能产出经过验证的答案？

这个问题回答起来更慢。但它也更有用。

代理工作不断诱使人们提出组件级主张：更好的模型、更好的检索器、更好的提示词、更好的记忆、更好的并行能力。运行现实却不断把方向推回去。只有当执行环境把组件能力转化为从任务到证据再到行动的可靠路径后，组件才真正有意义。

这才是值得迁移的部分。

FAQ

这篇论文证明 grep 优于向量搜索吗？

没有。作者明确把结果限定在研究中的长记忆对话问答场景。他们指出，在证据很少以字面形式出现的领域，包括科学综合、重视觉文档和代码语义，稠密检索与混合路由可能会有不同表现。¹

为什么 grep 在实验中表现这么好？

LongMemEval 问题经常依赖过去对话中的字面片段：姓名、日期、个人事实和原话。当代理能够猜到具有辨识度的词时，grep 会奖励这种高精度模式。¹

为什么框架会有影响？

执行环境控制提示词形态、工具描述、会话记录格式、shell 行为、上下文构造、结果交付和停止条件。论文报告显示，即使底层对话数据保持不变，Chronos、Claude Code、Codex CLI 和 Gemini CLI 之间仍出现了显著准确率差异。¹

Codex 用户应该怎么做？

保留精确搜索作为基线，检查工具会话记录，并在假定某种检索方法更好之前，测试内联交付与基于文件的交付。论文中的 Codex 结果很有参考价值，但它仍然只是一个基准设置、一种语料类型，并且不是完整的供应商级扩展图景。¹

这和 RAG 引用有什么关系？

Agentic GraphRAG 溯源论文认为，最终引用可以支撑答案，但仍可能省略影响答案的检索上下文。对代理系统而言，引用质量应包含路径层面的来源脉络，而不仅是最终引用来源列表。⁴

从 Claude Code 迁移到 Codex 时应该保留什么？

保留操作行为：代理何时搜索、如何限制输出、如何打开证据、如何重试、如何记录来源路径，以及如何拒绝无依据的主张。不要因为两个环境都暴露 shell 和搜索命令，就假定它们已经等效。

参考文献