Building Cursor Composer — 完整演讲转录

演讲者: Lee Robinson (Cursor 工程师，前 Vercel DX Lead) 场合: AI Engineer 大会（纽约） 时长: 15:36 原视频: YouTube

第 1 章：Cursor Composer 是什么，为什么要做它 [00:00:20 - 01:15]

Lee Robinson: 很高兴回到纽约，非常兴奋能在这里代表 Cursor 全体工程和研究团队，跟大家聊聊我们是怎么构建 Cursor Composer 的。我的同事 Sasha 最近也做过一版类似的分享，今天我想讲讲我自己的视角和理解。

Composer 是一个专为真实世界软件工程场景设计的模型，我们的目标是让它同时具备速度和智能。根据我们自己的 benchmark 测试，它的表现优于最好的开源模型，跟近期的前沿模型相比也很有竞争力——大概略低于最新的 Sonnet 4.5 和 GPT 5.1 Codex 这个量级。但 Composer 真正出彩的地方是：在相同智能水平的模型中，它的 token 生成效率大约是同类模型的四倍。我们追求的是速度与智能的结合。

第 2 章：为什么 Cursor 要自己做模型 [01:15 - 02:27]

Lee Robinson: 那为什么我们要做这件事？Cursor 本身是一个 IDE，为什么要进入模型研究领域？

我们的研究和产品团队此前一直在做一个叫 Tab 的模型——就是 Cursor 里的代码补全功能，也许你们有人在用。我们想把这个低延迟模型的思路延续下来，应用到 coding agent 的场景里。说实话，一开始我们也不确定这条路走不走得通。所以我们先做了一些早期原型，放出去收集用户反馈。

结果有点出乎意料——我们为这个模型发布了一个"猎豹版"（cheetah slug），用户反馈出奇地好，大家真的很喜欢它的速度。但反馈里也很清楚地写着：它还不够聪明，还没到可以作为日常开发主力的程度。所以我们面临的挑战是：既要快，也要聪明，缺一不可。

第 3 章：内部 Benchmark 与并行工具调用 [02:00 - 03:30]

Lee Robinson: 于是我们花了大量精力打造一个内部 benchmark，这个 benchmark 要真实反映我们自己日常开发的方式——用我们自己的代码库，跑我们真实写代码的流程。逻辑很简单：如果我们团队的工程师愿意每天用这个模型来开发产品，那就说明它真的够用了。

在整个优化过程中，有一个关键突破让模型从"还行"跨越到了"工程师愿意每天用"的门槛——那就是并行工具调用，以及非常高效地使用我们的语义搜索工具。这两点让 Composer 的实际体验发生了质的变化，后面我会详细展开。

第 4 章：Composer 实际运行演示 [03:30 - 05:00]

Lee Robinson: 先来看一段演示。这是 Cursor 2.0 的新界面，用的是 Composer 1 模型。你会注意到它同时在做很多事情：并行调用 grep 等工具、大量读取文件、执行 shell 命令、编辑文件、维护一个动态的待办列表——在前台就能快速推进任务。演示里我在排查一个开源 repo 里的 bug。

说句心里话，和 coding agent 打交道这段时间，这种体验跟以前真的很不一样。以前的感觉是：你发出一个任务，然后等，少说等 20 分钟，你只能切换到别的事情去。而现在这种交互方式让你真正保持在心流状态里——这是一种完全不同的编程风格。

第 5 章：RL 训练的三大挑战 [05:00 - 07:30]

Lee Robinson: 接下来我想讲讲我们是怎么做到的——尽量讲得通俗一点。我本人不是 ML 研究员，但我真的很喜欢这些东西。

先讲一下基本流程。在 Cursor 里，用户发一个请求到后端，agent 读取这个请求，然后决定发起一系列工具调用。我们的 agent 大概有 10 个工具左右，重点讲五个：读文件、编辑文件、搜索代码库、查看 lint 错误、执行终端命令。Agent 会自主决定这些工具调用是串行还是并行执行。

我们做强化学习（RL）的目标是：尽可能精确地复现 Cursor 生产环境。训练数据里的每一次 rollout，我们都希望它像真实的 Cursor 请求一样。比如一次 rollout 里我们调用了读文件和编辑文件；换一次 rollout 从同一个起点出发，可能走了完全不同的工具调用路径，比如做代码库搜索。我们给输出打分，判断哪个更好，然后根据结果更新模型参数。思路其实很简单，难就难在扩大规模上。

这里有三个主要挑战：第一，训练环境和推理环境要尽量一致；第二，rollout 的复杂度很高——模型要处理数十万到百万 token，发起数百次工具调用，每次 rollout 耗时差异极大；第三，一致性问题——工具格式和工具响应必须和生产环境完全一致，但训练时的计算负载是极度集中爆发的，和生产环境的分布式推理完全不同。

第 6 章：基础设施解法——三层服务器架构与云端 VM [07:30 - 10:30]

Lee Robinson: 这三个 ML 挑战，解法说来有趣——全都是基础设施问题。

我们的架构分三层：训练服务器（标准 ML 栈，PyTorch）、推理服务器（用 Ray 管理 rollout）、环境服务器（模拟 Cursor 生产环境）。三层服务器相互通信：推理服务器把每次 rollout 的优势分数（advantage）传回训练服务器，训练服务器更新参数，再把新权重发回推理服务器。

为了让模型训练又快又大，我们研究团队自研了一套自定义 kernel 库，支持超低精度训练。这套方案显著加速了训练过程，也让权重更容易迁移到推理服务器。具体来说，在 MoE 层上，Nvidia Blackwell 芯片实现了约 3.5 倍的速度提升——对训练周期的影响非常显著。细节我们写了一篇深度博客，感兴趣的可以去看。

权重更新后，推理服务器要做的事情是：跑大量 rollout，不断调用工具，处理工具返回结果。挑战在于每个 rollout 耗时不一。解法是在不同线程和进程间做负载均衡，把工作动态分配，避免大量空转等待——比如一个 rollout 在装依赖包，不能让整个系统都傻等它。

Lee Robinson: 环境服务器这块，我们做了一件非常划算的事：我们在做 RL 训练基础设施的同时，正好也在开发 Cursor 的云端 Agent 产品——就是那个可以从手机、浏览器或者 Slack 发起 Agent 任务的功能。这个产品的基础设施是：为每个任务启动一个云端 VM，加载用户代码，让 agent 在安全沙箱里改文件、跑工具、编辑代码。这套 VM 基础设施和 RL 训练需要的环境几乎完美吻合。

所以我们直接复用了这个云端 VM 集群——数十万台 VM——作为 RL 训练的环境服务器。我们还用 Composer 本身写了一个内部仪表盘来可视化整个 VM 集群的状态，就是屏幕后面那张图。

为什么要花这么大力气让训练环境贴近生产？因为这样做有一个极其重要的好处：我们可以让模型在训练时就使用我们为 agent 专门打造的工具。其中最关键的是我们自训练的 embedding 模型，它支持对代码库做语义搜索——用自然语言就能找到相关文件。我们的研究发现，语义搜索对 Cursor agent 体系里几乎所有模型都有帮助，而对 Composer 的提升尤为显著——原因不难理解，因为 Composer 就是在使用这个工具的环境里训练的，模型本身成了这个工具的"超级用户"。

第 7 章：发布反馈与未来方向 [10:30 - 15:15]

Lee Robinson: 来聊聊发布之后的情况和我们接下来的方向。

在训练过程中，我们判断 RL 是否生效的标准很直接：随着 rollout 不断增加，模型性能是否持续提升。我们从大概和最好的开源模型持平的水平起步，随着训练推进和算力投入，性能持续爬坡——今天已经接近前沿的 coding agent 水平。对我个人来说，这是一个很振奋的信号：把 RL 扩展应用到高度垂直的专业任务（比如 coding），是切实可行的——而且这个思路未必局限于 coding，可以迁移到其他领域。

RL 还让我们能够有针对性地改变模型的行为特性。我们希望 Composer 既能快速生成 token，又能给用户一个端到端感觉顺畅的结果。举个例子：与其一个一个读文件，Composer 可以并行读 10 个文件——这让实际体验快了很多，演示里你也看到了。我们觉得这只是起点，这个方向还有很大空间。

另一个有意思的变化是：模型学会了更好地"做 agent"。早期模型有点着急，动不动就改代码，很多改动其实不必要。随着训练深入，模型自己学会了先搜索、先读文件，找准了再动手——整体效率提升很明显。

Lee Robinson: Composer 上个月随 Cursor 2.0 一起正式发布，目前反响不错。在座有没有试过这个模型的？哦，还不少——比我预期的多，太好了。

我个人有个比喻来形容早期 coding agent 的体验：就像飞机上的 Wi-Fi。能用，但用得挺憋屈。你想做事，但它就是慢，有时候你宁愿没有它。对于早期用户来说，coding agent 就有这种感觉——如果一个任务要跑 10 到 20 分钟，你就卡在一个很尴尬的中间地带，SWIX 把它叫做"半自动的死亡谷"——你要么想要极速响应的东西，要么就要最强大的模型放在后台跑几十分钟甚至几个小时。卡在中间最痛苦。

对我来说，Composer 把那种写代码的喜悦感带回来了——那种你很在状态、很同步、很掌控的感觉。我现在的日常工作流是：用最前沿的大模型（比如 GPT 5.1 Codex）来写计划、做思路梳理，然后把这个计划交给 Composer，让它真正去把事情做出来——就像 Dex 讲的那套 context engineering 思路：先规划，再执行。

Lee Robinson: 最后分享几点我们团队在构建 Composer 过程中的体会。

第一，RL 在训练高度专业化模型上的效果出乎意料地好——给它高质量数据和合理的算力，它能做到很多你意想不到的事情。Cursor 不是在做通用智能，不是在做 AGI，我们就是想做最好的 coding 模型，RL 在这件事上表现超出预期。

第二，AI 工具本身就在加速 AI 研究。我们全团队都在用 Cursor 写代码、debug，这个效率提升在整个工程团队里形成了复利——我们能更快地试验想法、更快地迭代产品、推进更多研究方向。

第三，也是对我个人来说最有共鸣的一点：ML 工作和基础设施工作的边界比我们想象的要模糊得多。回想我在 Vercel 的经历，前端框架那些"魔法时刻"背后，同样需要认真思考实际部署的基础设施。两件事比大多数人以为的关联更深。

如果今天分享的方向让你感兴趣，Cursor 现在各个方向都在招人。我们刚在纽约开了新办公室，如果你在纽约，很欢迎来聊聊——一起来做世界上最好的 coding 模型。谢谢大家。

由 AssemblyAI 转录，经可读性优化。