在生产级代码仓库里，一个 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 Pretraining（CPT）被拆成三步走，而不是一次粗暴的 next-token 轰炸：

1. Bulk Training（32k 序列长度）：用海量代码主导的数据混合进行标准预测，快速建立广度知识。
2. Long-Context Extension（256k 序列长度）：把上下文窗口拉到 256k，让模型能一次性“看”完整个大型 monorepo 或超长文档。
3. SFT 收尾：短暂的有监督微调，进一步对齐具体编码任务。

在这个阶段，Cursor 还引入了 Multi-Token Prediction（MTP）。模型不再只预测下一个 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 Optimization（GRPO）的变体，单 epoch 制度、不标准化 group advantage、去掉长度标准化，完全靠非线性惩罚来平衡长度偏差。

整个系统拆成训练、环境、推理、评估四个独立服务异步运行，最大化吞吐——这已经是当前前沿 RL 训练的标配做法。

CursorBench 为什么能持续领先：真实工程任务而非 GitHub Issue 堆砌

公开基准容易被刷饱和，CursorBench 直接来自 Cursor 团队和用户的真实问题：1000 个任务，覆盖数十个大型真实仓库。任务往往模糊——“新特性有 bug，日志里只有 JSON 响应”，需要跨引用源码和生产日志、写启发式检测器、调参。基准本身也在迭代（v0→v1→v2→v3），永远跑在模型和开发者工作流的前面。

从具体管道升维到行业趋势

Composer 2 的报告其实在告诉我们：Agentic 编码模型的下一战，已经从“模型参数”转向“训练闭环的工程精度”。谁能把 RL 环境、安全隔离、奖励塑形、基准迭代这些环节做得更极致，谁就能在未来软件工程的 Agent 浪潮里占住位置。对开发者而言，这意味着我们不能只停留在 prompt engineering，而是需要理解 RL 训练的系统设计，才能真正驾驭下一代工具。

如果你正在构建自己的内部 Agent，或者正在评估是否要把 Cursor Composer 2 类方案引入团队工作流，我抛出一个值得深入讨论的问题：在资源有限的情况下，你会把更多预算投到 CPT 的知识深耕，还是 RL 环境的工程打磨？欢迎在评论区分享你的实际权衡，我们一起把这些前沿实践落地到生产里。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。