Cursor 如何训练自己的编程 Agent 模型

去年，Cursor 工程师 Lee Robinson 在 AI Engineer 大会上分享了 Composer 模型的构建过程。这不是一篇典型的"我们做了一个很酷的东西"的演讲——它更像是一份诚实的工程复盘，讲清楚了为什么要做、遇到了什么麻烦、以及哪些地方超出了预期。

值得注意的是 Robinson 的背景：他是前 Vercel 工程师，不是 ML 研究员。这个视角让这篇演讲格外有意思——他能把基础设施和机器学习训练之间的关联说得格外清楚。

从 Tab 到 Composer：为什么 Cursor 要自己训练模型

Cursor 进入模型训练领域的起点，是他们已有的一个成功案例：Tab。

Tab 是 Cursor 的自动补全功能背后的模型，定位是极低延迟。团队在 Tab 上积累了训练低延迟专用模型的经验，并想把同样的思路迁移到 Agent 场景。于是 Composer 的初始目标就是：一个既快又聪明的编程 Agent 模型。

早期原型发布时，他们给这个版本起了个内部代号"cheetah slug"，放出去收集反馈。结果出乎意料——用户非常喜欢速度，但普遍反映智能程度不够，无法作为日常驾驶工具。

这是一个很典型的产品信号：速度有了，智能还差。团队决定两手都要抓。

他们设定的检验标准也很实际：如果内部开发者愿意每天用这个模型来构建 Cursor 本身，那就说明做对了。这个"吃自己狗粮"的 benchmark，最终推动了 Composer 从原型走向可用。

RL 训练的核心思路

Composer 的训练核心是强化学习（RL）。

架构逻辑并不复杂：用户提交一个查询，Agent 读取后决定调用哪些工具，执行完成后根据结果质量更新模型权重。Cursor 的 Agent 大约有 10 个工具，演讲中重点提到了五个：读文件、编辑文件、搜索代码库、查看 lint 结果、运行 shell 命令。

RL 训练的关键在于 rollout：从同一个初始状态出发，模型会产生多条不同的工具调用路径。比如一条 rollout 选择了读文件 + 编辑文件，另一条选择了代码库语义搜索。对这些路径打分，然后根据分数更新参数。

概念上很清晰。但当你把这个想法规模化，麻烦就来了。

三大挑战：都是基础设施问题

Robinson 在演讲中明确说了一句话，值得记录下来：

“我们有三个机器学习挑战，而所有解决方案恰好都是基础设施问题。”

挑战一：训练环境与推理环境的对齐

Composer 是一个大型混合专家模型（MoE），训练时并行在数千张 GPU 上运行。如果训练时用的工具格式、响应格式和生产环境不完全一致，模型学到的东西在推理时就会出现偏差。

团队的解法是：尽可能让训练环境 = 生产环境，而不是用模拟或 mock。

挑战二：rollout 的复杂性与异步处理

真实的编程任务里，一个 rollout 可能涉及数十万到数百万 token，数百次工具调用，且每个 rollout 的完成时间差异极大——有的 rollout 调用了大量工具（比如安装依赖包），有的很快结束。

如果用朴素的同步方式处理，会有大量空等时间。解法是在不同线程和进程之间做负载均衡，确保推理服务器始终在做有效工作，而不是等某个慢 rollout 完成。

挑战三：训练负载的突发性

生产环境的推理流量是相对平稳的，但 RL 训练的计算需求是突发式的——某个阶段会集中爆发大量计算，然后再次平静。这和标准的云服务工作负载模式完全不同，需要专门的调度和编排能力。

三层服务器架构

为了应对上述挑战，Cursor 构建了三层服务器架构：

训练服务器（Trainer）：使用标准 ML 栈（PyTorch）管理模型权重和参数更新。

推理服务器（Inference Server）：使用 Ray 框架管理 rollout。负责调用工具、管理并发、把 advantage（优势估计）反馈给训练服务器。

环境服务器（Environment Server）：模拟真实的 Cursor 编程环境。这是整个架构里最有意思的一层。

环境服务器的基础，来自 Cursor 云端 Agent 产品的现有基础设施：每个任务都在独立的云端虚拟机（VM）里运行，VM 会加载用户代码，允许 Agent 在安全沙箱里做文件修改、运行工具、编辑代码。

Robinson 提到，这是一个偶然的完美契合——他们为云端 Agent 产品构建的 VM fleet，恰好也是 RL 训练所需要的理想环境。当前这个 fleet 规模在数十万台 VM。

此外，研究团队还开发了一套自定义内核库，支持极低精度（very low precision）训练，在 MoE 层上实现了约 3.5 倍的速度提升（基于 Nvidia Blackwell 芯片）。这让训练速度大幅加快，也让权重更容易部署到推理服务器。

语义搜索：被训练出来的"工具专家"

Composer 的一个值得关注的能力来自语义搜索。

Cursor 内部训练了自己的 embedding 模型，用于对用户代码库做索引。Agent 可以用自然语言查询来找到它想编辑的文件，而不是只能用 grep 做精确匹配。

训练团队做了一项研究，发现语义搜索能提升 Cursor Agent harness 里几乎所有模型的表现，而对 Composer 的提升尤为显著。

原因并不难理解：Composer 是在完全相同的环境里训练的，训练时它就在用这个语义搜索工具。经过大量 rollout，模型学会了如何高效使用这个工具——相当于成为了这个工具的"专家用户"。

这说明了训练/推理环境对齐的价值不只是避免分布偏移，还能让模型对特定工具形成深度利用。

飞机 WiFi 比喻：速度与智能的取舍

Robinson 在演讲中用了一个类比，我觉得相当准确：

“在飞机上用 WiFi，能用，但让人沮丧。你希望自己没有 WiFi，或者希望它快到可以正常工作。”

他把早期 coding agent 体验比作飞机 WiFi。等待 10 到 20 分钟，你进入了一种奇怪的状态：太快了不够完成任务，太慢了又浪费注意力。SWIX 把这叫做"semi-agentic valley of death"——半自动化的死亡谷。

Composer 想做的事，是把人从这个谷里拉出来：足够快，让你保持在 flow 里；足够聪明，真正帮你完成工作。

在效率数据上：Composer 在同等智能水平的模型中，token 生成效率约为其他模型的 4 倍。同时，并行工具调用（比如一次读取 10 个文件而不是逐个读取）进一步压缩了端到端的等待时间。

目前 Composer 的性能：超过最好的开源模型，接近但略低于最前沿的模型（Sonnet 4.5、GPT 5.1、Codex）。Robinson 的定位很明确——Composer 不是要做最强，而是要做速度和智能的最优平衡点。

他个人的工作流是：用 GPT 5.1 / Codex 这类顶级前沿模型做规划，然后把规划好的任务交给 Composer 执行。

RL 教会了模型什么

RL 训练带来的一个意外收获，是模型的 Agent 行为本身变得更好。

早期版本的 Composer 有一个明显问题：过度编辑。它会在还没完全理解代码的情况下就开始修改文件，导致很多不必要的改动。

随着训练推进，模型逐渐学会了一种更合理的工作模式：先通过搜索和读文件充分理解代码，再做有针对性的编辑。

这个变化不是人工设计规则实现的，而是从 rollout 的评分反馈中自然涌现的——模型发现"先读再改"能得到更好的分数。Robinson 提到自己对这一点"感到惊讶"。

这在某种程度上印证了 RL 在特定领域专业化训练上的价值：给它正确的环境和评分函数，它能自己学会更好的行为策略。

几个值得记住的启示

1. ML 挑战与基础设施问题是同一件事

Robinson 反复强调了这一点。训练/推理对齐、rollout 异步处理、训练负载的突发性——这些看起来是机器学习问题，本质上都是分布式系统和基础设施问题。对于想进入这个领域的人，这意味着 ML 技能和系统工程技能缺一不可。

2. 专用模型的 RL 可行性已经被证明

Cursor 不是在做通用智能，而是在做编程这个垂直任务的专用优化。Robinson 的观察是：在高质量数据和足够计算资源的条件下，RL 在专用领域的效果"出乎意料地好"。这对其他垂直领域（医疗、法律、金融）是一个参考信号。

3. 训练与产品的共演化是护城河

Cursor 同时拥有 IDE 产品和模型训练能力，让他们可以共设计（co-design）工具和训练环境。Composer 的语义搜索能力，正是这种共演化的产物。纯粹的模型公司或纯粹的工具公司，都很难单独做到这一点。这可能是 Cursor 真正的技术壁垒所在。

本文基于 Lee Robinson 在 AI Engineer 大会上的演讲整理。