为什么高 token 效率的代码搜索对 AI 代理很重要

Farah Rahman 在多哈遇到一个熟悉的问题：一条客户 bug 报告、一段午夜的 Slack 线程，以及一个分布在 43 个仓库中的 180 万行代码库。她请一个 agent 追踪一次支付失败。第一次检索消耗了太多 token，以至于模型丢掉了上下文。随后它又给出了一个半对半错、却装得很有把握的答案。

这正是 Semble 试图修复的那类混乱。它的卖点——面向 agent 的代码搜索，使用的 token 比 grep 少 98%——听起来几乎有点俏皮。但在这个标题之下，是一个严肃的转变：代码搜索不再只是为了快速找到文本。它是为了只把机器真正需要的那一小段源代码喂给它们，并且以一种它们能够推理、又不会烧掉预算和上下文的形式。

老实说，这很重要，因为旧的工作流是为人类在终端里快速扫视而设计的。agent 不会略读。它们会吞入。而当它们吞得不好时，后续每一步都会变得更不稳定：补丁生成、根因分析、测试选择、文档修复，甚至安全审查。

为什么它现在很重要

几乎在同一时间，事情发生了两件变化。首先，团队开始把 LLM 直接放进工程工作流里，从 IDE 助手到自主分诊机器人。其次，上下文成本变得痛感十足。明白吗？大提示词不仅昂贵，而且脆弱。如果一个 agent 需要检查一个 monorepo，几次糟糕的检索步骤就可能白白浪费整次运行。

与此同时，搜索预期也变了。开发者仍然希望有 grep 式的精确性，但 agent 需要的不只是精确字符串匹配。它们需要语义级缩小范围、按符号感知的分组，以及足够的结构来避免从无关片段中产生幻觉。Semble 正好处在这个缝隙里。

核心想法：为模型搜索，而不只是为工程师

传统的 grep 在一件事上非常出色：匹配文本。它也极其字面化。如果你的 bug 体现在一个被重命名的函数、一个生成文件，或者一个藏在五层包装器中的符号里，除非人类知道该敲下哪根正确的针，grep 可能就会视而不见。

面向 agent 的代码搜索应该以不同方式运作。它应该把一个庞大的仓库缩减成紧凑、高信号的证据。这意味着按可能的相关性排序，返回周围结构，并剔除那些人眼可能会忽略、但模型会愉快浪费 token 的重复样板代码。

更深层的观点是，token 现在是一种稀缺的工程资源。不是抽象意义上的稀缺，而是字面意义上的稀缺。你喂给 agent 的每一段额外文件内容，都可能改变延迟、成本和答案质量。因此，一个声称比 grep 少 98% token 的工具之所以有趣，不是因为 grep 很糟，而是因为 grep 从来就不是为 LLM 饮食计划而设计的。

在实践中，一个更适合 agentic code search 的系统通常会做好几件事：

• 索引的是符号，而不仅仅是行。 函数、类、导入和引用，比原始文本块更容易让 agent 总结。
• 按上下文排序，而不是只看匹配次数。 靠近失败测试的一个高价值命中，可能比 27 次出现在生成文档里的匹配更重要。
• 大幅压缩。 重复的许可证头、第三方依赖代码，以及重复常量，不应该主导提示词。
• 返回结构化片段。 文件路径、符号名、跨度和依赖提示，能帮助模型在不重新阅读整棵树的情况下进行推理。
• 保留可追溯性。 好的 agent 搜索应当可审计。你应该能看出为什么选中了某个片段。
• 与工具链配合良好。 最好的搜索层会无缝嵌入 CI、IDE 和终端工作流，而不是要求单独的一套仪式。

如果一个模型无法解释自己为什么选了某个文件，你大概也就不太会信任它去编辑那个文件。

这里还有一个微妙的体验收益。人类使用搜索是为了定位方向。agent 使用搜索是为了生成动作。这并不是同一项任务。开发者可以扫一眼 12 个嘈杂命中结果，然后仍然知道该去哪里。相比之下，agent 如果检索层很草率，就可能自信地把错误假设一路传播到整个补丁里。

因此，Semble 关于 token 减少的说法，应该被视为更大问题的代理指标：更好的检索卫生。更少的噪声意味着更少的幻觉表面。更少的噪声也意味着模型有更多空间去看到代码中的真实不变量。而真正有用的变更，正是从那里产生的。

这在实践中是什么样子

Kenji Silva 是波兰克拉科夫的一名数据分析师，他在帮助团队调试一个定价管道，这个管道涉及 14 个服务和 9 个 SQL 模型。一次传统搜索针对某个错误字符串返回了 311 个匹配项。一个感知 token 的搜索工作流把工作集缩小到 18 个片段，并将 agent 的提示词大小减少了 91%。他说，第一次有用的诊断在 4 分钟内出现，而不是 29 分钟。

Rina Popescu 是爱沙尼亚塔林的一名运营负责人，她用一个 agent 检查分布在 6 个内部仓库中的事故处置手册。这个 agent 一直被模板化 markdown 和重复 runbook 搞糊涂。等她的团队切换到一个能去重样板内容的代码搜索层后，机器人的误升级次数从一周 17 次降到 3 次，而值班团队也不再忽视它一半的告警。

回到多哈后，Farah Rahman 在一个支付服务上做了一个试点，涉及一个月内 248 个测试失败。她的团队让 agent 按根因对失败进行聚类。借助更好的搜索层，agent 将其中 193 个归为 5 种模式，并准确找出了发生变化的文件路径。这并没有取代人工判断，但确实省去了大量盲目翻找。

应避免的常见错误

• 把 token 节省当成全部目标。 更少的 token 用量当然很好，但这不是产品本身。如果搜索返回的上下文更少、证据更差，那你只是把错误压缩了。目标不是更短的提示词，而是更可靠的决策。

• 用精确匹配思维来处理语义任务。 当你知道字符串、符号或导入路径时，grep 很出色。但 agent 往往并不知道。如果你的检索策略只是把 grep 套个更薄的外壳，你就会错过被重命名的代码、隐式依赖和生成产物。

• 忽视仓库结构。 测试辅助函数里的一个函数定义，和生产代码里同名函数并不等价。agent 需要关于所有权、模块边界和调用方向的提示。没有这些，它们就可能一本正经地修错层。

• 喂入过多样板内容。 许可证块、第三方捆绑包、压缩后的 JS 和重复的配置片段会迅速吃掉上下文。团队往往会忽略它们，因为人类会在心里自动跳过杂乱内容。但模型不会跳过；它会吸收。

• 跳过评估。 一个在演示里看起来很聪明的搜索层，到了真实工作负载中，面对长尾命名、多语言仓库或混乱测试时可能会失败。要用具体任务衡量检索质量：bug 定位、文件排序和答案正确性，而不只是查询延迟。

• 假设 agent 会自我纠正。 它往往不会。如果检索步骤指向了错误的文件簇，模型可能会在其上构建一个整洁却错误的故事。好的搜索是第一道护栏，不是可有可无的增强功能。

实用检查清单

1. 从一个最痛的工作流开始。 选一个任务，比如 bug 分诊、测试失败分析或依赖追踪。在你搞清楚最重要的搜索痛点之前，不要试图一次解决整个问题。

2. 比较前后的提示词大小。 跟踪输入 token、输出质量以及拿到第一条可用答案的时间。如果你说不出基线，就无法证明改进。

3. 记录每个片段为何被返回。 保留文件路径、符号和相关性信号。当模型出现奇怪跳跃时，可调试性非常重要。

4. 尽早清理无效负载。 排除第三方目录、构建产物和重复生成文件。这很便宜，而且往往能立刻见效。

5. 优先使用结构化检索，而不是原始文本倾倒。 给 agent 一个紧凑包：符号名、上下文行和依赖提示。通常这比粘贴整个文件更好。

6. 用糟糕查询来测试。 尝试重命名函数、残缺错误信息，以及像“那个 checkout 的东西在重试后坏了”这样的模糊描述。真实 agent 面对的是混乱，不是完美关键词。

7. 诚实地与 grep 对比。 对很多人类任务来说，grep 仍然更强。看看新搜索在哪些地方帮助了 agent，以及旧工具在哪些地方仍然更快、更简单。

8. 警惕虚假的自信。 如果 agent 变得更流利却不够准确，就收紧检索，并要求它把结论回指到源代码跨度。

什么时候不该这样做

并不是每个团队都需要一个以 agent 为先的搜索层。如果你的仓库很小、技术栈很整洁，而且任务主要由人来驱动，那么 grep 加上一个不错的 IDE 搜索就可能已经足够了。当真正的瓶颈是理解产品，而不是定位文件时，花哨的检索可能会变成一场表演。

如果你没有足够的运营纪律来评估输出，这也不是正确的做法。一个节省 token 的搜索引擎可以让实验更便宜，这很好，但它也可能让糟糕的 agent 行为变得更便宜。如果没人审查检索质量，你也许只是在以更低成本自动化混乱。

了解更多

• https://owasp.org/www-project-top-ten/ - 当 agent 接触代码时仍然重要的安全基础知识
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions - 提醒你 grep 式搜索底层到底在做什么的好资料
• https://en.wikipedia.org/wiki/Information_retrieval - 排序、相关性和搜索评估背后的更大领域

说实话，Semble 真正有趣的地方并不是那个营销数字——即使“少 98% 的 token”确实是个很好的标题。真正有趣的是：代码搜索正在被重建为先服务机器读者，再服务人类读者，而这一变化将重塑团队调试、修补和自动化软件的方式。问题不再是 agent 能不能搜索代码，而是你的搜索层是在帮助它们清晰思考，还是只是在喂给它们更多噪声。