Cursor Composer 2:Real-time RL 与 Self-summarization 技术解析
深入分析 Cursor Composer 2 的生产环境训练架构、Self-summarization 机制、5 小时 RL 闭环及基础设施设计。
Composer 2 的定位与能力
Cursor Composer 2 是 Cursor 公司自研的 agentic 软件工程模型,专为自主编程任务设计。与通用的代码补全模型不同,Composer 2 具备以下能力:
flowchart LR
subgraph "Composer 2 Core Capabilities"
A[代码阅读与编辑] --> B[Shell 命令执行]
B --> C[代码库搜索]
C --> D[Web 浏览]
D --> E[多文件协调修改]
end
与传统代码模型的差异
| 维度 | 传统代码模型 | Composer 2 |
|---|---|---|
| 任务范围 | 单文件补全 | 跨文件项目级修改 |
| 交互模式 | 一次性响应 | 多轮工具调用迭代 |
| 环境感知 | 仅当前文件 | 完整开发环境 |
| 学习能力 | 静态权重 | 实时 RL 更新 |
生产环境训练:Shadow Deployment
为什么必须在生产环境中训练?
公开基准测试如 SWE-bench 存在一个根本问题:与真实场景的分布不匹配。
| 维度 | SWE-bench | 真实开发场景 |
|---|---|---|
| 环境 | 简化的 Docker 容器 | 完整的开发环境 |
| 提示 | 详细的规格说明 | 模糊的、不完整的描述 |
| 代码变更 | 平均 7-10 行 | 中位数 181 行 |
| 验证标准 | 预定义测试 | 用户满意度 |
| 任务类型 | Bug 修复为主 | 功能开发、重构、调试 |
Cursor 的关键洞察是:如果要在真实场景表现好,就必须在真实场景中训练。
Shadow Deployment 架构
Cursor 维护了一个影子部署(shadow deployment)系统,确保训练环境与生产环境完全一致:
flowchart TD
subgraph "生产环境"
A[用户请求] --> B[生产后端]
B --> C[生产工具]
C --> D[LLM API]
end
subgraph "Shadow 训练环境"
E[训练 Rollout] --> F[影子后端]
F --> G[相同工具]
G --> H[训练模型]
end
B -.->|配置同步| F
C -.->|行为一致| G
关键一致性保证:
- 相同的工具集合(语义搜索、代码编辑、Shell 执行等)
- 相同的提示格式和系统消息
- 相同的文件上下文处理逻辑
- 相同的工具行为(如语义搜索的返回格式)
CursorBench:内部评估基准
为了解决公开基准的不足,Cursor 构建了 CursorBench:
| 特征 | SWE-bench | CursorBench |
|---|---|---|
| 数据来源 | 开源 GitHub Issues | Cursor 内部工程团队真实会话 |
| 平均代码变更 | 7-10 行 | 181 行(中位数) |
| 提示长度 | 详细规格 | 简短、模糊 |
| 任务复杂度 | 单一 bug 修复 | 多步骤功能开发 |
| 与产品同步 | 静态 | 随产品进化 |
CursorBench 采用协同进化策略:随着用户不断挑战 agent 的极限,benchmark 也变得越来越复杂。
RL 基础设施:四大解耦服务
Composer 2 的 RL 基础设施由四个独立的解耦服务构成:
flowchart LR
subgraph "RL Infrastructure"
A[Training] --> B[Environments]
A --> C[Inference]
A --> D[Evaluations]
B --> E[Anyrun Platform]
C --> F[Fireworks AI]
D --> G[Pinned Backend]
end
1. 训练服务(Training)
- 框架:基于 Ray 和 PyTorch 的全异步栈
- 算法:GRPO(Group Relative Policy Optimization)的变体
- 更新:全参数更新,单 epoch(每个 prompt 只训练一次)
2. 环境服务(Environments)
每个 rollout 运行在专用的 Firecracker 微虚拟机中:
| 特性 | 规格 |
|---|---|
| 调度能力 | 500+ pods/秒 |
| 快照支持 | 文件系统级快照和分叉 |
| 应用场景 | 完整开发环境,支持浏览器和 GUI |
| 平台 | 内部平台 Anyrun |
快照与分叉的价值:
- 可以在 trajectory 中间创建 checkpoint
- 支持从同一状态探索多个不同分支
- 便于调试和错误复现
3. 推理服务(Inference)
Cursor 与 Fireworks AI 合作提供 RL 推理服务:
- 权重同步:每个训练步骤通过 S3 进行 delta 压缩上传
- 分片策略:跨训练 rank 进行权重分片
- 在线更新:推理 worker 可以在 rollout 中间更新权重,保持后续 token 的 on-policy 性
4. 评估服务(Evaluations)
- 环境:固定的生产后端和 Cursor client 副本
- 置信度:确保评估行为与用户看到的完全一致
- 回归检测:新 checkpoint 必须通过 CursorBench 才能部署
Self-summarization:处理长会话
问题:长 Horizons 的挑战
真实的编码任务可能非常长:
- 数十次工具调用
- 读取大量文件
- 数百轮迭代
在有限的上下文窗口(即使 128K tokens)中,模型很快会”遗忘”早期的重要信息。
Self-summarization 机制
Composer 2 采用自我总结来解决这个问题:
sequenceDiagram
participant Model
participant Context
participant Summary
loop 多轮迭代
Model->>Context: 生成响应 + 工具调用
Context->>Context: 上下文增长
opt 触发总结条件
Model->>Summary: 生成关键信息摘要
Summary->>Context: 替换详细历史
end
end
Model->>Model: 最终结果
关键设计:
- 总结不是固定的规则触发,而是模型自己学习何时总结
- 最终的 outcome reward 应用于整个 chain 的所有 token
- 好的总结(保留关键信息)得到强化
- 差的总结(丢失重要上下文)被惩罚
总结策略的学习
模型通过 RL 学习何时总结:
| 场景 | 学到的行为 |
|---|---|
| 复杂任务 | 多次总结 |
| 简单任务 | 可能完全不总结 |
| 关键决策前 | 主动总结以确保信息完整 |
在困难任务中,模型经常会在关键决策点进行多次总结,确保重要信息不会丢失。
Real-time RL:从生产流量学习
5 小时闭环
Cursor 最创新的设计是 Real-time RL —— 从真实生产流量中持续学习:
flowchart LR
A[收集生产 Token] --> B[蒸馏用户反馈]
B --> C[训练新 Checkpoint]
C --> D[CursorBench 验证]
D -->|通过| E[部署]
D -->|失败| F[回滚]
E --> A
完整循环时间:约 5 小时
这意味着 Cursor 每天可以部署多个改进版本,保持模型几乎与数据同政策(on-policy)。
用户反馈蒸馏
如何从用户交互中提取训练信号?
| 信号类型 | 具体指标 | 奖励权重 |
|---|---|---|
| 采纳率 | 用户是否接受建议 | 高 |
| 后续修改 | 用户是否继续编辑 | 中 |
| 回滚 | 用户是否撤销修改 | 负 |
| 会话长度 | 任务是否一次完成 | 正相关 |
| 重复查询 | 用户是否重复问同样问题 | 负 |
这些信号被聚合成 reward,用于训练模型。
保持 On-policy
RL 训练的一个关键挑战是分布偏移(distribution shift):随着模型改进,它生成的数据分布也在变化,旧的训练数据可能不再适用。
Cursor 的解决方案:
- 极短的训练循环(5 小时)
- 实时权重同步到推理服务
- 优先使用最新的生产数据
这确保了生成数据的模型与被训练的模型几乎相同。
算法细节:GRPO 变体
Composer 2 使用的策略梯度算法是 GRPO 的变体,但有两个关键修改:
1. 移除 Length Standardization
标准 GRPO 包含长度标准化项:
# 标准 GRPO(含长度偏置)
advantage = (reward - mean) / std
advantage -= λ * length_penalty # 这会引入长度偏置
Cursor 发现这会导致模型故意生成更短的响应来获得更高的 advantage,即使长响应可能更正确。
解决方案:完全移除长度标准化项。
2. 移除标准差标准化
标准 GRPO 使用组内标准差进行 advantage 标准化:
# 标准 GRPO
advantage = (reward - mean) / std
但在某些情况下,组内所有 rollout 的正确性相同(全对或全错),此时 std = 0,导致梯度爆炸或噪声放大。
解决方案:跳过标准差标准化,仅使用中心化(减去 mean)。
Multi-Token Prediction (MTP)
Composer 2 训练了额外的 MTP 层用于投机解码(speculative decoding):
flowchart LR
A[输入 Token] --> B[主 LM Head]
A --> C[MTP Layer 1]
A --> D[MTP Layer 2]
B --> E[Token t+1]
C --> F[Token t+2]
D --> G[Token t+3]
训练方式:
- MTP 层从 scratch 初始化
- 学习预测主 LM head 在每个位置的精确 logit 分布
- 使用 self-distillation:MTP 层模仿主模型的输出
- 在长上下文和 SFT 阶段后进行联合微调,然后进入 RL
效果:推理速度提升 2-3 倍,质量损失极小。
优势与局限
优势
| 优势 | 说明 |
|---|---|
| 真实场景优化 | 训练环境与生产环境完全一致 |
| 快速迭代 | 5 小时闭环支持每日多次部署 |
| 长任务处理 | Self-summarization 解决长 horizon 问题 |
| 效率提升 | MTP 投机解码加速推理 |
局限与挑战
| 局限 | 说明 |
|---|---|
| 基础设施要求高 | 需要复杂的 shadow deployment 和实时同步 |
| 用户隐私 | 从生产流量学习需要处理敏感数据 |
| 反馈噪声 | 用户行为作为 reward 信号存在噪声 |
| 冷启动问题 | 新功能缺乏用户反馈数据 |
参考资料
- Cursor Composer 2 Blog Post - Cursor 官方博客
- Group Relative Policy Optimization (GRPO) - 策略梯度算法
- Fast Inference from Transformers via Speculative Decoding - 投机解码技术
- Firecracker: Secure and Fast microVMs - Firecracker 虚拟机