当编码智能体接收到一个请求时，要返回正确答案，就需要通过阅读文件和搜索相关信息来建立对代码库的理解。

Cursor 的智能体使用的一项工具是语义搜索，它可以根据自然语言查询检索匹配的代码片段，例如“我们在哪里处理认证逻辑？”，作为对 grep 这类基于正则表达式搜索工具的补充。

为了支持语义搜索，我们训练了自研的嵌入模型，并构建了用于快速检索的索引流水线。虽然理论上可以完全依赖 grep 和类似的命令行搜索工具，但我们发现语义搜索可以显著提升智能体性能，尤其是在大型代码库上：

• 在回答问题时平均实现 12.5% 更高的准确率（根据模型不同为 6.5%–23.5%）。

• 生成的代码修改更有可能在代码库中被保留。

• 用户达到正确解决方案所需的迭代次数更少。

• 提升我们测试过的所有模型的准确率，包括所有最前沿的编码模型。

#离线评估

我们维护了一个名为 Cursor Context Bench 的评估数据集，专注于在代码库中检索具有已知正确答案的信息。我们会在 Cursor 中所有最常用的模型上运行这套评估，其中包括我们自研的 Composer。

对比考察了在两种可用工具组合下的表现：一种包含语义搜索，另一种不包含语义搜索。在所有配置下，语义搜索都能显著提升效果。

#在线 A/B 测试

我们还希望了解这对终端用户体验的影响。我们进行了一个 A/B 测试，两组都使用同一个模型，但其中一组的 agent 可以使用语义搜索，而另一组则只能依赖像 grep 这样的传统搜索工具。我们关注两个指标：

• 代码保留率（Code Retention）：高效 agent 编写的代码更有可能保留在用户代码库中。我们发现，当提供语义搜索时，agent 代码保留率提高了 0.3%。在包含 1,000 个及以上文件的大型代码库中，这一提升进一步扩大到 2.6%。

• 不满意的用户请求（Dissatisfied User Requests）：高效 agent 编写的代码不需要任何后续追问或纠正。我们观察到，在不提供语义搜索时，不满意的后续用户请求增加了 2.2%。

这里观测到的效果更小，因为 A/B 测试覆盖的是所有 agent 查询，而并非所有请求都需要进行搜索。

#自定义检索模型

实现这些效果的关键之一是我们的自定义 embedding 模型。我们的做法是使用 agent 会话作为训练数据：当一个 agent 处理任务时，它会在找到正确代码之前进行多次搜索并打开多个文件。通过分析这些操作轨迹，我们可以事后判断，在对话的更早阶段本应检索到哪些内容。

我们将这些轨迹提供给一个 LLM，由它来排序在每一步中哪些内容会最有帮助。然后我们训练 embedding 模型，使其相似度评分与这些由 LLM 生成的排序对齐。这样就形成了一个反馈回路，使模型能够从 agent 实际完成编码任务的方式中学习，而不是仅仅依赖通用的代码相似度。

#总结

在当前阶段，要获得最佳效果，语义搜索是必不可少的，尤其是在大型代码库中。

我们的 Agent 大量使用 grep 和语义搜索，两者结合能够带来最好的效果。随着模型不断改进，我们也会持续测试和评估提供给 Agent 执行环境的所有工具。