Grep 打败向量检索：编码代理搜索新范式

一篇新论文本周在 AI 开发者圈引发热议：研究发现，用 grep 风格的文本搜索包裹在合适的代理宿主层中，在编码代理任务上的表现可以匹敌甚至超越基于嵌入向量的检索方案。

Omarsar0 在推荐这篇论文时措辞强烈，他直接质疑向量数据库在代理搜索场景中的必要性："AI 开发者请注意这篇文章。他们发现 grep 风格的文本搜索，在合适的代理宿主层包裹下，能够在编码代理任务上匹配或击败基于嵌入的检索。编码代理需要的可能不是更好的嵌入，而是围绕原始工具做更好的宿主层设计。如果你的编码代理栈依赖向量数据库，也许是时候重新评估了。"

@omarsar0: "They find that grep-style text search, when wrapped in the right agent harness, matches or beats embedding-based retrieval on coding-agent tasks. Are vector databases even needed where this is all going?"

DAIR.AI 的 @dair_ai 也以简洁的方式呼应了这一发现，称其为 "一篇很棒的文章，讨论了代理搜索 vs 向量搜索"。

而信息检索领域的权威学者 Lin 则半开玩笑地总结了一个 "双参数模型" 论点：代理搜索的双参数模型叫 BM25，零参数版本是 grep。

@lintool: "Since we're counting model parameters, let me introduce you to a two-parameter model for agentic search that's awesome: It's called BM25."

与这一方向形成互补的是 Cloudflare 生态中的一条实操数据。Yoni Braslaver 在实际的 monday.com GraphQL API 上做了一个对比实验：使用 SDK 方式仅需 1 步、15K tokens；而使用真实的 MCP 服务器需要 4 步、158K tokens——同样的输出，token 成本相差 8.4 倍。

@YoniBraslaver: "SDK: 1 step, 15k tokens. Real MCP server: 4 steps, 158k tokens. 8.4× the cost, same output."

这两条发现指向一个共同的趋势：当前代理工具的臃肿抽象层（无论是嵌入向量系统还是 MCP 工具调用协议）在效率和成本上可能远不如简单直接的原始工具调用。对于追求极限效率的编码代理场景，回归 grep、BM25 和直接代码调用正在成为一种反直觉但经验证有效的选择。

分类：📊 研究/论文

本作品采用《CC 协议》，转载必须注明作者和本文链接