测了一下：给 Coding Agent 接 LSP 语义检索，不一定比 grep 好用

最近测了一下：给 Coding Agent 接一套基于 LSP 的语义导航（查引用、跳定义、列符号），跟平时常用的 grep 对比，看看到底哪个更好用、什么时候该用哪个。

用了 3 个 Claude 模型（ Opus 4.8 / Sonnet 4.6 / Haiku 4.5 ），几个 Python / TypeScript 仓库，测了定位代码、找全引用、多文件重命名三类任务。只有两种方法都跑成功的情况才拿来比 token ，避免半路失败的跑法看起来“省 token”。

几个实测下来的点：

• 简单定位代码的任务里，模型自己几乎不选 LSP （主动选择率 0%～ 6%）。强制先用 LSP ，这组任务成功率反而从 100% 掉到 89%。
• 找全部调用方的任务里，模型会主动选 LSP （ 45%～ 57%），精确率从 grep 的 0.76 提到 1.00 ，但两边的召回率都只有 0.66 左右——没漏查的问题，LSP 也没帮上忙。
• 同名文本越多的仓库，LSP 提升越明显：hono 这个仓库 grep 精确率只有 0.51 ，换 LSP 后 F1 +0.246 ，token 还省了 12%；干净的仓库（ remeda ）里 LSP 基本没用，token 反而多花 16%。
• 影响最大的一次改动，跟检索后端完全没关系：LSP 原来只返回文件路径和行号，模型得再开一次文件看代码；改成直接带上下文源码之后，多文件重命名的 pass@1 从 0.67 提到 0.83 ，多余的文件读取从 15.2 次降到 3.2 次，比纯 grep 的 4.3 次还少。

大概的结论是：LSP 好不好用，很看任务类型和代码库里同名文本多不多；工具返回内容的格式，有时候比检索后端本身对结果的影响更大。加新工具前，最好把“模型会不会主动用、任务有没有真的做完、返回格式够不够用”这几件事一起看，不能只看检索精不精确。

完整的任务设计、数据和结果分析写成了一篇博客： https://www.agentconnect.md/blog/grep-beat-lsp-harness/

任务定义、prompt 和原始结果在这个仓库： https://github.com/agentconnect-md/lsp-vs-grep-token-study

（ disclosure：这个测试是我们做 AgentConnect 过程中的一部分产出，AgentConnect 是一个用开放协议连多个 Agent 的工具，这里不展开介绍，只是说明一下背景。）