Does a Language Server Save Tokens for Coding Agents? A Measurement Methodology and Preliminary Study
本文挑战了语言服务器协议（LSP）语义检索在本质上比词法搜索对编程智能体更具 Token 高效性的假设，通过一种新的测量方法揭示了 LSP 往往会增加 Token 成本，并且在处理复杂编辑时无法达到 grep 的有效性，从而主张根据任务类型和模型能力采取一种自适应的工具选择策略。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你是一名试图破解谜团的侦探，但你有一个严格的规则：你只能携带一个很小的、沉重的背包。你捡起的每一件证据都会占用空间，如果你的背包变得太满，你就无法清晰地思考了。在 AI 编程助手的世界里，这个“背包”被称为上下文窗口（context window）。它是 AI 在理解一项任务时，大脑中能同时容纳的信息量限制。
为了解决编程问题，AI 需要从巨大的数字图书馆中寻找散落在成千上万个文件里的特定线索。寻找这些线索有两种主要方式。第一种是词法检索（Lexical Retrieval）（类似于使用 grep 命令）。你可以把它想象成在一个拥挤的房间里大喊一个关键词，并抓取所有写有这个词的纸片。这种方法很快也很简单，但你会得到很多垃圾——边注、笑话中的单词，或是出现在无关故事中的提及。AI 必须阅读所有这些噪音来寻找真正的线索，这会填满你珍贵的背包，装满无用的纸张。
第二种方式是使用语言服务器协议（LSP）进行的语义检索（Semantic Retrieval）。这就像拥有一个超级聪明的图书管理员，他完全理解你的意思。他不仅仅是匹配单词，而是理解代码的含义。如果你问：“谁使用了这个函数？”，图书管理员会给你一份真正调用该函数的列表，忽略掉那些笑话和注释。大家一直在问的一个核心问题是：“这位聪明的图书管理员能否节省我们的背包空间？”普遍的观点是，由于图书管理员提供的资料更干净、更相关，所以效率更高。但直到现在，还没有人真正测量过这种“聪明”的方式是否真的比“喊叫并抓取”的方法节省了 Token（数字空间单位）。
这篇由 Pengcheng Xu 撰写的论文决定停止猜测，开始进行测量。作者设计了一系列实验，以观察使用聪明的图书管理员（LSP）是否真的能帮助编程智能体在正确解决谜题的同时，节省其背包空间。结果有点令人惊讶，它颠覆了普遍的认知。
“喊叫并抓取”在简单任务中胜出
当任务仅仅是寻找特定代码的位置时（例如寻找要编辑的文件），聪明的图书管理员反而让情况变得更糟了。在这些测试中，使用图书管理员的 AI 比仅使用关键词搜索的 AI 多使用了 6% 的 Token（对于最强的 AI 模型）以及 118% 的 Token（对于中等水平的模型）。为什么呢？因为图书管理员给出的答案非常精确，以至于 AI 必须进行额外的步骤来验证它们，而“喊叫并抓取”的方法直接在搜索结果中就给出了答案。当给予自由选择权时，AI 智能体几乎从不将这些简单任务交给图书管理员，而是坚持使用虽然嘈杂但更快速的关键词搜索。
图书管理员是较弱模型的“拐杖”
研究发现，聪明的图书管理员只为测试中最弱的 AI 模型节省了空间。对于最强的模型来说，图书管理员其实是一种负担。那个难以过滤“喊叫并抓取”方法产生的噪音的弱模型，通过使用图书管理员实际上节省了 26% 的 Token。看起来，图书管理员就像是为那些无法处理混乱数据的“弱脑”准备的拐杖，但对于“强脑”来说，这根拐杖只会拖慢它们的速度。
精确度 vs. 完整性：“缺失的三分之一”
当任务转变为寻找函数使用的每一个地方（引用完整性/Reference-Completeness）时，图书管理员在准确性方面表现出色，但在节省空间方面却失败了。图书管理员找到了 100% 正确的位置，且零失误，而关键词搜索仅找到了 76%，并且包含许多虚假警报。然而，这种完美的准确性是以消耗约 19% 更多 Token 为代价的。更重要的是，两种方法都无法找到所有位置。AI 在两种情况下都遗漏了大约 34% 的真实位置。这表明问题不在于工具，而在于 AI 本身不够彻底，无论图书管理员多么优秀，它都无法找到最后那几个线索。
真正的秘密：取决于“噪音”
最重要的发现是，图书管理员的好坏并不取决于编程语言（如 Python 或 TypeScript），而完全取决于代码的“噪声”程度。如果一个函数名是独特且清晰的（例如 decodeBase64），关键词搜索就是完美的，图书管理员毫无用处。但如果名字很常见，出现在注释、字符串和笑话中（例如 html 或 stream），关键词搜索就会被垃圾信息淹没。在这些“多噪”的情况下，图书管理员成为了救星，它大幅提升了准确性，甚至通过让 AI 停止浪费时间阅读垃圾信息来节省了 Token。
结论：不要强迫使用图书管理员
论文得出结论，我们不应该强迫 AI 智能体始终使用聪明的图书管理员。智能体本身其实已经足够聪明；它们在处理简单任务时自然会选择关键词搜索，并在任务复杂且多噪时寻求图书管理员的帮助。最好的解决方案不是把图书管理员作为一个永久性的功能强行嫁接到 AI 上，而是训练 AI 成为一个更好的“路由器”——教它明确知道何时该大声喊叫，何时该询问图书管理员。论文显示，AI 已经具备了这种隐藏的本能，我们只需要强化它。
简而言之，聪明的图书管理员是一个强大的工具，但它并不是一个能自动节省空间的魔杖。它是一个专门化的工具，只有在代码混乱且 AI 难以过滤噪音时才能发挥最佳作用。对于整洁的代码和聪明的模型来说，传统的“喊叫并抓取”往往更快、更便宜，也同样有效。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。