Grep 击败 LSP:Coding Agent 为什么反而偏好最朴素的搜索工具 · 重庆智能体开发 · 行业资讯

2026 年 AI Coding Agent 工具链里出现了一个有意思的反转:几乎所有主流 Agent——Claude Code、Codex、Cursor、VT Code、Outline Driven Development——都默认把 grep/ripgrep 作为代码搜索的主力工具,而不是更"现代"的 LSP(Language Server Protocol)。LSP 一直被视作 IDE 时代的代码智能底座,理论上能解决 ripgrep 在真实代码库里"找不到跨模块引用、不能预览重构、不理解代码结构"的痛点;但现实是,Agent 工程师们反复回到 ripgrep,在它上面自己组合更复杂的语义层,而 LSP skill 直到 2026 年初才被专门做成"Agent 友好"的封装。LSP Skill 的开发者直接在 Show HN 里承认:"AI coding agents today use grep/ripgrep for code search. This fails on real codebases."——然后他们才去做 LSP 集成。这件事的工程含义在于:Coding Agent 工具链的演化路径,不是用 LSP 替换 grep,而是让 grep 在 Agent 工作流里被用对方式。下面是这个反转让企业 Agent 落地得到的 10 个具体启示。

1. Grep 之所以胜出,因为它够简单

Grep/ripgrep 在 Agent 时代重新成为首选,根本原因是它的接口极其简单——输入一个正则、一个文件列表,输出匹配的行。这个简单性带来三个 Agent 特别看重的特性:可预测(Agent 能精确预期 grep 会返回什么)、可组合(grep 可以和其他 shell 命令任意串接)、易描述(Agent 在内部推理时能用自然语言清晰描述 grep 命令的目的)。LSP 协议则相反——一个 LSP 调用可能涉及 server 生命周期、workspace 上下文、symbol 类型、range/position 等多个维度,Agent 需要 10 次以上 round-trip 才能拿到一个真正能用的答案。

这件事对企业 Agent 工具链设计的启示是:工具越简单、越像基本原语,Agent 越能用好。一个工具的"能力密度"高不等于 Agent 用得更好——Agent 真正需要的是"每次调用都能直接得到下一步推理所需信息"的工具,而不是"理论上一个调用能做一切"的工具。这是 Agent 友好工具设计的反直觉点。

2. LSP 不是不好用,是 LSP 集成对 Agent 不友好

LSP Skill 在 Show HN 里点出了关键问题:Agent 集成 LSP 的现有方案(Serena、cclsp、Claude Code LSP 等)只是把 LSP 端点直接暴露给 Agent,Agent 需要 10+ 次 round-trip 才能拿到一个答案。LSP 协议本身是为人类 IDE 设计的——IDE 后台维护大量状态(symbol table、type information、workspace context),用户触发操作时 IDE 翻译成 LSP 调用。但 Agent 没有 IDE 那种持久状态,LSP 的优势被它的协议复杂度抵消了。

这个观察的更深含义是:任何为人类设计的接口,在被 Agent 直接消费时都会变得笨拙。LSP 是为人类 IDE 优化了 10 年的协议,但 Agent 不是人类 IDE,它的"用户界面"是自然语言推理,而不是点击、补全、跳转。这对企业做"接口升级"的启示是:不要把人类工具直接暴露给 Agent,要为 Agent 重新设计一层抽象,把底层能力重组为 Agent 友好形态。

3. AST-grep 是 ripgrep 之后的关键拼图

Outline Driven Development(ODD)项目的做法揭示了 ripgrep 在 Agent 工作流里的下一步演化方向:把 ripgrep 与 AST-grep 组合——ripgrep 做文本层搜索,AST-grep 做结构层搜索。两者都用 Rust 实现、性能一致,但 AST-grep 能理解"匹配某个 AST 节点类型的代码",比如"找出所有调用 super().__init__() 的方法定义",而不是简单的文本模式匹配。这种"文本 + 结构"的双层搜索,在真实代码库里能解决 ripgrep 单独的痛点。

VT Code 的开发者公开了类似做法:用 ripgrep 做传统的 grep,用 ast-grep 做语义代码搜索。两者并存,Agent 根据任务选合适的工具。这种"工具各管一摊、Agent 编排使用"的模式,比"用一个大而全的工具替代多个小工具"更适合 Agent 工作流。

4. Cursor 砍掉 embedding-based 索引的工程意义

OpenAI 在 2026 年 9 月的"关于 SpaceX 收购 Cursor 后的决定"文章里,有一段关于 Cursor 自身演化的关键描述:Cursor 似乎是有意砍掉了基于 semantic embedding 的代码库索引,他们的解释是,更新的 coding agent 已经好到可以直接搜索仓库——并行 grep、检查目录、读最可能的文件、Agent 自主精炼搜索。Cursor 说这种新方式在大多数场景下效果一样或更好。架构上从"chunk → embed → 向量库 → 检索"变成"本地搜索索引/ripgrep → Agent 探索"。索引仍然存在,但只是一个传统搜索索引,而不是向量索引。

这条事实对企业 Agent 工具链建设有巨大意义。2024、2025 年很多人(包括我自己在内)默认"Agent 时代的代码搜索一定要走 RAG/embedding 路线",因为传统 grep 在跨模块引用、抽象语法层面有局限。但 Cursor 的实战说明,这条路在大多数 Agent 工作流里并不优于"grep + Agent 自主精炼"。原因是 Agent 的推理能力能弥补 grep 的浅层,只要 grep 跑得快、可组合,Agent 就能用多次调用拼出近似"语义搜索"的效果。

5. Agent 工具链的选择要看 Token 与延迟,不是看"理论能力"

VT Code 在 README 里直接说"语义上下文理解由 ast-grep 提供结构化代码搜索,ripgrep 提供传统 grep"。这两种工具都用 Rust 写,性能是 native 的,对 Agent 来说调用成本(延迟、Token)极低。LSP 即使封装得再好,启动一个语言服务器、维持状态、回答跨模块查询的延迟与 Token 成本,都显著高于 ripgrep 的简单 grep 调用。这对企业选型有直接含义:工具的"理论能力"重要,但对 Agent 来说,"每次调用的成本"更重要,因为 Agent 的工作流是大量小调用组成的。

这条原则对企业 IT 团队的启示是:任何"理论上一个调用能做所有事"的工具,都不一定是 Agent 工作流的最优选。在 Agent 时代,工具选型应该看"每次调用的延迟、Token、可预测性",而不是"理论能力密度"。一组可组合的简单工具,通常优于一个"理论能力很强但调用成本高"的复杂工具。

6. Grep 不是简单文本匹配,而是 Agent 的"代码探针"

Supabase 团队在 2026 年 4 月做了一个很有意思的实验:把 Supabase 文档以 markdown 文件形式挂在一个 SSH server 上,然后让 Agent 用 ssh supabase.sh grep -rl 'RLS' docs 这种命令去探索文档。这件事把 grep 从"代码搜索工具"提升为"任意文件集合的检索探针"——只要数据能转成文件,Agent 就能用 grep 这种最朴素的方式去探索。

这条思路的产业意义是:Agent 时代的"知识检索"未必需要 RAG。文件 + grep + Agent 自主探索,这种极其朴素的方式在很多场景下比 embedding 检索更可控、更可调试、更易部署。这对企业"内部 Agent + 内部知识"场景的启示是:不要急着上向量数据库,先把知识整理成 markdown 文件 + 教 Agent 用 grep 探索,这套轻量级方案往往就够用。

7. 为什么 LSP skill 直到 2026 年才出现

LSP 协议本身在 2016 年就被 Microsoft 提出,2018 年开始普及,十年间被所有主流 IDE 采用。但"为 Agent 设计的 LSP skill"直到 2026 年初才出现,中间有八年时间。原因不是工程师没想到,而是 Agent 在那之前不够强——当 Agent 的代码推理能力还弱时,LSP 提供的语义信息确实有不可替代的价值;当 Agent 推理能力变得够强(尤其是 Sonnet、Opus、GPT-5 系列),LSP 的边际收益开始下降,而它的协议复杂度成本开始凸显。

这件事对企业技术选型的时间维度的启示是:今天选 Agent 工具链时,要考虑模型能力随时间的演化。今天 Agent 不能用好的工具,可能 6 个月后就能用好;今天 Agent 用着别扭的工具,可能 1 年后就会被新的封装替代。Agent 工具链的选型应该是有"演化时间观"的——不是"今天最强",而是"未来 1-2 年最有演化空间"。

8. 不同任务用不同工具,不要追求"一招鲜"

Outline Driven Development 提出的方案是"在每个 Agent 任务里,根据任务性质选用合适的本地工具"。简单搜索用 ripgrep,结构搜索用 ast-grep,文件浏览用 fd,差异查看用 git-delta,代码统计用 tokei。每种工具管自己最擅长的领域,Agent 在编排层组合它们。

这对企业 Agent Harness 建设的启示是:不要试图让一个工具替代所有事情。"通用大工具"听起来诱人,但在 Agent 工作流里往往输给"工具各管一摊 + Agent 编排"。这是 Unix 哲学在 Agent 时代的回归——小工具、可组合、Agent 当协调器。企业在搭 Agent Harness 时,应该把"工具集的广度与质量"放在"单个工具的能力"之上。

9. Grep 的天然优势:跨语言、跨项目、零配置

Grep 在 Coding Agent 时代重新被青睐,还有一个不起眼但很根本的原因:它跨语言、跨项目、零配置。在一个多语言 monorepo 里,LSP 需要为每种语言起一个 server,有时还要协调它们的 workspace;而 ripgrep 一次扫描就能把整个仓库当作文本,无论里面是 Python、TypeScript、Go、Rust 还是配置文件。对 Agent 来说,这种"零配置通用"是关键优势——Agent 不需要知道目标项目用什么语言,它只需要会调用 grep。

这条特性对企业 Agent 落地的启示是,在跨语言、跨项目的工作流里(比如多 monorepo、polyglot 代码库),优先选通用工具而非专用工具。专用工具在单一场景里更强,但它们的复杂度会拖慢 Agent 的推理。Agent 工具链的"通用底座"应该尽量简单,让 Agent 的推理负担放在业务逻辑而不是工具调用上。

10. Grep 与 LSP 未来会共存,但比例会变

Grep 在 2026 年击败 LSP,不代表 LSP 没有未来——Cursor 自己仍然保留了一个本地搜索索引;LSP Skill 把 LSP 封装成 Agent 友好形态;Serena、cclsp 等仍在演化。更可能的演化路径是:grep/ripgrep 仍然是 Agent 工具集的"默认底座"(占 70%-80% 的调用),LSP skill 在某些场景下提供高价值补充(占 20%-30% 的调用),AST-grep 这类"结构感知 grep"在两者之间补位。

对企业的启示是,今天的 Agent Harness 建设不要做"非此即彼"的选择。grep/ripgrep 应该是默认就位的工具,LSP skill 作为可选增强,AST-grep 作为结构补充。工具集的层次应该是"通用 → 半结构 → 完全语义",Agent 根据任务类型选择层次。这是从"工具替代"走向"工具组合"的工程纪律。

从 Grep 视角看 Agent Harness 工程

Grep 击败 LSP 这个反转,折射出 Coding Agent 工具链的真正演化方向:不是"找最强工具",而是"找最适合 Agent 工作流的工具"。Agent 的工作流特征是大量小调用、需要可预测性、需要可组合性、需要零摩擦接入。LSP 输在协议复杂度,grep 胜在接口简单。这对企业 Agent Harness 建设的工程纪律有三条具体含义。第一,工具选型看调用成本(延迟、Token、可预测性),不看理论能力密度。第二,工具集应该是 Unix 哲学(小工具、可组合、Agent 协调),而非"大一统工具"。第三,工具集要分层(通用、半结构、完全语义),Agent 根据任务类型选层次,而不是强求一站式方案。

这条工程纪律的更深意义在于:Agent 时代的工具设计哲学应该回到 Unix 哲学,而不是继续堆叠"超级工具"。Cursor 在砍掉 embedding-based 索引、Outline Driven Development 强调 AST-grep + ripgrep + fd + git-delta 的组合、LSP Skill 把 LSP 封装成 Agent 友好形态——所有这些工程选择都在指向同一个方向:Agent 不需要"每个调用都很强大"的工具,Agent 需要"每次调用都恰到好处"的工具。Grep 的胜利就是这个原则的最朴素证明。