Overview

当编码智能体（Coding Agent）从“补全一段代码”走向“在真实仓库里连续几十轮做搜索、修改、执行、回滚和验证”时，问题已经不再只是模型会不会写代码，而是训练分布、工具环境和评测任务是否还和真实开发一致。很多公开基准测试（benchmark）仍以单一缺陷修复或高规格说明任务为主，这类任务对模型能力的刻画已经开始落后于真实工作流。

Composer 2 Technical Report 讨论的正是这个错位。Cursor Research Team 沿着三个方向同时推进：面向编码场景的继续预训练（Continued Pretraining）、面向长时程代码任务的异步强化学习（Asynchronous Reinforcement Learning），以及直接来自真实工程会话的内部评测集 CursorBench。论文最值得关注的地方，是它把“真实工作流对齐”同时放进训练和评测流程，没有停留在最后的公开分数比较上。

CursorBench performance comparison
图1: CursorBench 主结果。Composer 2 在内部真实工程评测上达到 61.3，明显高于前代 Composer 模型，并与最强一档前沿模型接近。图片来自原论文 Figure 1。

Motivation

这篇论文的动机有两层。

第一层是 公开编码评测与真实开发之间的分布错位。论文把这种错位拆成四类：

  • 任务域错位。SWE-bench 一类评测大多集中在缺陷修复，Terminal-Bench 虽然更广，但其中仍有不少任务更接近抽象谜题，和日常工程操作有明显距离。
  • 任务说明过度具体。公开基准测试往往假定存在窄而唯一的标准解；现实里的开发请求通常高度欠规格化（under-specified），允许多种实现路径。
  • 数据污染与过拟合。公开仓库构造的基准测试更容易被训练集覆盖，分数会高估真实泛化能力。
  • 指标范围太窄。开发者实际关心的不只有功能正确性，还包括代码质量、交互效率、成本和工具使用行为。

第二层是 长时程编码智能体的强化学习比短回答场景更难。在真实代码任务里，一条轨迹（rollout）可能包含很多轮工具调用、代码修改和环境状态变化；同一个策略更新还会跨越多个异步服务、多个推理节点和一个混合专家（Mixture-of-Experts，MoE）模型的路由过程。此时如果仍把训练看成普通聊天模型上的短输出强化学习，长度偏置、离策略误差和行为退化都会被迅速放大。

Methodology

Training Pipeline

Composer 2 的训练分成两段。

第一段是继续预训练。论文从 Kimi K2.5 出发，追加一个以代码为主的数据混合，并把训练拆成三个阶段：先在 32k 上下文长度做主体训练，再扩展到 256k 长上下文，最后用面向编码任务的小规模监督微调（Supervised Fine-Tuning，SFT）做收尾。论文报告的一个关键经验是：内部代码库上的困惑度（Perplexity）下降，能够预测后续强化学习阶段的收益。这说明继续预训练承担的是策略初始化工作，它为后续智能体强化学习提供了更好的起点。

为了加速线上推理，模型还训练了多词元预测（Multi-Token Prediction，MTP）层，并使用自蒸馏（Self-Distillation）去拟合主语言模型头的未归一化分数（logits）。这个设计本身不是论文核心，但它解释了 Composer 2 为什么在保持较强能力时，仍然能把服务成本压在可交互产品能接受的区间。

Coding Agent as a Long-Horizon Policy

论文把编码智能体形式化成一个在代码环境中连续行动的策略。给定任务提示 $x$、已有动作历史和环境反馈，模型在第 $t$ 步采样动作 $a_t$：

$$ a_t \sim \pi_\theta \left(a_t \mid x, a_1, y_1, \ldots, a_{t-1}, y_{t-1}\right) $$

这里的 $y_t$ 不是普通对话回复，而可以是命令行（shell）执行结果、文件读取内容、搜索命中项或测试输出。整条轨迹的最终奖励由代码正确性、简洁性以及工程规范共同决定。和竞赛编程不同，这类任务要求模型自己搜索仓库、选择改动范围、必要时写测试，并在不完整需求下形成可执行方案。

Stabilizing Asynchronous RL

论文在策略梯度实现上做了几处很关键的取舍。

第一，作者刻意去掉了会引入长度偏置的归一化做法。论文借鉴已有工作，不使用GRPO中的长度标准化项，也不按组内标准差去归一化优势值（advantage）。原因很直接：如果一组轨迹的正确性都接近，但行为差异很小，标准差归一化会把这种微小差异过度放大，训练目标就会被噪声主导。

第二，论文没有对超长轨迹做硬截断（hard masking）。很多长任务本来就需要持续探索，如果超过最大长度后直接把样本掐掉，模型会被系统性地推向短轨迹，也更难在长轨迹中学到一致性。Composer 2 选择保留这些样本，再配合自摘要机制和长度惩罚去控制成本。

第三，论文在 KL 散度正则化的估计器上做了更保守的选择。若定义

$$ r(x)=\frac{p(x)}{q(x)} $$

很多开源强化学习实现会用

$$ k_3=(r-1)-\log r $$

来估计 KL 散度，但论文指出它在 $p$ 和 $q$ 偏离较大时方差会迅速变差，因此改用

$$ k_1=-\log r $$

这个更稳定的估计方式。这里更关键的是方差控制：系统本身已经高度异步，轨迹又长，MoE 路由还会引入额外数值差异，训练过程首先需要稳定。

第四，论文把“尽量接近同策略分布（on-policy）”当成基础设施目标，而不仅仅是优化器目标。它通过快速权重同步、轨迹中途热更新权重、以及 MoE 的路由回放（router replay）来减少采样分布和训练分布之间的偏差。特别是路由回放很关键，因为如果推理端和训练端对同一个词元（token）选中了不同专家，那么训练时回放出来的对数概率（log-prob）就和采样时不是同一个分布。

Self-Summarization and Credit Assignment

长时程编码任务的另一个难点是上下文压缩。Composer 2 沿用了前代模型里的自摘要（Self-Summarization）机制：一条轨迹并不总是单次长回答，而可以由多段生成和多次摘要串接而成。论文把最终奖励回传给整条链上的所有词元，因此一个好的摘要不仅能压缩上下文，还会因为帮助后续轨迹成功而被正向强化；相反，丢失关键信息的摘要会被系统性降权。

这个设计把“摘要质量”直接接到最终任务成功率上。对于编码智能体，这种做法也更自然，因为后续决策真正依赖的是状态保留是否充分，不是摘要文本本身是否可读。

Nonlinear Length Penalty

论文还引入了一个用于行为塑形的非线性长度惩罚。记输入代价 $x$ 为若干项的加权和，包括思考词元、工具调用词元、工具输出词元、最终回复词元、工具调用次数和轮数；论文定义惩罚函数为：

$$ C_{\mathrm{length}}^{k,q}(x)=\frac{(1+kx)^{1-q}-1}{k(1-q)} $$

其中 $k,q$ 是控制曲率的超参数。这个式子的性质可以直接算出来：

$$ \frac{d}{dx}C_{\mathrm{length}}^{k,q}(x)=(1+kx)^{-q} $$
$$ \frac{d^2}{dx^2}C_{\mathrm{length}}^{k,q}(x)=-kq(1+kx)^{-q-1} $$

当 $k>0,q>0$ 时，一阶导数恒为正，二阶导数恒为负，所以它是一个单调递增但边际惩罚递减的函数。含义非常明确：

  • 简单任务里，前几次额外工具调用带来的惩罚很敏感，模型会倾向于更快收敛。
  • 困难任务里，随着轨迹变长，继续探索的边际惩罚会下降，模型不会因为“怕长”而过早停止。

这也是论文强调的重点：长度惩罚并非单纯压缩输出，而是在不同任务难度下重新分配“快”和“深思”的权重。

Experiments

Why CursorBench Matters

论文最有信息量的实验部分，首先是对 CursorBench 的说明。作者先解释了它为什么比现有公开基准测试更接近真实开发。

CursorBench 来自真实工程团队的实际智能体会话，不是从公开仓库里回收出来的静态缺陷样本。论文给出两组很关键的统计：

  • 需要改动的代码行数中位数为 181，而 SWE-bench Verified 和 SWE-bench Multilingual 只有 7 到 10 行量级。
  • 问题描述长度中位数只有 390 个字符，公开基准测试则大约在 1,185 到 3,055 个字符之间。

这两个数字合在一起很有代表性：真实任务往往改动更大，但提示更短、更含糊。模型因此必须在大仓库里主动补上下文，不能等题目把边界条件全部写好。论文举的一个例子甚至要求模型从简短错误报告和 Datadog 日志里，定位一个 esbuild 降级编译造成的 var 作用域错误；这类任务和公开基准测试相比，差别已经上升到任务形态层面。

Main Results

在 CursorBench-3 上，Composer 2 的准确率是 61.3，前代 Composer 1.5 和 Composer 1 分别是 44.2 与 38.0；底座模型 Kimi K2.5 是 36.0。公开基准测试上，Composer 2 在 SWE-bench Multilingual 达到 73.7，在 Terminal-Bench 达到 61.7。按论文表格，CursorBench 上它高于 Opus 4.6 High 的 58.2 和 GPT-5.3 Codex 的 59.1，低于 GPT-5.4 的 63.9，整体处在最强一档模型附近。

Performance versus token and cost
图2: CursorBench 上的性能与词元 / 成本关系。Composer 2 的准确率接近第一梯队，同时保持较低推理成本。图片来自原论文 Figure 11。

图2更能说明这篇论文真正要表达的点。只看词元数量，Composer 2 已经接近前沿模型；进一步换算成每任务推理成本后，它的性价比优势更明显。论文的结论是：领域特化训练并不只是把分数拉高，也能把单位交互成本压到产品化可接受的水平。

What the Results Actually Support

从证据链看，这篇论文至少支持三件事。

第一，继续预训练和下游智能体强化学习之间存在稳定的正相关。论文在较小模型上观察到，代码领域困惑度越低，后续强化学习奖励越高。

第二，强化学习训练提升的不只是平均表现，也提升了多次采样取最优（best-of-K）表现。论文专门强调这一点，是因为近来很多工作认为大模型强化学习更多是在重新分配已有成功轨迹的概率质量，未必真的扩大了可达解空间。Composer 2 的结果表明，在真实编码任务和相应基础设施条件下，这个悲观判断至少不是普适结论。

第三，真实工作流对齐是有效的。CursorBench 的任务构成、环境、工具和产品运行框架（harness）与训练过程保持一致，因此论文中的收益更接近“部署域收益”，不只是公开榜单上的离线收益。

Limitations

这篇技术报告也有明显边界。

  • 论文没有公开 CursorBench 的完整数据与评测细则，外部很难完全复现实验。
  • 奖励设计只给出关键思路，没有公开全部权重和工程细节，因此行为塑形部分更像方向性证据，距离可直接复制的工程配方还有一段距离。
  • 训练与推理基础设施高度依赖内部平台，包括环境快照、异步调度、路由回放和跨区域推理集群，这些条件并不是一般团队可直接拥有的。

因此，这篇论文更像是在说明“真实软件工程智能体应该怎样被训练和评测”，并没有提供一套低门槛复现实验手册。

References

[1] Cursor Research Team. “Composer 2 Technical Report” arXiv preprint arXiv:2603.24477 (2026).

[2] OpenAI. “Why SWE-bench Verified No Longer Measures Frontier Coding Capabilities” OpenAI, 2026.