LSP 这轮实验里没省下 token。对更强的模型，它还多烧了。这个结论我先甩出来——别等下面算账算到一半你才回过味来。因为太多人把“语义导航更聪明、更省上下文”当天然正确，碰见谁不接 LSP 就觉得人家在裸奔。AgentConnect 工程博客八月份那篇研究，我认真翻过。人家原本的预期跟市场一样：语义导航降噪、降本。结果 agent 不买账。三个 Claude 模型在简单定位任务里自己选语义工具的比例，加一起不够一个整数的零头。强制让它们先走语义路径，成功率从 100% 掉到 89%。账不是这么算的——不能因为一个工具“在语义上更高级”就默认它在代理场景里更便宜。谁要是一直这么想，就是在交认知税，还没人给你开收据。
先算那笔最直观的账：token。结论反直觉——语义导航省不省，跟这个仓库是不是 TypeScript 一毛钱关系没有。真正的变量只有一个：grep 在这个代码库里会产生多少误匹配。remeda 里 grep 精度干到 1.00，LSP 反而多烧 16%；hono 里 grep 精度只有 0.51，LSP 把 F1 提上去 0.246，少烧 12%；requests 更暧昧，grep 精度 0.76，LSP 稍微提了一点，但多掏 19% 的 token。看到没，同样是 TypeScript，remeda 和 hono 给出的答案完全相反。“静态类型语言就该配 LSP”是个伪判断。你以为你在做技术选型，其实你缺的是一张“这仓库里 grep 误报率”的表。没有这张表，你花在语义导航上的每一分 token，都有可能是在替 grep 本来就能干好的活付溢价。
——插一句，这研究真正让我高看一眼的，不是它证明了 grep 还是 LSP 赢。它把“工具返回结果”这层窗户纸给捅了。初始版本的 LSP 语义导航只返回文件路径加行号列号，模型拿到这玩意儿，得自己再去开一次文件看代码；grep 呢？直接把匹配行内容带着位置一起怼回来，模型一眼就知道相关不相关。你猜中间差了多少成本？多文件重命名那个任务里，只返回位置的 LSP 逼着模型做了 15.2 次后续文件读取，成功率 0.67；后端和引用集合全没动，只在每个引用前后附了两行源码，文件读取直接掉到 3.2 次，比 grep 的 4.3 次还低，成功率升到 0.83。这一笔省下来了，才叫真省。只给位置的语义导航不是省 token，它是把 token 从“工具返回”里挪到了“后续文件读取”里——面值降了，总成本更贵。
这里头藏着一个很多人没想明白的账本结构：模型的“下一步行动”是有成本的。你给它一个结果，如果这个结果没法支撑它直接开始下一步，它就得重新打开上下文、重新读文件、重新组织判断。你看到的是“每次工具返回更精简了”，它看到的是“我得再去开三次文件”。你以为你省了上下文，其实你把上下文成本转移成了行动成本。报告里引 Anthropic 那句引用得准：工具返回的上下文得当成接口设计的一部分来对待，语义正确但不好用的工具，照样拉高解释成本。这跟我在商业复盘里老算的那笔账一模一样——研发成本降了 60%，省下的钱拐个弯跑去获客了。这里只是把获客换成文件读取，本质没变。
账算到这儿，得再往下挖一层。模型为什么老爱用 grep？为什么把同样的结果多给两行源码，成功率就能提一个档？有一种解释是模型只认它练熟了的动作路径。研究报告没说那么死，只说不能区分“熟悉常见工具形态”和“单次响应信息量”各自起了多大作用，因为没人去动训练数据。但你自己想想，后训练轨迹里塞的那些例子，哪条不是 read、grep、edit、bash 这套循环？模型学到的不是“语义关系”这个抽象概念，它学到的是“grep 会返回这种格式的结果，我下一步该这么接”。harness 把关了它能看到什么、看到之后该怎么回。你把 grep 换成 LSP，模型面对的不是一个更智能的检索器，是一套它没练过下文的接口。这不叫模型能力不行，这叫能力表面变了。
——说句扫兴的，这研究还给了个结构解释。有些活，语义引用这集合天生就不齐全。find_references 返回的是“真实的符号引用”，但重命名去改注释、docstring、配置文件、字符串字面量这些事，它就是覆盖不到，设计上就排除掉了。grep 啥都给你刨出来。对文本范围编辑这路任务，语义引用就是文本出现集合的一个子集。子集再干净它也是缺的。你为了“干净”把“完整”丢了，在重命名这个场景里就是降维打击自己。这条账我一开始看那份报告时也自己想岔了，总以为语义导航的问题只是上下文格式——后面才转过弯来。有些任务里它压根不是格式的问题，是这把刀没开刃。
那谁在赚谁在亏？卖工具的和卖服务的在赚认知差的钱，这个很明显，我不点名。更值得算的是普通用户这边。假如你因为在朋友圈里看到两篇“LSP 降本”的科普，就把自己的 agent 默认路由全切到语义导航，那你就是在交认知税。remeda 那种 grep 本来就不怎么误报的代码库，你等于白花 16% 的 token；简单定位任务里 agent 自己都不爱用 LSP，你还硬按着头让它用，成功率掉几十个点。钱省不下来，还倒贴。反过来，hono 那种 grep 遍地噪声的库，你不给 agent 配 LSP，它就在一堆误匹配里刨食，token 全烧在分辨垃圾上。所以这根本不是一个“LSP 好还是 grep 好”的问题，是一个“按仓库和任务路由”的配置工作。账没有统一的输赢，只有错配的亏。
最后给条能用的路，不宽，但能落地。那篇报告里的六项检查，我挑四条信息密度最高的说白一点。第一，别拿“精度提升”自我感动，真去同精度条件下跑一遍真实任务，看成功率和总 token 成本，这俩才是真的。第二，你加上去的工具，先观察 agent 到底选不选它。它要是不选，你投入的集成成本就全是沉没成本。第三，看返回的上下文够不够支撑下一步行动，不给源码只给位置，等于让模型裸奔。第四，保留原生回退路径。grep 这路东西在文本范围编辑任务里是底线，你把它拆了，就是自断一臂。这些不是增量优化建议，是你在给 agent 加任何“高级工具”之前该写的检查单。否则你以为你在给 agent 提效，其实你在给它改接口、改工具循环、改能力表面，然后还不知道这笔账为什么会变差。
LSP 现在的问题是，很多人把它从“一个在某些仓库里能省 token 的工具”吹成了“更先进的检索范式”。范式这字太大了，大到能把账本遮住。遮住之后你就会忽略那个最重要的结论：一模一样的 LSP 结果，只多给两行源码，就能把成功率从 0.67 拉到 0.83。这锁定的不是 LSP 不行，是“工具返回形态”才是 agent 时代真正被低估的那笔账。这笔账你没算，怎么调参都是亏的。本期认知税：把“语义更高级”直接当成“代理场景更便宜”，是现阶段最贵的一笔糊涂账。这笔账，你自己算。咱下篇见。