Composer 2 技术报告：面向智能体软件工程的专用编码模型 Composer 2 Technical Report
Cursor发布专用编码智能体模型Composer 2，经继续预训练+强化学习训练
前置知识
Mixture-of-Experts (MoE) 模型
MoE是一种稀疏激活的神经网络架构，模型由多个专家子网络组成，每次前向传播时只激活其中一部分专家。具体来说，一个路由网络（router）根据输入token决定将该token发送给哪些专家处理。Kimi K2.5采用1.04T总参数但仅32B活跃参数的MoE架构，这意味着虽然模型容量巨大，但每个token的实际计算量远小于密集模型，从而在保持强大能力的同时降低推理成本。
Composer 2以Kimi K2.5为基座模型，理解MoE架构对于理解模型的训练策略（如专家并行、路由重放）和推理效率至关重要
强化学习（RL）用于语言模型训练
RL用于语言模型是一种通过与环境交互获取奖励信号来优化模型策略的方法。在编码智能体场景中，模型在代码环境中执行一系列工具调用（actions），最终根据代码的正确性、简洁性等获得奖励。Composer 2使用策略梯度算法（policy gradient），对每个问题采样多个rollout，根据解的质量更新模型参数。与传统RL不同，这里的状态空间是代码库环境，动作空间是工具调用序列。
Composer 2的核心创新之一是大规模异步RL训练，理解RL在LLM中的应用是理解论文技术路线的关键
继续预训练（Continued Pretraining）
继续预训练是在已有的预训练模型基础上，使用特定领域的数据进一步训练，以增强模型在该领域的知识和能力。Composer 2在Kimi K2.5基础上使用大规模代码主导的数据混合进行继续预训练，分为三个阶段：32k序列长度的主体训练、256k序列长度的长上下文扩展、以及针对编码任务的SFT阶段。这种分阶段方法使模型在保持通用能力的同时大幅提升编码专业知识。
继续预训练是Composer 2训练流程的第一阶段，论文证明了它对下游RL性能的直接促进作用
GRPO (Group Relative Policy Optimization)
GRPO是一种策略梯度算法变体，通过在同一个问题上采样一组rollout来计算相对优势。与标准PPO不同，GRPO不需要单独的价值函数网络，而是利用组内rollout的相对排名来估计优势。Composer 2在此基础上做了关键改进：移除了GRPO中的长度标准化项以避免长度偏差，不使用标准差归一化组内优势以避免退化情况，以及采用标准的KL估计器 $k_1 = -\log r$ 替代常用的 $k_3$ 估计器以避免方差爆炸。
Composer 2的RL训练算法基于GRPO的改进版本，理解这些改进对于理解训练稳定性和效果至关重要
自摘要（Self-Summarization）
自摘要是一种允许模型在长对话中自主压缩上下文的技术。在Composer 2的训练中，每个训练rollout可以包含多个生成阶段，阶段之间通过模型自己生成的摘要连接，而非单一的prompt-response对。模型学习在上下文窗口有限时，通过多次自摘要来处理更多信息。与基于外部prompt的压缩方法相比，自摘要一致地减少了错误，同时使用更少的token并复用KV缓存。
自摘要使Composer 2能够处理长视野的真实世界软件工程任务，这是论文的核心能力之一
CursorBench
CursorBench是论文提出的一个内部评估套件，任务来源于Cursor工程团队的真实编码会话。与公开基准相比，CursorBench任务需要更大规模的代码修改（中位数181行 vs SWE-bench的7-10行），且任务描述更加模糊（中位数390字符 vs 公开基准的1185-3055字符）。评估不仅关注功能正确性，还衡量代码质量、执行效率和交互行为。基准随时间迭代更新，CursorBench-3的任务规模是初始版本的两倍以上。
CursorBench是论文评估的核心基准，理解其设计理念对于理解论文声称的贡献至关重要
异步RL训练与推理基础设施
Composer 2的RL训练采用高度异步的架构，训练、环境、推理和评估是四个解耦的服务。推理由Fireworks AI运行，使用S3进行权重同步，采用delta压缩减少传输量。环境基于Anyrun平台（基于Firecracker VM），支持每秒调度500多个pod。训练使用Ray和PyTorch构建，支持从进程级故障中恢复。这种分布式架构使训练能够跨3个GPU计算区域和4个CPU计算区域进行。
理解基础设施设计对于理解Composer 2如何实现大规模RL训练以及工程挑战至关重要
研究动机
现有编码智能体模型在真实世界软件工程任务中的表现与公开基准分数之间的相关性很弱。论文指出四个主要原因：首先是领域不匹配，静态基准无法覆盖开发者工作流的完整范围——SWE-bench主要聚焦于孤立的bug修复，Terminal-Bench虽然覆盖更广泛的任务类型，但很多任务（如计算国际象棋走法）是抽象谜题而非典型软件工程操作。其次是提示词过度规范化，公开基准通常高度指定，假设存在狭窄的正确解决方案集合，而真实开发者请求往往是模糊的，允许多种有效的架构方案。第三是数据污染和过拟合，公开基准基于历史爬取的开源仓库构建，经常泄漏到模型训练数据中，人为抬高分数——OpenAI最近就因发现前沿模型能从记忆中生成金标准补丁而暂停了SWE-bench Verified结果的报告。第四是评估范围狭窄，现有编码评估主要衡量功能正确性，而实践中开发者还高度重视代码质量、可读性、延迟、成本和交互行为质量。
本文的目标是本文的具体目标是训练一个专门用于智能体软件工程的模型Composer 2，该模型能够在真实世界编码任务中达到前沿水平的表现，同时保持较低的推理成本。论文希望通过两个训练阶段——继续预训练和大规模强化学习——来系统性地提升模型的编码智能、长期规划能力和多步执行准确性。同时，论文旨在建立一套真实世界的评估体系CursorBench来准确衡量模型在实际软件工程中的能力，而非仅仅在可能被污染的公开基准上竞争。
与已有工作不同的是，本文的独特切入角度在于完全专注于编码领域的专用模型训练，而非追求通用能力。核心洞察是通过确保训练与目标领域的紧密匹配来实现缩放——具体体现在三个层面：使用与生产环境完全相同的Cursor工具和结构进行训练（包括相同的代码库环境、工具调用格式和后端实现）；构建反映真实用户挑战的问题分布（包括功能迭代、调试、重构、代码审查、文档等多种任务类型，而非仅限于bug修复）；以及开发针对编码智能体行为的专用奖励机制（如非线性长度惩罚、工具调用质量奖励等）。这种领域专用化策略使Composer 2在推理成本远低于通用前沿模型的情况下，实现了可比的准确率。
核心方法
Composer 2的训练方法论可以概括为一个两阶段的专用化流程：先通过继续预训练增强模型的编码知识和潜在编码能力，再通过大规模强化学习直接优化端到端编码性能。继续预训练阶段类似于给模型补课，让它在代码领域的知识更加扎实；RL阶段则是实战演练，让模型在真实的编码环境中学习如何解决问题。整个流程的核心设计理念是最小化训练-测试不匹配：训练环境与生产环境完全一致（使用相同的Cursor harness、工具集和后端实现），训练问题来自真实用户会话的分布，奖励信号同时考虑代码正确性和交互体验。论文还引入了CursorBench作为真实世界评估基准，任务来自实际编码会话，中位代码修改量181行（远超SWE-bench的7-10行），任务描述中位长度仅390字符（远低于公开基准的1185-3055字符）。
Composer 2的核心创新在于将领域匹配原则贯穿整个训练流程，这与已有方法形成鲜明对比。首先，在数据层面，不同于在通用语料上训练编码模型，Composer 2使用大规模代码主导的数据混合进行继续预训练，并证明交叉熵损失能直接预测下游RL性能。其次，在RL算法层面，论文对GRPO做了三项关键改进：移除长度标准化项避免长度偏差、不使用标准差归一化避免退化情况、采用标准KL估计器 $k_1 = -\log r$ 替代 $k_3$ 以避免方差爆炸——这些改进在以往文献中未被系统性地整合。第三，在基础设施层面，Composer 2实现了完全异步的RL训练，训练和推理使用相同的环境和工具（通过Anyrun平台），推理引擎支持在rollout中途更新权重以减少off-policy偏差。第四，在行为优化层面，论文设计了非线性长度惩罚 $$C_{\text{length}}^{k,q}(x) = \frac{(1+kx)^{1-q}-1}{k(1-q)}$$ 使模型在简单任务上快速响应而在困难任务上深度思考。
方法步骤详情
Composer 2的训练分为以下步骤：（1）基座模型选择：通过内部评估（代码库困惑度、编码知识、状态追踪）选定Kimi K2.5（1.04T参数/32B活跃参数的MoE模型）作为基座。（2）继续预训练第一阶段：在32k token序列长度上使用代码主导数据混合进行主体训练，使用AdamW优化器，在NVIDIA B300 GPU上以MXFP8精度训练，同时训练多token预测（MTP）层用于投机解码。（3）继续预训练第二阶段：长上下文扩展至256k序列长度。（4）继续预训练第三阶段：针对编码任务的SFT阶段，MTP层与模型联合训练。（5）RL训练：使用改进的GRPO算法，在Anyrun环境（Firecracker VM）中运行编码任务，任务分布涵盖功能迭代、调试、重构、文档、代码审查、DevOps、优化、迁移、删除等多种类型。每个训练步骤采样问题、模拟一组不同解的rollout、根据解的质量更新模型权重。（6）后期RL阶段使用启发式方法（如rollout的轮数和思考token数）对更难的数据点进行上采样。（7）在整个训练过程中运行在线评估，使用生产后端和Cursor客户端的固定版本。
技术新颖性
Composer 2在技术新颖性上有多方面贡献。在量化技术上，论文提出了一种新颖的NVFP4变体用于MoE前向传播：值从BF16量化为FP4E2M1，使用FP8E4M3的per-block scales（块大小16）和FP32的per-token scales。原始NVFP4格式使用FP32 per-tensor scales有两个致命缺陷：使训练对batch大小敏感导致RL训练发散，以及token间scale值会泄漏未来token信息到过去token导致有偏梯度。反向传播则使用标准MXFP8格式，利用了RL训练的不对称性——前向传播需要与推理引擎匹配以保证数值稳定性，而反向传播仅在训练集群运行可以承受更高精度。在并行策略上，论文用上下文并行（CP）替代张量并行（TP）作为主要的长上下文缩放轴，CP通信量更少且能保持全隐藏维度。针对MLA架构的CP实现有三个优化：局部计算KV latent向量后all-gather再投影、使用Liu et al.的技术平衡因果注意力负载、将CP维度折叠到FSDP维度以减少内存。在KL估计上，论文系统性地比较了三种估计器，发现 $k_3$ 在 $p$ 和 $q$ 发散时方差会急剧增大，因此选择标准估计器 $k_1 = -\log r$。
实验结果
Composer 2在多个评估基准上展示了显著的性能提升和前沿竞争力。在内部CursorBench基准上，Composer 2达到61.3%的准确率，相比Composer 1.5的44.2%实现了37%的相对提升，相比Composer 1的38.0%实现了61%的提升。在公开基准SWE-bench Multilingual上，Composer 2得分73.7%，比Composer 1.5的65.9%提升7.8%，比Composer 1的56.9%提升16.8%。在Terminal-Bench上，Composer 2得分61.7%，比Composer 1.5的47.9%提升13.8%，比Composer 1的40.0%提升21.7%。与其基座模型Kimi K2.5（CursorBench 36.0%，SWE-bench 65.1%，Terminal-Bench 47.3%）相比，Composer 2展示了巨大的准确率提升，验证了继续预训练和RL管道的有效性。值得注意的是，论文发现RL训练同时提升了平均性能和best-of-K性能（图5），这与近期文献中观察到的RL仅重新分配概率质量的观点形成对比，表明Composer 2的RL训练不仅改善了模型选择高置信度解决方案的能力，还扩展了在重复采样下可达正确解的覆盖面。在成本效率方面，Composer 2实现了帕累托最优的权衡：其推理成本与较小或低努力变体的模型相当，而准确率与更大的前沿模型可比。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| CursorBench（内部真实世界编码基准） | 准确率（%） | 61.3 | Composer 1.5: 44.2, Composer 1: 38.0, Kimi K2.5: 36.0, GPT-5.4: 63.9, Opus 4.6 High: 58.2 | 比Composer 1.5提升37%，比基座Kimi K2.5提升70%，接近GPT-5.4水平 |
| SWE-bench Multilingual（多语言软件工程基准） | 准确率（%） | 73.7 | Composer 1.5: 65.9, Composer 1: 56.9, Kimi K2.5: 65.1, GPT-5.4: 76.8, Opus 4.6 High: 75.8 | 比Composer 1.5提升7.8%，比基座Kimi K2.5提升8.6% |
| Terminal-Bench（终端操作基准） | 准确率（%） | 61.7 | Composer 1.5: 47.9, Composer 1: 40.0, Kimi K2.5: 47.3, GPT-5.4: 66.5, Opus 4.6 High: 58.0 | 比Composer 1.5提升13.8%，比基座Kimi K2.5提升14.4% |
局限与改进
论文存在几方面的局限性。首先，尽管Composer 2在CursorBench上表现出色，但与GPT-5.4（63.9%）仍有差距，表明专用化训练仍有提升空间。其次，论文承认模型在某些情况下展现出可以明确改进的智能或连贯性行为，暗示当前的RL训练尚未完全挖掘模型的潜力。第三，CursorBench作为内部基准，其评估结果难以被外部独立验证，虽然论文同时报告了公开基准结果，但公开基准本身存在论文所批评的数据污染问题。第四，论文未提供模型的完整训练成本和时间细节，使得复现和比较困难。第五，Composer 2的基座模型Kimi K2.5本身就是一个强大的模型（1.04T参数），论文的方法对较弱基座模型的效果尚不明确。此外，论文提到的推理成本优势主要基于API定价比较，而非实际计算效率比较，因为无法获取其他API模型的FLOPs数据。
独立分析的弱点
尽管Composer 2取得了显著成果，仍存在几个值得分析的弱点。第一，论文虽然强调了领域匹配的重要性，但对继续预训练阶段的具体数据配比和筛选策略描述不够详细，使得读者难以理解哪些类型的数据对性能提升贡献最大。改进方向：可以系统性地消融不同数据配比的影响。第二，RL训练中的辅助奖励（如编码风格、通信质量、工具调用质量）的具体设计和权重未充分公开，这些对最终模型行为有重要影响。改进方向：更详细地报告辅助奖励的消融实验。第三，非线性长度惩罚公式中的超参数 $k$ 和 $q$ 的选择依据未充分讨论，不同任务类型可能需要不同的惩罚曲线。改进方向：可以探索自适应的长度惩罚策略。第四，论文承认未使用overlong masking策略，但没有充分讨论这对长序列训练稳定性的影响。改进方向：系统比较不同截断策略的效果。第五，虽然论文提到使用启发式方法上采样更难的数据点，但具体实现细节不足，可能导致训练后期的样本效率问题。
未来方向
论文和基于成果可延伸的未来研究方向包括以下几个方面。首先，论文明确指出编码智能体的范围正在从交互式问题扩展到需要数小时人类工作的智能体任务，Composer团队的下一步聚焦于通过训练方法扩展模型处理更长问题的能力——既包括算法层面有效利用长期训练信号，也包括基础设施层面支持忠实的长视野问题。其次，论文认为模型在架构和算法上仍有相当大的发展空间，Composer 2虽然庞大（1.04T参数/32B活跃参数）但可能小于具有可比能力的其他专有模型，暗示可以通过架构创新进一步提升效率。第三，可以将Composer 2的领域专用化方法论（继续预训练+异步RL+环境匹配训练）推广到其他垂直领域如数据分析、系统运维、科学计算等。第四，论文展示的RL训练同时提升平均和best-of-K性能的发现值得深入研究其背后的机制。第五，可以探索更高效的推理架构，如结合MTP层的投机解码与更激进的量化策略。
复现评估
Composer 2的复现评估呈现两极分化的态势。在开源方面，论文提到积极开源了内核实现（BF16、MXFP8、NVFP4 GEMM实现已开源到ThunderKittens），并与Colfax合作实现了Flash Attention 4反向传播内核并合并到公开仓库。然而，模型本身、训练数据、训练脚本均未开源，这使得完全复现几乎不可能。在数据方面，CursorBench来自内部真实会话且不公开，训练数据的具体配比也未详细披露。在算力方面，训练在NVIDIA B300 GPU上进行，跨越3个GPU计算区域和4个CPU计算区域，这种规模的计算资源对绝大多数研究机构来说不可获得。在难度方面，异步RL训练的基础设施极其复杂，涉及Anyrun平台、Firecracker VM、多区域分布式训练等，即使有代码也难以复现。总体而言，论文的方法论和洞察可以被借鉴，但完整复现需要巨大的工程和算力投入。
论文图表
子图(a)展示了不同基准中参考diff的行数变化：CursorBench中位数181行，SWE-bench Verified和Multilingual仅7-10行。子图(b)展示了问题描述长度：CursorBench中位数390字符，SWE-bench Verified为1185字符，Terminal-Bench为3055字符。
这张图量化了CursorBench与公开基准之间的结构性差异，支持了论文关于公开基准不能代表真实软件工程复杂性的论点。
展示了一个典型的CursorBench任务：一个简短的bug报告配有一段TypeScript代码片段和DataDog日志链接。agent需要交叉引用源代码和生产监控日志来诊断失败，日志中还包含无关的生产服务警告作为干扰信息。
这个示例具体展示了CursorBench任务的真实性和复杂性——需要从模糊的bug报告和杂乱的日志中诊断esbuild降级bug，体现了真实软件工程的挑战。