行业动态

过去两年，RAG几乎成了 AI应用获取外部知识的标准方案，代码助手也普遍通过向量索引和语义检索理解大型代码库。但随着 Claude Code、Codex、Cursor等 Agent型编程工具快速发展，传统的 Grep、Glob、文件读取和命令行搜索重新成为核心能力。表面看，这像是几十年前的文本工具“击败”了向量数据库；实际发生的变化更准确地说，是编程 Agent开始从单一语义检索转向按任务动态选择工具。

图片来源：cursor.com

Grep的优势首先来自代码本身的结构。开发者排查问题时，经常已经掌握函数名、错误信息、配置键、接口路径、类名或日志片段，这类查询不是在寻找“意思相近”的内容，而是在寻找精确出现的位置。正则表达式搜索可以快速返回匹配文件、行号和上下文，结果可验证、可重复，也不需要先把整个仓库切片、生成向量并同步索引。

Anthropic的 Claude Code文档直接把 Grep、Glob、Read和 Bash列为代码搜索与分析的基础工具，其中 Grep基于 ripgrep并支持正则表达式。OpenAI对 Codex的定位同样强调，Agent可以直接读取和编辑仓库文件、运行测试、代码检查器和命令行工具。它们共同体现出一种新的工作方式：模型不必在执行任务前一次性“理解整个仓库”，而是可以像工程师一样，先提出假设，再通过搜索、打开文件、追踪引用和运行测试逐步验证。

这也是 Grep在 Agent场景中格外有效的原因。传统聊天模型通常依赖系统预先准备上下文，检索系统必须提前猜测哪些片段最相关；Agent则可以连续行动，在第一次搜索结果不理想时改写关键词、缩小目录、扩大上下文，或者沿着导入关系继续追踪。检索不再只是一次向量召回，而成为推理过程中的多轮工具调用。

不过，把这种趋势概括成“RAG已经被淘汰”并不准确。Cursor的公开研究显示，它的 Agent同时使用正则搜索与语义搜索；在大型代码库和自然语言问题中，语义检索仍能明显提升准确率。例如，用户询问“身份验证在哪里处理”时，问题中可能没有出现仓库里的真实函数名，单靠字符串匹配很难直接定位。语义搜索可以先找到概念相关区域，再由 Grep、符号导航和文件读取完成验证。

两种方式解决的是不同问题。Grep更适合精确标识符、错误文本、配置项、日志、已知调用点和最近修改内容；语义检索更适合陌生项目探索、自然语言提问、跨文件概念定位，以及命名不一致的代码。符号索引和语言服务器则擅长定义跳转、引用关系和类型信息。成熟的代码 Agent不会在这些工具之间二选一，而会根据任务信号进行组合。

成本和时效也是工具选择发生变化的重要原因。向量检索通常需要代码切片、嵌入生成、索引存储和增量更新，仓库持续变化时还要处理索引新鲜度。文本搜索可以直接针对当前工作区执行，模型刚写入的代码立刻就能被检索到。对于短生命周期分支、本地项目、敏感代码库以及频繁修改的文件，这种即时性和可控性非常重要。

另一方面，超大型单体仓库中的全文扫描同样可能变慢，因此行业并不是简单回到最原始的 Grep。Cursor已公开介绍为正则搜索建立本地索引，以减少大仓库中的扫描延迟，同时保留结果的新鲜度和本地执行优势。这说明真正的演进方向不是“旧工具取代新技术”，而是把文本索引、语义索引、符号系统和 Agent推理整合成分层检索架构。

对开发团队而言，最实用的结论是不要把代码知识全部押在一种检索方式上。项目应保持清晰的命名、稳定的目录结构、可搜索的错误信息和完整测试，让 Grep能快速定位事实；同时为架构说明、业务概念和跨模块关系提供文档与语义索引。这样，Agent既能通过精确搜索验证细节，也能通过语义检索建立整体理解。

因此，Claude Code、Codex和 Cursor对 Grep的重视，并不意味着 RAG失败，而是说明 AI编程正在进入更工程化的阶段。代码 Agent的竞争重点，已经从“谁能塞入更多上下文”转向“谁能在正确时机调用正确工具，并用可验证结果完成任务”。Grep的回归，代表的不是技术倒退，而是检索策略从单一路径走向更务实的混合体系。

图片来源：cursor.com