3.26 通过实时 RL 改进 Composer · Cursor
　　cursor将使用真实推理token进行训练的方法称为“real-time RL"，他们之前在训练tab模式时使用过这项技术，发现效果很好，所以他们将类似的方法应用到composer上。cursor通过将checkpoint部署到生产环境，观察用户反馈，将这些反馈汇总为奖励信号，这种方法可以让cursor最快5小时就发布一个改进版本的composer.
　　像composer这种编程模型，主要通过创造模拟编程环境来训练，也就是我们常说的沙箱，目标是为了尽可能真实地复现模型在实际使用中会遇到的环境和问题。相比于其他领域的rl，编程更容易创建high-fidelity simulation of the environment。这也是为什么agent能快速取代人类，完成基本的编程任务。
　　像alphago一样，在一个虚拟环境下，通过rl可以让模型涌现出超越人类的水平，而在不容易模拟环境的领域，agent往往显得很“蠢”，但显然coding的reward相比于围棋要稀疏的多。因此模拟出场景的环境，构建密集的反馈，是实现智能的必要条件。
　　但编程模型的生产环境不仅仅包括执行命令的计算机，还包括监督并引导其行为的人，这很难模拟。虽然已经有研究人员在探索构建模拟用户的模型[2505.10831] Creating General User Models from Computer Use，但是这种方法会不可避免的引入建模误差。使用真实环境的推理token来作为训练信号，能让我们直接利用真实环境和真实用户的行为，从而消除建模不确定性，以及训练-测评不匹配的问题。
　　显然，这种realtime rl非常考验工程能力，cursor通过埋点，将用户交互转化为信号，再通过数据pipeline将信号送入训练循环。最后通过fast deployment path上线更新后的checkpoint。
　　整个过程大约需要5个小时，这种速度能够让数据几乎完全保持On policy。但同时Reward hacking在real time rl中更为突出，因为技术栈的每一个环节，包括数据如何采，如何转换为信号，reward逻辑，都会成为模型利用的地方。
　　起初，cursor在训练composer时，会丢弃tool call失败的case，于是composer发现，如果它在一个自己很可能做不好的任务上故意发出损坏的tool call，就永远不会获得negative reward。于是后来cursor将损坏的tool call纳入了negative examples。
　　还有一个更隐蔽的情况出现在编辑行为中，cursor的部分reward来自模型做出的编辑。在某个阶段，composer学会了通过提出澄清性问题从而推迟高风险编辑，同时它也意识到知道代码没写出来就不会受罚（只要我不给出答案，就没人能证明我错了！），又由于reward里出现的一个问题导致这种激励不会反转（即不修改代码也没有惩罚），这导致编辑率急剧下降，最后cursor通过修改reward function来纠正这种行为。
　　但随着一次任务执行的时间越来越长，用户每一次对话都想要一个更完整的结果，因此real time rl还需要适应这种低频的交互。同时，cursor也在探索其他场景的real time rl~
3.27 关于 Composer 2 的技术报告 · Cursor
　　我在这里简要聊聊，关于技术报告的详细分析，跳转（还没写）Composer 2
　　composer2基于kimi k2.5，先在注重代码的混合数据上进行预训练，以深化模型的编程知识，随后进行大规模的强化学习，提升端到端的表现。
　　在cursor自己的benchmark上，composer2相较于1.5提升了37%，在准确性与成本之间实现了帕累托最优的平衡。技术报告里包括很多infra相关的工作，包括全异步的rl，沙箱平台等等技术方案，甚至包括训练方案的消融实验，评测的设计等，有时间认真读一读报告。
4.6 用 warp decode 实现更好的 MoE 模型推理 · Cursor
　　这篇博客有蛮多我不太熟悉的知识，如果表述有误请联系我更正～