【文章标题】：Grep击败LSP？为何编程智能体无视你的高级工具
【文章正文】： 我在代码查找与编辑任务中对比了grep与基于LSP的语义导航工具。结果表明，工具的LLM友好度可能与其功能本身同等重要。 为何编程智能体会忽略返回更精确结果的检索接口？ 我通过小型研究对比了基于grep的词汇搜索与LSP语义导航。原以为语义导航能减少干扰并节省token，但智能体往往坚持使用grep。当我强制其优先使用语义路径时，任务成功率反而下降。 这本质是LLM友好度问题。工具不能仅因结果精确就被视为模型友好，它必须为后续步骤提供充足上下文，并以模型可直接使用的界面和输出形式呈现。熟悉度也很重要：模型可能在训练中习得了类似操作路径。界面特性可直接评估，而训练支持则是符合结果的假设（非本实验结论）。 结论并非全盘否定LSP。该协议功能远超代码导航，本研究仅测试了极小部分。结果揭示了更广泛的工程问题：模型并非孤立使用工具，而是通过定义可用操作、命名、输入及返回上下文的框架来调用。 本文阐述代码检索如何影响查找与编辑任务，grep的优势场景，及其对智能体平台的启示。 我对比了两种代码检索方式：grep执行词汇搜索（匹配文本），测试的LSP工具则通过引用、定义和文档符号进行语义导航，能区分真实函数调用与注释中的相同词汇。 实验涵盖三个Claude模型、多个Python/TypeScript代码库及多种任务类型。仅当两种方法都成功时才统计token用量，避免”因提前终止而看似高效”的评估误差。 简单定位任务中，当两种工具可用时，三个模型选择语义工具的概率仅0%-6%。强制语义优先路径使成功率从100%降至89%。 引用完整性任务结果不同。当要求查找所有调用者时，模型选择语义导航的概率达45%-57%。LSP路径精度达1.00（grep为0.76），但两者召回率均为0.66左右。语义导航并未发现更多真实调用，限制因素在于智能体工作深度而非检索精度。对强模型而言，精度提升还伴随token用量增加而非节省。 模型并非盲目偏好grep——它会根据任务路由 当grep和LSP均可自由选择时，语义(LSP)工具的调用占比： 图例：Opus 4.8(蓝)、Sonnet 4.6(洋红)、Haiku 4.5(绿)
| 任务类型 | Opus 4.8 | Sonnet 4.6 | Haiku 4.5 |
|---|---|---|---|
| 定位任务 | 0% | 4% | 6% |
| 引用完整性任务 | 45% | 50% | 57% |
| 多文件重命名 | 3% | — | — |
| 代码库质量同样关键。在整洁的TypeScript仓库中，LSP导航未提升F1分数且多消耗16%token；在杂乱仓库中则提升F1分数0.246并节省12%token。预测指标是词汇干扰度，而非语言是否强类型。 | |||
| 代码库杂乱度决定语义导航价值 | |||
| 语义检索在引用完整性任务中的准确度增益(ΔF1 = LSP−grep)。柱色表示grep在该库的杂乱程度；prec=grep精度 | |||
| 图例：蓝色表示grep结果干净，洋红表示杂乱 | |||
| 代码库 | 语言 | grep精度 | ΔF1(LSP−grep) |
| ---------- | ----------- | ---------- | --------------- |
| remeda | TypeScript | 1.00 | +0.000 |
| hono | TypeScript | 0.51 | +0.246 |
| requests | Python | 0.76 | +0.072 |
| 这些结果是条件性的而非绝对。智能体并非”总是用grep”，其路由策略随任务改变，LSP导航价值也随代码库变化。 | |||
| 测试的LSP工具最初仅返回位置信息（文件路径+行列号），智能体需额外打开文件查看代码。而grep通常直接返回匹配行：src/auth.ts:42: return validateToken(token)。 | |||
| 我将语义导航响应改为包含类似格式的源码文本（语义后端和引用集不变，仅改变返回给模型的信息）。重命名任务的Pass@1… |