Agentic Search 重构：用 Grep 模式检索替代重型向量搜索的工程实践

从向量优先到词汇优先的范式转移

过去两年，RAG（检索增强生成）架构几乎等同于 "向量化一切"—— 文档切片、嵌入模型、向量数据库、余弦相似度搜索。这套流程在简单问答场景下表现尚可，但随着 Agent 能力进化与上下文窗口扩容，其瓶颈日益凸显。今天的 Agent 通常配备多种检索工具，根据查询意图动态选择调用路径，RAG 不再是唯一答案，而是工具箱中的一员。

这一转变的核心在于查询理解层的前移。早期 RAG 将查询理解推给向量存储，由它返回 top-k 相似候选，生成模型仅充当总结器。而现代 Agentic Retrieval（尤其是 Claude Sonnet 4.5 等模型发布后）由模型 upfront 处理查询分解，跨多个系统并行检索，再统一重排序。这个过程往往是迭代的：Agent 判断检索结果是否充分，决定是否需要回退补充。

为什么 Grep 正在击败向量数据库

Shaped.ai 的观察揭示了一个反直觉的事实：grep arguably 是当前主导的检索系统。Cursor 和 Claude Code 等代码 Agent 的内部实现严重依赖 grep 进行代码库检索。这并非因为 grep "优于" 向量存储，而是因为它在特定场景下无摩擦、确定性、即开即用。

代码本质上是词汇性的。当需要定位特定变量、函数名或文件路径时，精确字符串匹配正是所需。配合 LSP（Language Server Protocol）查找引用和遍历代码结构，即使面对大规模代码库，语义索引的收益也有限。

性能数据印证了这一点：GrepRAG 的实证研究显示，在大规模代码库中，基于 ripgrep 的词汇检索延迟约为 0.40 秒 / 检索，而传统基线方法需要 3-7 秒，延迟降低了一个数量级。对于需要频繁工具调用的 Agent 系统，这种差距直接决定了交互流畅度。

向量搜索的运营负担

构建传统向量数据库的 Agent 应用是一项运营噩梦。工程师必须：

• 选择嵌入模型：权衡本地模型的延迟与 API 方案的成本和速率限制
• 设计分块策略：对字符数、递归标题、重叠百分比做出任意且脆弱的决策
• 构建同步管道：确保 GitHub 仓库文件变更或 Slack 消息发送时，向量存储能更新而不产生重复或陈旧索引

grep 完全规避了这些问题。它是确定性的、即时的，配合百万级 token 上下文窗口，可直接将原始结果灌入，让模型的注意力机制承担重活。

Agent 作为数据架构师

更激进的视角是：Agent 不应只是数据基础设施的 "用户"，而应成为数据架构师。传统上，人类选择一种数据基础设施，一次性索引数据，系统即被锁定，本质上是状态无关的（stateless）。但如果给 Agent 一个沙盒，让它端到端负责解决检索问题，数据基础设施就变得状态化且高度动态。

想象一个 Agent 被投入全新代码库。最初几次查询，它可能只用 grep。但随着工作推进，它发现反复搜索的关系依赖正在吞噬上下文窗口。此时 Agent 不是报错或盲目继续 grep，而是编写脚本解析 AST，提取关系，在沙盒中启动临时知识图谱；或者被问及仓库文档的宽泛概念问题时，自主决定将特定 markdown 文件嵌入，启动轻量级本地向量索引。

在这个世界中，索引不再是静态产物。每个进入的查询都定义了内部数据系统如何被改进。Agent 利用对先前查询的认知和遇到的瓶颈，持续优化数据存储方式以服务于后续查询。

三层 Agentic 检索架构

为实现这一目标，底层基础设施必须从刚性预配置孤岛转变为灵活构建块：

第一层：Ephemeral Sandboxes（临时沙箱）—— 本地进程级原语（DuckDB、SQLite、内存 FAISS、AST/LSP、grep）。并非所有数据都需要持久存储。这一层充当 Agent 的草稿本。当 Agent 进入新仓库解决问题时，它需要能够通过 MCP（Model Context Protocol）等协议启动临时基础设施。可能将关系数据子集转储到 DuckDB，或为近期日志构建内存向量索引，执行单会话复杂查询，任务完成后直接销毁。

第二层：Specialized Stores（专业存储）—— 分布式扩展对应物（Pinecone、Elasticsearch、Neo4j）。这些是上述本地原语的分布式表亲：Pinecone 是内存 FAISS 的规模化归宿，Elasticsearch 是 grep 的分布式对应物，Postgres/Supabase 是 SQLite 的持久化多租户版本。当 Agent 需要诊断涉及历史客户支持工单索引的问题时，临时沙箱无法胜任，需将数据路由到这些重型工具。

第三层：Unified Orchestration & Routing（统一编排与路由）—— 连接组织（Shaped、Mem0、统一 API 网关）。关键特性是它不位于分布式层之上逐层传递请求，而是通过相同的声明式接口同时触及本地沙盒和分布式存储。Agent 可以查询单进程 DuckDB 草稿本和多节点 Pinecone 集群而不必关心差异。

混合策略的工程实践

纯粹依赖 grep 显然不是银弹。自主 Agent 经常写出糟糕的正则，或意外搜索庞大的 node_modules 文件夹，用垃圾数据淹没上下文窗口。依赖超大上下文窗口既昂贵又缓慢，强制前沿模型迭代解析 50 万 token 原始文件输出会烧穿 API 额度并飙升延迟，同时增加 "lost in the middle" 风险。

可落地的混合策略包括：

1. 分层过滤：先用 grep 快速缩小候选范围，再用向量相似度精排，将检索时间从数秒降至零点几秒
2. 工具选择逻辑：Agent 根据查询特征动态选择检索工具 —— 精确字符串匹配用 grep，概念性检索用向量，关系查询用图数据库
3. 上下文预算管理：设定 token 预算上限，grep 返回结果超出预算时触发摘要或二次过滤
4. 渐进式索引：Agent 在工作中识别重复查询模式，自主决定构建临时索引（如 AST 关系图、markdown 向量索引）以优化后续检索

风险与限制

• 正则复杂性：Agent 生成的正则表达式可能低效或错误，需要沙盒限制搜索范围（如排除 node_modules、.git 目录）
• 语义鸿沟：纯词汇检索无法处理同义词、改写或概念相似性，必须保留向量搜索作为概念检索的后备
• 上下文污染：grep 返回的大量原始文件内容可能淹没模型注意力，需要智能截断或结构化呈现
• 状态管理：Agent 自主构建的临时索引需要生命周期管理，避免沙盒泄漏或资源耗尽

结语

信息检索正从静态管道转向动态决策树，而导航这棵树的主体正在从人类工程师转向 Agent 本身。grep 的复兴不是技术倒退，而是模型对无摩擦、动态、按需数据访问需求的体现。

作为人类工程师，我们的角色不再是构建完美索引，而是构建沙盒—— 提供声明式、身份感知的路由层，处理 ETL 和同步的机械琐事，让 Agent 成为一等开发者，自主构建它们所需的精确内存，查询接查询。

参考来源

• Shaped.ai: "Why grep is beating your Vector DB" (2026)
• arXiv: "GrepRAG: An Empirical Study and Optimization of Grep-Like Retrieval for Code Completion"
• arXiv: "Is Grep All You Need? How Agent Harnesses Reshape Agentic Search"

ai-systems