当代码智能体收到提示时，要给出正确答案，需要通过阅读文件并检索相关信息来建立对代码库的理解。

Cursor 的 Agent 使用的工具之一是语义搜索。除了像 grep 这类工具提供的基于正则的搜索之外，它还能根据自然语言查询（例如“我们在哪里处理身份验证？”）检索匹配的代码片段。

为支持语义搜索，我们训练了自有的嵌入模型，并构建了用于快速检索的索引管道。尽管你可以完全依赖 grep 等命令行工具进行搜索，但我们的实践表明，语义搜索能显著提升智能体的表现，尤其是在大型代码库中：

• 在回答问题方面，平均准确率提高 12.5%（视模型不同提升幅度为 6.5%–23.5%）。
• 生成更有可能在代码库中被保留的代码改动。
• 用户只需更少的迭代即可得到正确的解决方案。
• 在我们测试的所有模型（包括所有前沿代码模型）中均提升了准确性。

离线评估

我们维护了一个评估数据集 Cursor Context Bench，专注于在代码库中进行信息检索，并且具备已知的标准答案。该评估覆盖了 Cursor 中最常用的所有模型，包括我们自家的Composer。

此次对比在两套可用工具配置下评估性能：一套包含语义搜索，另一套不包含。无论何种配置，语义搜索都能显著改善效果。

在线 A/B 测试

我们也想了解这对终端用户体验的影响。我们进行了 A/B 测试：两组都使用相同的模型，但其中一组的代理可使用语义搜索，另一组则只依赖 grep 等传统搜索工具。我们关注两个指标：

• 代码留存：高效代理生成的代码更容易长期留存在用户代码库中。我们发现，在提供语义搜索的情况下，代理代码留存率提高了0.3%；在包含 1,000 个及以上文件的大型代码库中，这一提升幅度增至 2.6%。
• 不满意的用户请求：高效的代理编写的代码无需后续跟进或更正。当无法使用语义搜索时，我们观察到不满意的用户后续请求增加了 2.2%。

这里的效应值较低，因为这次 A/B 测试面向所有智能体查询，而并非所有请求都需要搜索。

自定义检索模型

促成这些成果的关键之一是我们的自定义嵌入模型。我们的方法将代理会话用作训练数据：当代理处理任务时，往往要在找到正确的代码之前进行多次搜索并打开若干文件。通过分析这些操作轨迹，我们可以事后判断在对话的更早阶段本应被检索到的内容。

我们将这些轨迹数据提供给 LLM，让它评估并排序每个步骤中最有帮助的内容。随后，我们训练嵌入模型，使其相似度评分与这些由 LLM 生成的排序保持一致。这样就形成了一个反馈回路，使模型能够学习代理在实际编码任务中的工作方式，而不是依赖通用的代码相似度。

总结

为取得最佳效果，尤其是在大型代码库中，目前需要使用语义搜索。

我们的 Agent 大量使用 grep 和语义搜索，两者结合能带来最佳效果。随着模型不断提升，我们会持续测试和评估提供给 Agent 运行框架的所有工具。