Grep 击败 LSP?Coding Agent 忽略高阶工具的真实原因,以及 Harness 工具链工程新样本 · 重庆智能体开发 · 行业资讯

2026 年 9 月 4 日,AgentConnect 团队在 Hacker News 发布《Grep beats LSP? Why coding agents ignore your fancier tools》,97 分上首页讨论 24 条——一篇工程实证研究,把 lexical search(grep)和 LSP-backed semantic navigation 在 coding agent 上的实际表现做了严格对照,跑 3 个 Claude 模型(Opus 4.8、Sonnet 4.6、Haiku 4.5)、多个 Python 和 TypeScript repo、多种任务类型。结论颠覆直觉——在 simple code-location tasks 上 semantic 只被选中 0-6%,forcing semantic-first 反而把 success 从 100% 降到 89%;在 reference-completeness tasks 上 semantic 才被选中 45-57%,但 precision 只提升 0.24,recall 几乎没变。同一时期,6 月 5 日 HN 上 17 分的《Bad MCP design costs your agent 5x more tokens》给出另一条互补的实证——两个功能相同的 MCP Server(MCP-A vs MCP-B),用同样的模型和 agent framework 跑 40 个测试 prompt,Pass Rate 都是 36/40(90%),但 Total input tokens 差 4.98 倍(MCP-A 637k vs MCP-B 3.17M)。两件事合起来,把一个长期被开发者忽视但对企业 Agent 落地极其关键的事实摆到桌面上——Agent 工具的设计决定 token 消耗和 success rate,模型本身的 benchmark 不能预测它在自定义 harness 里的真实表现。这件事的工程价值在于它揭示了 Harness 工具链工程的具体设计基线,提示企业 IT 在评估 Coding Agent 时必须把 harness 和模型当做一个整体来看,而不是分别打分。

一、Grep vs LSP 的关键实验发现

AgentConnect 团队的实验设计相当严谨。三个 Claude 模型、多语言 repo、多种任务类型,token 计量只在两边都成功完成任务的条件下进行——这条控制避免了一个常见的 evaluation error:失败的 run 可能看起来更高效,因为它根本没产生那么多 token。

具体数字揭示了几个反直觉的发现。在 simple code-location tasks 上(找一行代码、一个函数定义),三个模型在 grep 和 LSP 都可用时,选 semantic tool 的频率只有 0-6%——模型几乎总是用 grep。Forcing semantic-first 的 arm 把 success 从 100%(用 grep)降到 89%(用 semantic)。这条发现是 surprising 的,因为 semantic navigation 在理论上应该更精准——它能区分真正的函数调用和注释里的同名字符串。

在 reference-completeness tasks 上(找所有 caller),模型选 semantic 上升到 45-57%,LSP-backed 路径 precision 达到 1.00(grep 是 0.76),通过消除 false matches。但是 recall 在两个 arm 都接近 0.66——semantic navigation 没有找到更多 true call。剩下的限制不是 retrieval precision,是 agent 工作得有多彻底。

codebase 本身的特性也是关键预测因子。在一个 clean TypeScript repo 上,LSP-backed navigation 没有 F1 增益,反而多用 16% tokens。在一个 noisy TypeScript repo 上,F1 改善 0.246,tokens 反而少 12%。预测因子是 lexical noise——grep 在那个 repo 上精度有多差——而不是语言本身是否静态类型。

这条发现的工程含义非常具体:不要给 agent 默认安装 LSP,应该根据 codebase 特征路由。clean codebase 用 grep,noisy codebase 用 semantic,而不是"更高级的总是更好"。

二、Tool Interface 决定 Agent 行为

Grep vs LSP 实验最深刻的一条发现是关于 tool interface 的——同样的 semantic backend,只是改一下返回结果的格式,pass@1 就从 0.67 飙到 0.83。

具体来说,实验里的 LSP-backed tools 最初只返回一个 location(file path, line, column)。Agent 必须再开文件才能看到 code。Grep 通常直接返回 matching line:`src/auth.ts:42: return validateToken(token)`。

实验把 semantic navigation 的 response 改成也包含 source text,format 类似 grep 的 path:line:content。Semantic backend 和 reference set 都没变,只是返回给 model 的信息变了。Pass@1 在 rename tasks 上从 0.67 升到 0.83,follow-up file reads 从 15.2 降到 3.2——比 grep 自己的 4.3 还低。

这条结果揭示了一个原则,Anthropic 在《Writing effective tools for agents》里也强调——tools 是 for non-deterministic agents 的 interfaces,所以 returned context 是 design 的一部分。一个语义正确的 tool,如果每个 result 需要几次额外 action 才能解读,仍然会创造糟糕的 agent workflow。

Output format 的改变是不是因为 post-training data?这条不能证明。但结果符合一个更广泛的假设——models learn concrete action patterns,不是抽象的 "tool usage"。Tool 的 output shape 决定了 model 接下来怎么 act,这是 model × harness 的一部分,不是 model 单独的属性。

三、Bad MCP design 5x tokens 的实验

6 月的《Bad MCP design costs your agent 5x more tokens》给出另一条互补实证。两个 MCP Server(MCP-A 和 MCP-B)功能完全相同,后端 API 也相同,但 Pass Rate 都是 36/40(90%),Total input tokens 差 4.98 倍。

具体数字:MCP-A Tool Description Length 11,464 字符,MCP-B 3,682 字符(更短但更糟);MCP-A Total input tokens 637,244,MCP-B 3,174,329;MCP-A Total output tokens 17,301,MCP-B 23,238;MCP-A Total Agent steps 122,MCP-B 157;MCP-A Total time 597s,MCP-B 676s。MCP-B 多跑了 35 个 ReAct loop(29% 多),output tokens 多 30%,input tokens 多 5 倍。

根因是 query tool design。MCP-B 的 `search_tool` 只返回 id/title/url,但其他 CRUD 操作需要 project_id,所以 Agent 必须再调 `get_task_by_id`。MCP-A 的 `query_tasks` 一次返回所有必要信息(id/title/project_id/start_date/priority/status)。

第二条根因是 unprocessed API output。MCP-B 的 `create_task` 直接 dump 整个 API response 到 Agent context——id/projectId/createdTime/modifiedTime/focusSummaries 等 600+ 字符。这些字段对 Agent 当前 task 毫无意义,但全部进入 context。MCP-A 的 `create_tasks` 做了一层 filtering 和 formatting,只返回 Agent 真正需要的字段。

这两条根因揭示的工具设计 bad pattern 是企业 Coding Agent 部署里最常见也最难发现的问题——开发者写 tool 时直接转 API response,不思考 Agent 的下一步需要什么。结果是 token 暴涨、ReAct loop 拉长、Agent 决策质量下降。Pass Rate 看起来不错(都是 90%),但成本是 input tokens 多 5 倍。

四、Agent capability = Model × Harness

AgentConnect 的研究最终落到一个公式:agent capability = model × harness。这个公式直接挑战了当前行业对 Coding Agent 的评估范式——benchmark 数字不能预测自定义 harness 里的真实表现,支持同一个 model 不等于 reproduce 同一个 agent。

这条公式的工程含义在 Harness 工具链设计上有四条直接推论。第一,tool selection 影响 model 的 effective capability——把同一个 model 从 A harness 移到 B harness,实际能力可能完全不同,因为 post-training trajectory 已经被 A 的 tool shape 训练过。第二,tool signatures 影响 model policy——同样的 task 在两个 harness 里可能走完全不同的 tool call 序列,因为 model 学习了不同 signatures 下的 action pattern。第三,output formats 影响 model 的 reasoning efficiency——返回 location vs path:line:content 影响后续 action 数和 success rate。第四,error behavior 影响 model 的 recovery strategy——MCP-A 在 error 时返回结构化信息,MCP-B 在 error 时返回 raw error string,model 处理这两种 error 的方式完全不同。

Anthropic 在《Building effective agents》里也强调这条原则——"successful agent systems often rely on simple, composable patterns. More tools do not automatically produce a more capable agent; tools must be distinct, understandable, and useful within the model's workflow." 这条原则给了企业 IT 一个明确的 harness 设计 checklist——评估 Coding Agent 时必须 model 和 harness 一起看,benchmark 数字不能脱离 harness 单看。

五、企业 Harness 工具链工程的具体 checklist

把两篇研究合起来,可以列出一份 Harness 工具链工程的具体 checklist。

第一条,任何 tool 必须返回 path:line:content,而不是只返回 location。Agent 需要 source text 在下一步决策时,返回 location 强迫它再开文件,follow-up read 数会暴涨(实验数据:LSP+location 15.2 reads,LSP+inline context 3.2 reads)。

第二条,任何工具的 response 必须经过 filtering 和 formatting,不能直接 dump API response。MCP 实验数据:MCP-A 过滤后 11k tool desc + 637k total input tokens,MCP-B 不过滤 3.7k tool desc + 3.17M total input tokens。Pass Rate 一样,但成本差 5 倍。

第三条,任何工具的 response 必须包含 Agent 下一步 action 所需的所有信息。search tool 不能只返回 id,必须返回 project_id 等其他 CRUD 操作需要的字段,避免 Agent 必须额外 call get_by_id。

第四条,任何 tool 必须支持原生 fallback。Semantic navigation 在 noisy codebase 有 0.246 F1 增益,但在 clean codebase 是 0 增益还要多花 16% tokens。Harness 应该根据 codebase noise 自动 route,而不是默认用"更高级"的工具。

第五条,tool description 必须精确反映 capability。MCP 实验里 MCP-B 的 tool description 更短(3.7k vs 11.4k)但 Pass Rate 一样,问题不在 description 长度而在 description 是否准确说清楚返回什么、Agent 能用它做什么下一步。

第六条,任何 tool 必须支持 progressive disclosure——大结果集不要一次性倒进 context。Warp 的 skill 设计的 progressive disclosure 原则、machine0 的 stream-based transfer、Ridge 的 Keep artifacts out of model context 都是同一类思想。

第七条,任何 tool 必须为 non-deterministic agents 设计 interface。Anthropic 的 Writing effective tools for agents 反复强调这条——tool 的 output 是 model reasoning 的输入,output shape 决定 model 接下来怎么 act。

第八条,tool routing 必须 task-shaped 而不是 constant。Grep vs LSP 实验证明 simple code-location 几乎不用 semantic,reference-completeness 才用 semantic 一半。Harness 应该让 Agent 自己 route,或者按 task type 自动 route,不应该硬编码"用 LSP"。

第九条,tool evaluation 必须 on real tasks。Bad MCP 实验里 Pass Rate 一样但 token 差 5 倍——只看 Pass Rate 看不到 token 消耗差异。企业评估 Harness 时必须同时看 Pass Rate、Token 消耗、Steps 数、Time 四件套,而不是单看一项。

第十条,harness 必须可重复 evaluate。Unblocked 实测 Anthropic 内部 Coding Agent harness 监控时强调 harness 改变和模型升级必须分开测,model 单独 benchmark 不能预测 harness 改版后的实际表现。

六、下一步:Harness 工具链工程成为可量化基线

把这件事放到更大的图景里看,Harness 工具链工程正在从"开发者个人审美"过渡到"可量化基线"。Grep vs LSP、Bad MCP design、Warp self-improving skill、Decispher LongMemEval、Security Cards BaxBench——这一连串 2026 年的研究和产品,把 Agent harness 的每一个关键维度都拉到了可量化、可对比、可重复 evaluate 的状态。

接下来一年内,Harness 工具链工程会进入"benchmark 时代"——任何 agent 平台在发布时都需要跑一组标准 harness benchmark,token 消耗、Pass Rate、Steps 数、Time 四件套,以及在不同 codebase noise、task type、model family 上的 distribution。企业 IT 评估 Coding Agent 时,会像现在评估 GPU 一样看 benchmark 数字,而不是看 demo 演示。

回到一开始的问题——Grep 击败 LSP 的反直觉发现和 Bad MCP design 5x tokens 的实证数据,把 Harness 工具链工程的具体设计基线第一次用实验数字钉死。剩下的是企业 IT 在落地时把十条 checklist 都做对,把 Harness 从"开发者个人审美"升级为"可量化基线"。这是 2026 年下半年 Harness 工程走向成熟的标志,也是企业 Coding Agent 真正能承担关键业务的入场券。