2026 年 8 月,AgentConnect 博客发表了一篇标题颇有挑衅意味的工程实测文章——"Grep beats LSP? Why coding agents ignore your fancier tools"。作者 Pengcheng Xu 在 Claude Opus 4.8、Sonnet 4.6、Haiku 4.5 三个模型上对比了纯 grep 类正则搜索与基于 Language Server Protocol 的语义导航工具,跑了一组覆盖定位、重命名、引用完整性、多文件编辑的实测任务。结果相当反直觉:在简单代码定位类任务上,三个模型使用 LSP 语义工具的比例只有 0% 到 6%——它们几乎一致选择了 grep;在引用完整性任务上,语义工具的采纳率才升到 45%-57%;在多文件重命名任务上,即使强制让模型先用语义路径,pass@1 反而从 100% 掉到 89%。这篇文章的结论——"工具对 LLM 的友好度,可能比工具背后的能力更重要"——值得所有正在做 Coding Agent 工具链、Harness、Skill 平台的工程团队认真读一遍。它把一个长期被低估的问题推到了台前:模型不是在使用工具,它是在使用一个 Harness 暴露给它的接口形状,而接口形状的"LLM-friendliness"往往决定了工具的实际命运。
一、为什么 grep 反而赢
Pengcheng Xu 的实测给出了一个非常具体的对比:在定位任务(Localization)上,Opus 4.8 选择 LSP 语义导航的比例是 0%,Sonnet 4.6 是 4%,Haiku 4.5 是 6%。换句话说,在能选 LSP 的情况下,模型几乎一致地选择继续用 grep。作者把这个观察归因到一个非常具体的设计差异——LSP 工具最初只返回一个位置(file path、line、column),然后 Agent 必须再次调用"打开文件"才能看到那行代码的真正内容;而 grep 通常会直接返回匹配的那一行,例如 `src/auth.ts:42: return validateToken(token)`。这两种返回形态在 LLM 视角下意义完全不同:前者强迫 Agent 走多步才能完成任务,后者一步就能拿到下一步推理所需的全部上下文。
为了验证这一点,作者做了一个相当干净的控制实验——保持后端 LSP 服务不变,只把返回结果从"只有位置"改成"位置 + ±2 行源代码"。结果:多文件重命名任务的 pass@1 从 0.67 升到 0.83,后续文件读取次数从 15.2 降到 3.2(已经低于 grep 自己的 4.3)。也就是说,改变的不是工具能力,而是工具返回的"信息形状",Agent 的成功率与效率就被大幅改写了。这条结论对应到 Anthropic 在 Writing effective tools for agents 里反复强调的一个原则——"Tools are interfaces for non-deterministic agents",意思是工具不是为人设计的(确定性 IDE 用户),而是为模型设计的(非确定性、统计性推理方)。
这里有一个更深层的工程原因:LLM 在训练阶段见过海量的 grep 输出形态。`grep -rn "pattern" path` 这种调用形式以及它返回的"file:line:content"格式,几乎是模型预训练语料里最高频的代码检索模式之一。而 LSP 协议的 `textDocument/definition`、`textDocument/references` 这类 JSON-RPC 调用以及它返回的 Location 数组结构,在模型训练数据里出现频率要低得多。这意味着即便 LSP 在理论上能给出更精确的结果,模型在推理阶段还是会"下意识"选择它更熟悉、能更好预测下一步输出的那一个工具——这是工具选择层面的"训练分布偏好"问题,而非纯能力问题。
二、什么情况下 LSP 真的有用:代码库噪声是决定因素
但 Pengcheng Xu 并没有把 LSP 一棍子打死。实验数据明确显示,在"代码库噪声"较高的场景里,LSP-backed 语义导航的 F1 比 grep 高出 0.246,而且还省了 12% 的 token。这个对比被作者做成了一张直方图:同一个 TypeScript 语言,remeda 仓库(grep 的精度是 1.00)上 LSP 加 0 分;hono 仓库(grep 精度只有 0.51)上 LSP 加 +0.246 F1;Python requests 仓库(grep 精度 0.76)上 LSP 加 +0.072。
这条结论非常工程化——LSP 是不是值得用,取决于这个代码库的"词法噪声"有多大。一个命名干净、类型标注完整、注释克制、符号不被多个同名对象污染的代码库,grep 几乎不会产生假阳性,LSP 的语义精度毫无用武之地;反之,一个命名含混、同一名字在不同模块重复出现、注释里到处都是示例代码的代码库,grep 的精度会塌陷,LSP 才能体现价值。换句话说,语义工具的价值不是绝对的,而是相对于"词法检索在该代码库上的失败率"。当 grep 的精度还能保持 0.9 以上时,引入语义工具的边际收益是负的——它增加了 token 消耗但没有提升成功率。
这个发现直接挑战了 LSP-Skill(2026 年 1 月在 HN 上发布的 Show HN 项目)那种"把 LSP 转成 Agent 友好的 Markdown 接口"的思路。LSP-Skill 把 LSP 调用封装成一个叫 LSAP(Language Server Agent Protocol)的协议层,把 JSON-RPC 结果转成 LLM 友好的 Markdown 文本,试图降低模型使用 LSP 的门槛。从 Pengcheng Xu 的实验看,这种做法的方向是对的——它的本质就是给 LSP 包了一层 LLM-friendly 输出形态——但能不能真正改变"模型默认选 grep"的行为习惯,取决于这一层抽象的输出是否真的"在模型训练分布里足够常见"。如果 LSAP 输出的是模型在训练数据里没见过的全新 Markdown 结构,那么模型还是要走一遍试错才能学会怎么用,LSP 的优势依然会被浪费。
三、模型并非"盲目偏好 grep",而是按任务路由
Pengcheng Xu 文章里另一组值得反复看的数据是同一个模型在不同任务上的工具选择差异。Localization 任务上语义工具使用率 0%-6%,Reference-completeness 任务上立刻升到 45%-57%,Multi-file rename 任务又回到 3%。这不是"模型固执",而是"模型按任务形状在做路由":当任务是一次性定位某个符号在哪行,grep 的边际收益是 100%,LSP 的边际收益是 0;当任务是找出所有 caller 引用,grep 的精度会快速下降,LSP 的边际收益开始显现;当任务是跨文件重命名,需要的安全网(refactor preview)在 grep 层面根本无法表达,模型又回到 grep 因为 LSP 返回的 Location 不带 inline 上下文。
这种"按任务路由"的特性,正好与 Anthropic 在 Effective Tools for Agents 文档里描述的设计哲学一致——不要让模型去"猜"工具的能力边界,而要在工具描述里明确写出"什么任务用我、什么任务别用我"。具体来说,一个 LLM 友好的工具描述应该至少包含四个要素:触发条件(什么场景下应该调用)、输入形状(参数是什么语义、什么类型)、输出形状(返回的字段长什么样、有什么副作用)、不适用场景(什么时候不应该调用我)。前两个大家都在做,后两个很少有人做,但后两个恰恰是决定 Agent 在真实任务里会不会"放弃这个工具、转而去找 grep"的关键。
更进一步看,工具的命名本身也会影响 Agent 的选择。模型在训练阶段见过大量 `grep`、`ripgrep`、`rg`、`ag` 这种短名搜索工具,它们在 prompt 里的"被想起率"远高于 `definition`/`references`/`documentSymbol` 这种 LSP 原生操作名。一个 Harness 设计师如果把 LSP 操作暴露成 `find_definition`、`find_references`、`get_symbols` 这种自然语言短语,而不是 `textDocument/definition`、`textDocument/references` 这种协议原名,Agent 的采纳率通常会有量级提升。这与 LSAP 项目的设计哲学不谋而合——它把 LSP 操作重新命名、重新组织成 Agent 更熟悉的"语义动作"。
四、Harness 工具链设计的工程新样本
把上面这些发现汇总起来,可以提炼出 Harness 工具链设计的几条工程原则,它们与传统 IDE 插件开发的设计哲学有本质区别。
第一,工具输出必须直接包含下一步推理所需的上下文**。Pengcheng Xu 的实验证明,把 LSP 输出从"Location"改成"Location + 源代码 ±2 行",pass@1 从 0.67 升到 0.83。这意味着 Harness 应当为每个检索类工具强制规定"返回结果里必须包含完整的内联上下文",而不是让 Agent 自己再发一次文件读取请求。这是 Anthropic 反复强调的"save your agent's round-trips"原则的具体落地。
第二,工具描述必须明确说明不适用场景**。一个常见的反模式是工具描述只写了"我能做什么",从来不写"我不适合做什么"。结果 Agent 在不擅长的场景也硬调这个工具,拿到糟糕结果后只能回退到 grep。这种"工具自我贬低"的描述虽然看起来削弱了工具的存在感,但实际上能显著提高 Agent 的整体任务成功率。
第三,工具命名要符合模型训练分布。LSP-Skill 项目里把 JSON-RPC 操作重命名为 `Definition`、`Reference`、`Hover`、`Outline` 这种自然语言动词短语,而不是协议原名 `textDocument/definition`,这种做法符合模型训练阶段高频出现的命名习惯。Harness 设计师在做工具 API 时,应当刻意避开"框架原生的驼峰方法名",而是采用"自然语言动词+名词"的命名。
第四,工具能力要按"任务形状"分组暴露。Pengcheng Xu 的数据显示,模型对工具的采纳是按任务路由的,这意味着 Harness 不应当把所有工具平铺给 Agent,而应当基于任务类型动态暴露"工具组"。例如在定位任务中只暴露 grep 类工具,在引用完整性任务中暴露 grep + LSP,在多文件重命名任务中暴露 LSP + rename preview。这样 Agent 不会被"工具海洋"淹没,也不会在不该用 LSP 的时候被诱导使用。
第五,代码库噪声是 Harness 调优的关键指标**。Pengcheng Xu 的 remeda/hono 对比证明,语义工具的价值是相对于词法工具的失败率而言的。Harness 应当在运行时监控 grep 类工具的精度,当某个代码库的词法精度持续低于 0.7 时,自动启用语义工具;反之则隐藏语义工具,避免 token 浪费。
第六,工具接口要支持 inline context 注入**。LSP-Skill 项目把 LSP 结果转成 Markdown,Pengcheng Xu 的实验证明 inline 上下文是关键。Harness 应当为所有"位置型"工具提供一个标准化的"inline 上下文注入层",让模型不需要为"打开文件"再发一次请求。
五、对企业级 Coding Agent 平台的具体启示
这些发现在企业级 Coding Agent 平台建设里有一系列非常具体的应用场景。
第一,不要照搬 LSP 协议,要做 LLM-friendly 抽象。LSP 是为人设计的协议,其 JSON-RPC 形态对 Agent 来说成本很高。LSP-Skill 把 LSP 转成 Markdown 输出的方向是对的,但还不够——还需要把操作名从 `textDocument/definition` 改成自然语言动词,把"只返回 Location"改成"Location + 上下文",把"workspace symbol"改成"按类型过滤的全局搜索"。
第二,工具集要按代码库特征动态切换**。同一个 Harness 部署到企业内部不同项目时,工具集应当不同。在命名规范、注释克制的项目里,优先暴露 grep + 简单 read;在历史包袱重、命名含混的项目里,优先暴露 LSP + 引用分析 + 重命名预览。这要求 Harness 层维护一份"代码库特征画像",用 grep 精度等指标驱动工具集的动态开关。
第三,工具描述要带"反例"**。把工具描述从"我能做什么"扩展到"什么时候不要用我"。这一条 Anthropic 已经反复强调过,Pengcheng Xu 的实验再次验证了它的工程价值。Harness 层应当为每个工具强制要求"反例字段"必须非空,否则工具不予上架。
第四,Inline context 应当是平台级标准**。所有"位置型"工具(grep、ripgrep、symbol search、find references、go to definition)在返回结果时都必须包含 ±N 行的源代码 inline 上下文。这个 N 应当可配置——默认 2 行,重命名任务 5 行,引用分析任务 3 行。强制标准之后,Agent 不再需要为"读下一行代码"反复发起 read_file 调用,token 消耗和 wall-clock 都会显著下降。
第五,工具调用统计应当作为 Harness 的核心可观测性指标**。每个工具的调用次数、调用分布、平均返回大小、调用后任务成功率都应当进入 Harness 的可观测性平台。当某个工具的调用后任务成功率长期低于 50%,意味着工具接口设计有问题,应当触发"Harness 工具重设计"流程;当 grep 类工具的调用次数远超预期,意味着代码库噪声过高,应当触发"语义工具启用"流程。
2026 年的 Coding Agent 工具链设计正在从"协议中心"走向"LLM 中心"。这件事的工程含义远比表面看起来更深远——它意味着过去 20 年为人类开发者优化的 IDE 工具链(语言服务器协议、调试协议、构建协议)不会自动成为 Agent 工具链的最佳答案。每一家认真做 Coding Agent 平台的公司,都需要重新设计自己的工具 API、工具描述、工具输出形态。Pengcheng Xu 那篇 9 分钟的实测文章,值得每个 Coding Agent Harness 设计师打印出来贴在显示器上反复看。
