Cursor 自研 Composer 2：1万亿参数 MoE + 强化学习，编程 Agent 性能暴涨 61%

💡 Cursor 团队公开了 Composer 2 的完整技术报告，详细披露了从基座选型、继续预训练、大规模 RL 到自研评测基准的全流程。这是目前公开的、最详尽的 编程 Agent 专用模型训练 技术方案之一。

论文标题：Composer 2 Technical Report

作者：Aaron Chan, Ahmed Shalaby, Alexander Wettig, Aman Sanger, Andrew Zhai 等 50+ 位研究者（Cursor Research）

发布时间：2026 年 3 月 25 日

论文链接：https://arxiv.org/abs/2603.24477

一、核心摘要

Composer 2 是 Cursor 团队针对 Agentic 软件工程 场景专门训练的模型。基座选用 Kimi K2.5（总参数 1.04T，激活参数 32B 的 MoE 架构），经过两阶段训练：继续预训练强化代码知识 + 大规模强化学习提升端到端任务完成能力。

关键数字：

  • CursorBench-3：61.3%（对比上一代 Composer 1.5 的 44.2%，相对提升 37%）
  • SWE-bench Multilingual：73.7%
  • Terminal-Bench：61.7%

Composer 2 在 CursorBench 上的表现对比 图1：Composer 2 与多个前沿模型在 CursorBench-3、SWE-bench Multilingual、Terminal-Bench 三项基准上的对比。Composer 2 在 CursorBench 上以 61.3% 位居自研模型之首，接近 GPT-5.4 的 63.9%。

二、问题动机：公开基准已经不够用了

Cursor 团队提出了现有编程评测基准的 四大缺陷：

缺陷 具体表现
领域失配 SWE-bench 聚焦孤立的 bug 修复，无法覆盖开发者日常的多样化工作流
Prompt 过度指定 公开基准假设窄解空间，真实请求往往欠指定、存在多个合理方案
数据污染 公开基准取材于历史开源仓库，频繁泄漏到训练数据中。OpenAI 曾因前沿模型能从记忆中生成 gold patch 而暂停 SWE-bench Verified 上报
评估维度单一 仅测功能正确性，忽略代码质量、可读性、延迟、成本和交互行为

为此，团队构建了 CursorBench——直接取材于 Cursor 工程团队真实编程会话的评测集。一组关键对比数据揭示了差异之大：

指标 CursorBench SWE-bench
修改行数中位数 181 行 7-10 行
问题描述长度中位数 390 字符 1185-3055 字符

CursorBench 的任务更大、描述更短——这恰恰更贴近真实场景：开发者给出简短指令，Agent 需要理解意图并做出大规模代码修改。

CursorBench 与公开基准的修改行数分布对比 图2：CursorBench 任务的修改行数中位数达 181 行，远超 SWE-bench 的 7-10 行，更真实地反映了工程实践中 Agent 需要处理的任务规模。

问题描述长度对比 图3：CursorBench 的问题描述反而更短（中位数 390 字符），对应真实开发中用户给出简短指令、期望 Agent 自行推理意图的场景。

三、方法设计

3.1 基座选型：为什么是 Kimi K2.5？

团队对多个候选基座进行了系统评估，评估维度包括 FreshBench 知识准确度、状态追踪能力和负对数似然：

模型 FreshBench ↑ 状态追踪 ↓ 负对数似然 ↓
GPT-5.4 92.5% 103 —
Claude 4.6 Opus 88.9% 65 —
Gemini 3 Flash 84.5% 27 —
Kimi K2.5 83.2% 86 13.81M
DeepSeek V3.2 68.9% 66 11.75M
GLM-5 79.2% 92 14.11M

最终选定 Kimi K2.5（1.04T 总参数，32B 激活参数的 MoE），兼顾了模型能力与可训练性（闭源 API 模型无法继续预训练）。

3.2 继续预训练：三阶段流水线

训练分为 三个阶段：

  1. 主训练阶段：32k 序列长度，以代码为主的大规模数据混合训练
  2. 长上下文扩展：序列长度提升至 256k
  3. 监督微调：面向编程任务的 SFT

关键技术细节： - 精度：在 NVIDIA B300 上使用 MXFP8 - 优化器：AdamW - 多 Token 预测：独立初始化的预测层，通过自蒸馏匹配主 LM head 的 logits

一个重要发现——交叉熵损失可以预测下游 RL 性能。团队在 Qwen3-Coder-30B-A3B 上验证了这一点：三组对数间隔的计算量预训练后分别做 SFT + RL，预训练 loss 越低，RL reward 越高。

预训练 loss 与 RL reward 的关系 图4：交叉熵损失与下游 RL 性能之间存在可预测的关系。预训练阶段投入更多计算量降低 loss，能直接转化为更高的 RL reward。

3.3 强化学习：精细化的策略梯度

RL 是 Composer 2 的核心提升来源。团队采用了多样本策略梯度方法，关键设计决策包括：

算法选择： - 每个 prompt 采样多个样本，固定 group size - 单 epoch 训练（同一 prompt 不会被训练两次） - Adam 优化器，全参数更新 - 移除了 GRPO 中的长度标准化项（避免长度偏差） - 不对 group advantage 做标准差归一化（防止小差异被过度放大）

KL 散度正则化——选用 \(k_1 = -\log r\) 而非 \(k_3 = (r-1) - \log r\)：

KL 估计器的方差对比 图5：\(k_3\) 估计器在 KL 值较大时方差急剧增大，而 \(k_1\) 估计器保持稳定。这一看似微小的选择对训练稳定性影响重大。

非线性长度惩罚——这是一个精巧的设计：

\[C_{\text{length}}^{k,q}(x) = \frac{(1+kx)^{1-q} - 1}{k(1-q)}\]

其中 \(x\) 是思考 token、工具调用 token、工具输出 token、最终消息 token、工具调用次数和对话轮次的加权组合。设计直觉：简单任务上每增加一次工具调用的"代价感"应该比复杂任务更强烈。

长度惩罚对比 图6：非线性长度惩罚函数的曲线。对简单任务施加更强的效率约束，对复杂任务则更宽容，鼓励模型学会高效行为（如并行工具调用）。

奖励设计分两层： - 功能性奖励：代码正确性（主要）、简洁性、软件工程原则遵从度 - 行为性奖励：编码风格、沟通质量、产品特定惩罚（如遗留未完成的 TODO、低质量工具调用）

3.4 自摘要技术：突破上下文窗口限制

这是一个工程性很强的创新。每个训练 rollout 由多个 generation 通过摘要串联而非单一的 prompt-response 对。最终奖励应用于整条链路的所有 token。

好处： - 好的轨迹中，Agent 响应和使其成功的摘要都被上调权重 - 丢失关键信息的差摘要被下调权重 - 在有限上下文窗口内实现长时域工作 - 比单独基于 prompt 的压缩更少引入错误 - 使用更少 token，复用 KV cache

3.5 训练基础设施：跨区域分布式 RL

训练基础设施架构 图7：Composer 2 的分布式 RL 基础设施架构。训练、环境、推理、评估四个组件解耦部署，跨 3 个 GPU 计算区域和 4 个 CPU 计算区域。

并行策略创新： - 上下文并行作为长上下文扩展的主轴（比张量并行通信开销更低）：预训练 CP=2，RL 阶段 CP=8 - 专家并行与张量并行解耦：EP=8，使用 DeepEP 做高吞吐 token 分发 - Token 在分发前量化为 MXFP8，合并时用 BF16 保证精度

低精度训练的关键细节： - 前向传播使用自研的 NVFP4 变体（FP4E2M1 + 逐块 FP8E4M3 scale + 逐 token FP32 scale），解决了原始 NVFP4 逐张量 scale 导致的批次依赖训练问题 - 反向传播使用标准 MXFP8 保证稳定性 - 关键发现：NVFP4 必须使用 IEEE 精确除法（__fdiv_rn），快速近似路径在约 100 RL 步后导致发散；而 MXFP8 可以使用快速近似

MoE 路由回放（Router Replay）：推理引擎返回每个 token 在每个 MoE 层被选中的专家索引，训练时覆盖路由决策以匹配推理时的选择。配合可信度过滤——门控分数低于阈值的回放专家会被替换为路由器的候选。

四、实验结果

4.1 主实验对比

模型 CursorBench-3 SWE-bench Multi. Terminal-Bench
Composer 2 61.3 73.7 61.7
Composer 1.5 44.2 65.9 47.9
Composer 1 38.0 56.9 40.0
GPT-5.4 63.9 76.8 66.5†
GPT-5.3 Codex 59.1 74.8 64.8†
GPT-5.2 56.5 68.3 60.5
Opus 4.6 High 58.2 75.8 58.0
Opus 4.5 High 48.4 73.8 52.1
GLM-5 42.7 66.9 59.6
Kimi K2.5（基座） 36.0 65.1 47.3

†注：OpenAI 安全过滤器拒绝了 5 个 GPT-5.4 和 3 个 GPT-5.3-Codex 的任务，被拒任务按 0 分计。

核心结论： - 从基座 Kimi K2.5 的 36.0% 提升到 61.3%，绝对提升 25.3 个百分点 - 超过 Opus 4.6 High（58.2%）和 GPT-5.3 Codex（59.1%），接近 GPT-5.4（63.9%） - 相比 Composer 1.5，三项基准分别提升 17.1、7.8、13.8 个百分点

4.2 RL 训练动态

RL 训练过程中 reward 曲线 图8：RL 训练过程中平均 reward 和 best-of-K reward 均持续提升。这与近期文献中「RL 仅重新分配概率质量」的观点不同——Composer 2 的 RL 确实在扩展模型的正确解覆盖范围。

一个重要的实验发现：平均 reward 和 best-of-K 性能同时提升。近期有研究指出 LLM 上的 RL 主要通过集中概率质量到已知轨迹来提升平均表现，有时以策略熵为代价。但 Composer 2 的结果表明，RL 不仅在重新加权已有推理路径，还在改善模型对正确解的有效覆盖。

4.3 效率分析

性能 vs 推理成本 图9：Composer 2 在准确率-推理成本的 Pareto 前沿上表现优异。推理成本接近小模型或低计算量变体，但准确率与大型前沿模型持平——领域专用训练使模型同时更准确且更具成本效益。

4.4 CursorBench 演进

CursorBench 各版本任务复杂度变化——修改行数 图10：CursorBench 从 V1 到 V3，任务中位修改行数增加了 2 倍以上，反映了评测基准随 Agent 能力提升而持续升级。

CursorBench 各版本任务复杂度变化——涉及文件数 图11：CursorBench 各版本涉及的文件数量分布。V3 版本任务涉及更多文件，更接近真实工程场景的复杂度。

五、批判性思考

亮点

  1. 端到端工程闭环的稀缺公开：从基座选型、预训练数据策略、RL 算法设计、分布式训练基础设施到自研评测基准，一份报告覆盖完整链路。这种级别的技术透明度在商业模型中极为罕见。

  2. 交叉熵 loss 预测 RL 性能：这个发现具有很强的实用价值——可以在预训练阶段就预估 RL 阶段的收益，大幅降低实验成本。

  3. 非线性长度惩罚的设计直觉出色：对简单任务施加更强的效率约束、对复杂任务更宽容，比简单的 token 数惩罚更符合软件工程实践。

  4. Best-of-K 性能同步提升的发现，挑战了「RL 仅重排概率质量」的主流观点，对 RL for LLM 的理论理解有实质贡献。

  5. Router Replay + 可信度过滤——巧妙解决了 MoE 模型异步 RL 中训练-推理一致性问题，兼顾了工程效率和数值稳定性。

局限

  1. 关键细节缺失：预训练数据的具体组成比例、RL 超参数（学习率、batch size、长度惩罚的 \(k\)/\(q\) 值）均未公开。没有这些细节，难以评估方法的可复现性。

  2. 缺乏消融实验：多 Token 预测、自摘要、各类奖励信号各自的贡献有多大？Router Replay 关闭后性能下降多少？报告未提供系统性的消融分析。

  3. 评测基准的自洽性问题：CursorBench 来自 Cursor 内部工程任务，由 Cursor 团队构建，用于评估 Cursor 的模型。虽然有外部基准交叉验证，但核心指标的中立性存疑。

  4. 计算成本完全缺失：未公布训练总 FLOPs、GPU 时长或美元成本。对于一个 1.04T 参数模型的跨区域分布式训练，这些信息对评估方案实际可行性至关重要。

  5. 与 GPT-5.4 的差距：在 CursorBench 上落后 2.6 个百分点（61.3 vs 63.9），在 SWE-bench 上落后 3.1 个百分点（73.7 vs 76.8），在 Terminal-Bench 上落后 4.8 个百分点（61.7 vs 66.5）。考虑到 Composer 2 是专门针对编程任务训练的领域模型，与通用模型 GPT-5.4 仍有差距，这值得思考。

  6. NVFP4 精度陷阱的偶然发现：快速近似除法在约 100 RL 步后导致发散，这说明低精度训练的稳定性高度依赖实现细节，存在难以预见的工程风险。

六、工程启示

6.1 MoE 基座 + 领域 RL = 性价比最优路径

Composer 2 用 32B 激活参数实现了接近 GPT-5.4 的编程能力。对于垂直领域应用，选择开放权重的 MoE 基座做继续预训练 + RL，可能比直接调用闭源 API 更具成本优势——报告明确指出 Composer 2 在准确率-推理成本 Pareto 前沿上优于通用模型。

6.2 预训练 loss 是 RL 收益的先导指标

在预训练阶段就能预估 RL 阶段的潜力，这意味着团队可以更早地做出 go/no-go 决策。对于资源有限的团队，这一发现可以避免在低潜力基座上浪费 RL 计算量。

6.3 自摘要是长上下文 Agent 的实用方案

相比扩展上下文窗口或外部记忆，让 Agent 自己在多轮交互中生成摘要，既节省 token 又复用 KV cache。这种方案在实际部署中更容易落地。

6.4 低精度训练需要逐算子验证

NVFP4 的 IEEE 精确除法 vs 快速近似的差异，在预训练阶段不可见但在 RL 阶段暴露。启示：混合精度训练的正确性不能仅通过预训练验证，需要在目标训练流程全链路上做回归测试。

6.5 评测基准必须与产品共同演进

CursorBench 从 V1 到 V3 任务规模翻倍，反映了「模型能力提升 → 用户使用场景变复杂 → 基准必须同步升级」的循环。固定基准上的分数提升可能掩盖实际场景中的能力停滞。

6.6 异步 RL 中的一致性是系统性问题

Router Replay + delta 压缩权重同步 + 可信度过滤——这套方案解决的是大规模 MoE 异步 RL 的工程现实：推理集群和训练集群不可能实时保持完全一致，必须设计容差机制。

训练流水线概览 图12：Composer 2 的 MoE 分组 GEMM 训练流程示意。展示了 MXFP8/NVFP4 混合精度在 MoE 层前向和反向传播中的具体应用方式。

七、总结

Composer 2 技术报告的价值不仅在于模型本身的性能数字，更在于它系统性地展示了如何将一个开放基座模型改造为领域顶尖的 Agent 模型的完整方法论。从 Kimi K2.5 的 36.0% 到 Composer 2 的 61.3%，25.3 个百分点的绝对提升背后是预训练策略、RL 算法设计、分布式基础设施和评测体系的协同优化。

但也要清醒地看到：关键超参数和消融实验的缺失使得方案的可复现性存疑；自建自评的基准设计在严谨性上仍有改进空间；与 GPT-5.4 的差距说明领域专用训练还未能全面超越通用前沿模型。

对于 AI 工程团队来说，这份报告最大的参考价值在于：领域专用训练的投入产出比可能远高于等待下一代通用模型——用相对较小的激活参数，达到接近最强通用模型的领域性能，同时成本更低。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注公众号：机器懂语言