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

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 生成的排名对齐。这样就形成了一个反馈回路，使模型能够从代理实际完成编码任务的过程中学习，而不是依赖通用的代码相似度。

总结

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

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