Cursor Composer 2 技术报告拆解：MoE 预训练、RL 环境设计与 CursorBench 基准的工程实践

在生产级代码仓库里一个 AI Agent 面对的往往不是“实现某个功能”这样清晰的任务而是“新特性上线后出现诡异 bug日志里只有 954 个 JSON 响应栈踪迹完全不可靠”。它必须自己跨文件定位、写启发式检测器、调参避免误报最后还要保证不破坏现有构建流程。Cursor Composer 2 正是为解决这类真实卡点而生的 frontier-level 编码 Agent它的训练路径远超简单 scaling技术报告里把整个管道拆得清清楚楚。我起初以为 Agentic 编码模型的核心就是把预训练数据塞满代码和文档就够了——知识多了能力自然就上来了。后来深入报告才发现真正的分水岭在于“知识深耕”和“执行能力”两个阶段的精密配合前者让模型成为编码领域的专家后者则让它学会在真实环境中长期稳定地“干活”。这背后的底层逻辑其实很简单——知识是燃料RL 才是发动机。CPT 阶段的三层递进Kimi K2.5 如何从通用 MoE 转型编码专家Cursor 选择 Kimi K2.5 作为基座并非随意。它是一个 1.04 万亿参数的 Mixture-of-Experts 模型每次前向传播只有 32B 参数激活既保有海量知识容量又保持推理时的计算效率。想象一下这就像一个拥有全套厨具的超级厨房却只在需要时打开特定灶台不会把整个厨房的电都烧掉。Continued PretrainingCPT被拆成三步走而不是一次粗暴的 next-token 轰炸Bulk Training32k 序列长度用海量代码主导的数据混合进行标准预测快速建立广度知识。Long-Context Extension256k 序列长度把上下文窗口拉到 256k让模型能一次性“看”完整个大型 monorepo 或超长文档。SFT 收尾短暂的有监督微调进一步对齐具体编码任务。在这个阶段Cursor 还引入了Multi-Token PredictionMTP。模型不再只预测下一个 token而是同时预测后面好几个 token 的 logit 分布通过 self-distillation 从头训练 MTP 层。实际效果就像棋手提前看三步棋——推理时可以用 speculative decoding 一次性“猜”出一小段可预测序列再由主模型验证大幅提升生产环境下的生成速度。这不是锦上添花而是实打实的推理效率优化。RL 阶段的真实战场Anyrun Firecracker 如何让 Agent 安全“动手”CPT 解决的是“懂”RL 解决的是“会干”。这里 Cursor 展现了极高的工程细节。环境不是普通 sandbox而是基于 Rust 的 Anyrun 平台底层用 AWS Firecracker 轻量级虚拟化技术。每一次 agent rollout 都在独立的 Firecracker VM 里运行支持完整开发栈、浏览器、GUI甚至能 fork 和 snapshot 文件系统 内存状态。这意味着什么Agent 走错一步可以瞬间回滚到上一个 checkpoint 重新尝试就像 Git 的分支实验却能精确到内存级别。网络出口则由 Anygress 代理敏感 header 自动丢弃避免 Agent 意外对外造成影响。整个设计把“不可信代码执行”和“生产级开发环境”这两个看似矛盾的需求强行捏在了一起。奖励塑形的精妙权衡非线性长度惩罚与辅助信号Reward 设计是 RL 的灵魂。最终奖励来自任务整体成功通过测试、达到目标状态经典的 RLVR 思路。但 Cursor 加了两把“手术刀”非线性长度惩罚曲线是凹向下的。简单任务里多一个 token 就重罚复杂任务里则允许模型多思考而不被过度惩罚——就像短跑要极致速度长跑要战略配速。辅助奖励代码可读性、清晰的思考过程、工具使用习惯不允许只写 TODO 却从不完成。这些信号共同把模型往“既快又稳、既能干又会说”的方向拉。Cursor Harness 与异步 RL训练环境和 IDE 完全对齐最狠的是他们把 RL 训练的 harness 和 Cursor IDE 的真实工具调用链 100% 对齐。工具库通过 RPC 调用重资源工具语义搜索等放在 VM 外动态提供还支持 live code updates——训练中途就能上线新工具无需重启整个 job。训练采用 Group Relative Policy OptimizationGRPO的变体单 epoch 制度、不标准化 group advantage、去掉长度标准化完全靠非线性惩罚来平衡长度偏差。整个系统拆成训练、环境、推理、评估四个独立服务异步运行最大化吞吐——这已经是当前前沿 RL 训练的标配做法。Kimi K2.5 MoE 基座CPT 阶段Bulk 32k → 256k Long-Context → SFTMTP 层自蒸馏支持 speculative decodingRL 阶段Anyrun Firecracker 隔离环境GRPO 变体 非线性长度惩罚 辅助奖励 自总结Cursor IDE 完全对齐的 Harness生产级 Agentic 能力CursorBench 为什么能持续领先真实工程任务而非 GitHub Issue 堆砌公开基准容易被刷饱和CursorBench 直接来自 Cursor 团队和用户的真实问题1000 个任务覆盖数十个大型真实仓库。任务往往模糊——“新特性有 bug日志里只有 JSON 响应”需要跨引用源码和生产日志、写启发式检测器、调参。基准本身也在迭代v0→v1→v2→v3永远跑在模型和开发者工作流的前面。维度传统公开基准如 SWE-benchCursorBench核心差异任务来源GitHub Issue/PR真实生产问题 用户场景模糊性与工程复杂度更高上下文单一 PR 级别跨文件、大型 monorepo要求 256k 长上下文评估方式固定测试用例最终状态 可验证结果更贴近实际交付迭代速度静态持续演进v0/v1/v2/v3避免饱和从具体管道升维到行业趋势Composer 2 的报告其实在告诉我们Agentic 编码模型的下一战已经从“模型参数”转向“训练闭环的工程精度”。谁能把 RL 环境、安全隔离、奖励塑形、基准迭代这些环节做得更极致谁就能在未来软件工程的 Agent 浪潮里占住位置。对开发者而言这意味着我们不能只停留在 prompt engineering而是需要理解 RL 训练的系统设计才能真正驾驭下一代工具。如果你正在构建自己的内部 Agent或者正在评估是否要把 Cursor Composer 2 类方案引入团队工作流我抛出一个值得深入讨论的问题在资源有限的情况下你会把更多预算投到 CPT 的知识深耕还是 RL 环境的工程打磨欢迎在评论区分享你的实际权衡我们一起把这些前沿实践落地到生产里。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。