一项针对 Coding Agent 代码检索方式的实测研究显示，为 Agent 接入基于 LSP 的语义导航（查引用、跳定义、列符号）并不一定优于传统的 grep 搜索。研究使用 Opus 4.8、Sonnet 4.6、Haiku 4.5 三个 Claude 模型，在多个 Python 和 TypeScript 仓库上测试了定位代码、查找全部引用、多文件重命名三类任务，且仅统计两种方法均成功的情况以公平对比 token 消耗。结果显示：在简单定位代码的任务中，模型几乎不主动选择 LSP（主动选择率 0% 至 6%），强制使用 LSP 反而使成功率从 100% 降至 89%；在查找全部调用方的任务中，模型主动选择 LSP 的比例为 45% 至 57%，精确率从 grep 的 0.76 提升至 1.00，但两者的召回率均只有约 0.66。实验还发现，代码库中同名文本越多，LSP 的收益越明显：hono 仓库的 grep 精确率仅 0.51，改用 LSP 后 F1 提升 0.246 且节省 12% token；而在代码命名干净的 remeda 仓库中，LSP 基本无效，token 反而多消耗 16%。影响最大的改动与检索后端无关：将 LSP 返回内容从文件路径和行号改为直接附带上下文源码后，多文件重命名 pass@1 从 0.67 升至 0.83，多余文件读取从 15.2 次降至 3.2 次，低于纯 grep 的 4.3 次。研究的结论是，LSP 的效果取决于任务类型和代码库特征，而工具返回内容的格式，有时比检索后端本身对结果的影响更大。
事件分析
这项研究用量化数据揭示了 Agent 工具生态中容易被忽视的问题。模型在简单任务中自发绕开 LSP，说明其已具备一定的工具成本判断能力；而两种方法的召回率几乎持平，暗示语义级检索并未解决遗漏调用的根因。返回格式改动带来的提升幅度超过更换检索后端，对 MCP 等工具协议的设计具有直接参考意义——工具接口应尽量减少 Agent 的后续操作步骤，一次返回足够上下文。产业层面，随着 AI 编程工具竞争加剧，’给 Agent 配什么工具、怎么配’正在成为与模型能力同等重要的工程问题。相应的评估体系也需要从单一检索精度，转向端到端任务完成率、模型主动选择率与 token 成本的综合衡量，这对工具开发者的产品设计思路是一种纠偏。
核心观点：给 Agent 配工具，返回格式与任务场景的匹配度，比检索后端的精确度更决定成败。
原文链接：V2EX 分享发现
