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

最近测了一下：给 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 次。

大概的结论是：LSP 好不好用，很看任务类型和代码库里同名文本多不多；工具返回内容的格式，有时候比 检索后端本身对结果的影响更大。

完整的任务设计、数据和代码： GitHub - agentconnect-md/lsp-vs-grep-token-study: Does a language server save tokens for coding agents? A measurement study of LSP (semantic) vs grep (lexical) retrieval for LLM agents. · GitHub