【教程】别逗你xx笑了，自研模型？你上你也行！（Cursor Composer-2 训练路径分析与实战测试）
- 内容介绍
- 文章标签
- 相关推荐
综述
Cursor 发布的官方论文：Composer2.pdf
image828×466 50.3 KB
最近Cursor针对套壳Kimi的事情沸沸扬扬，之后Cursor直接通过论文的形式开放了训练过程。论坛里也有很多人在聊 Cursor 的 Composer 2的效果，作为一个练习时长两年半的大模型饲养员（bushi），也想给大家详细拆解下，让大家也可以尝试着自己训练一个~
由于domain gap（域间隙，即在一个数据集上训练模型，在另外一个数据集上进行预测性能下降很大）几乎为0，Composer 2 上线就直接把Opus 4.6按在地上摩擦（SWE-bench直接能干到 Multilingual 73.7%）当然这里指的是部分场景，Composer 2还是会过渡乱改（特别在老代码库）。
Cursor的核心思路就是：先让模型更懂代码，再把它放进真实开发环境里反复练。
Cursor 公布的数据里，Composer 2 在 CursorBench、Terminal-Bench 2.0 和 SWE-bench Multilingual 上都比前代明显提升。公开论文把这种提升归因于两件事：
1）continued pretraining（持续预训练）
先把底座继续喂大量更偏代码的数据，让模型的“代码直觉”更强。
2）reinforcement learning（强化学习）
不是只看它会不会答题，而是让它在真实 agent 式 coding 任务里学会：怎么找线索、怎么用工具、怎么少走弯路、怎么完成长任务。
这也意味着，对于一个特定领域的模型，RL确实是最佳方式。对于LoRA来说，作为finetuning的核心方法，应该叫做post-training。因为pretraining这个术语特指next token预测，LoRA本质上就是类似于MoE架构的“并联”操作，在这里Cursor的是full fine-tune + code-heavy数据，不是纯LoRA post-training.
总体来说，也就如下：
1.先准备一个足够强、适合交互式编码的基础模型
预训练…咱就不做了，太贵了。可以参考Cursor，选择Kimi这种开源大模型。
2.先做一轮 Continued Pretraining，让刚刚选择的模型更懂代码
这一步的目标不是教模型背答案，而是用 code-heavy 数据把它的分布拉近到真实软件工程任务。可以看到Cursor自己也说，Composer 2 质量提升来自他们第一次 continued pretraining run，这一步给后续 RL 提供了更强的基础。
3.把训练目标从“会答题”更改成“会在真实代码库里完成任务”
真正的 coding agent，不是只会给出一段看起来正确的回答，而是要能在大型代码库里理解问题、制定计划、执行修改并完成任务。这点是核心，需要用到数据集，要收集大量的项目+ Git提交历史（PR评论）打包成一整套的 code-heavy 数据集，可以用LoRA微调，让其保持一致的长上下文（例如256k）。至于从哪获得数据集嘛…
4.把真实工具链一起纳入训练，让模型学会正确地用工具
模型要学的不是“纯文本作答”，而是如何在任务里有效使用文件读写、terminal、grep、语义搜索等工具。在 RL 中不仅训练模型解决问题，还训练它更高效地用工具、尽量并行，并减少没必要的回复和无证据断言。这个是用于解决Agent调用问题的，也需要做。
5.用异步 RL 训练长任务，而不是只优化短回合
一旦任务变长，模型最大的挑战不是不会写，而是容易忘、跑偏、容易中断。要将 self-summarization 训练成模型行为：当上下文快满时，模型主动自己总结关键信息，再继续推进任务。这样训练出来的模型，才能稳定处理需要数百个动作的长链路 coding 任务。
6.把 Self-Summarization 训练成模型行为，而不是只当 Prompt 技巧
是官方博客里最值得抄的一点。Cursor 专门写了一篇文章解释：他们通过一种叫 self-summarization 的 RL 过程，让模型在上下文快满时，自己生成一个有用的工作总结，再继续推进任务。
也就是：“先总结上文关键信息，再输出下一步规划”（这个佬友们可以直接作为系统提示词用到自己的工作流里也是非常好的~）
7.最后用真实会话做评测闭环，形成自己的 benchmark
不要只盯公开榜单，而要用真实用户任务持续评估模型。Cursor 官方写得很清楚：他们采用 hybrid online-offline eval，离线部分是基于真实 Cursor 工程会话构建的 CursorBench，在线部分则看真实流量中的表现，从而让模型优化方向始终贴近真实开发场景。
综上，整个训练路径很清晰，但关键的是 Cursor坐在几百万真实session 上，每个用户的accept/reject/edit都是免费的reward signal。虽说可以照抄流程，但很难有那个数据量级。（坏Cursor！）
实战
接下来就是带佬友们实战啦，但由于直接微调 Kimi K2.5 全量参数 算力要求过大，Cursor自己做Composer-1都说是上千卡级别，当然我认为佬友们今后一年后就实力做了（毕竟大家都是AI Top）
这次微调目标是：训练一个 Python 后端 bugfix + PR 生成 assistant。使用 8 X H200（141GB HBM3e），冻结绝大多数权重，只训练 adapter / LoRA，并把 RL 做成小规模。
输入是这四类任务之一：
-
issue / 报错日志 → 定位根因
-
failing test → 生成最小修复 patch
-
PR diff + review comments → 生成修订方案
-
长上下文 repo 摘要 → 输出“当前状态 + 下一步计划”
输出统一成四段：
-
summary：当前已知事实 -
plan：下一步行动 -
actions：需要执行的工具/文件操作 -
final：patch / 解释 / PR note
这样做的好处是，把 Cursor 式 agent 行为 压缩成了一个窄场景模型，根据综述：Cursor 官方也明确强调：提升来自 continued pretraining + RL，以及把模型训练成能在真实 coding agent 环境里完成长任务。
因此，我们的路线要制定为三个阶段：
阶段 A：定向 SFT，先把模型训成“会按你想要的格式干活”
阶段 B：小规模在线 RL，让模型学会“少走弯路”
阶段 C：自总结（self-summarization）专项训练
首先准备数据集（对于这个任务无需几百万样本，可以通过爬虫或公开方法获取对应的，毕竟只是针对Git）：
训练数据 1：issue → patch
来源：
-
Git commit
-
PR diff
-
PR review comment
-
对应 issue / 报错
-
测试前后状态
把它整理成一条监督样本（这边我直接上Opus做蒸馏来辅助整理)：
{
"messages": [
{"role": "system", "content": "You are a code repair assistant."},
{"role": "user", "content": "Issue: login timeout after token refresh\nRepo summary: ...\nRelevant files: ...\nFailing tests: ..."}
],
"target": {
"summary": "Token refresh path updates cache but not session timestamp.",
"plan": [
"Inspect auth middleware",
"Patch timestamp update",
"Run auth test subset"
],
"actions": [
"open auth/middleware.py",
"edit refresh_session()",
"run pytest tests/auth/test_refresh.py"
],
"final": "```diff\n...\n```"
}
}
训练数据 2：长上下文总结
把一次真实修 bug 过程切成多段，人工或程序生成：
-
已读文件列表
-
已知结论
-
已尝试动作
-
下一步建议
专门训练 summary -> next plan。
训练数据 3：PR review 修订
输入：
-
原 diff
-
review comments
-
相关文件摘要
输出：
-
修改计划
-
精简 patch
-
回复 review 的说明
开跑：
阶段A：训练脚本层面，其实并不复杂，核心就是：8 张 H200 对应 8 个 worker→每个 worker 1 张 GPU，然后数据按 shard 切开，LoRA 只挂在 attention / MLP 的投影层，底座参数全部冻结
image1125×309 91.2 KB
阶段 B：小规模RL
这边不会真的去复刻 Cursor 的大规模异步集群，只做一个轻量版闭环：
-
从验证任务里取一条 issue / failing test
-
让当前模型采样 4 条候选轨迹
-
在本地 sandbox 里执行它生成的 patch 和命令
-
根据测试结果自动打分
-
把最优轨迹回流，继续训练
reward 我没有设计得太花，只保留最实用的几项：
-
测试是否通过
-
lint 是否通过
-
patch 是否足够小
-
工具调用是否过多
-
是否出现明显无效操作
阶段 C：
在这个简化版里，我没有做特别复杂的 compaction，而是直接规定：
当上下文长度接近阈值时，模型必须先输出：
-
repository_state -
known_facts -
files_touched -
open_questions -
next_step
然后再继续 patch 生成。这样训练后，模型在处理需要几百步的长链路任务时，几乎不会忘、不会跑偏、不会中断，稳定性很高。
image1153×552 141 KB
测试权重，稳定输出了四个既定目标的输出方式
image422×191 5.26 KB
image411×270 11.9 KB
Cursor调用工具准确执行了Exploring和修改工具以及代码工具（当然这是Kimi自带就有的能力）
此次实战只展示了一个小样例，具体来说如果整个框架可以的话就可以根据 Scaling Law 扩大数据集了，可惜我没有…
网友解答：--【壹】--：
哈哈哈
--【贰】--：
强
--【叁】--：
学习了
--【肆】--：
“Cursor调用工具准确执行了Exploring和修改工具以及代码工具（当然这是Kimi自带就有的能力）”
--【伍】--：
厉害厉害
--【陆】--：
太强了，大佬
--【柒】--：
太有实力了
--【捌】--：
好文 留个信标
--【玖】--：
强，学习了
--【拾】--：
牛牛牛
--【拾壹】--：
six
--【拾贰】--：
感谢佬的分享
--【拾叁】--：
这个就是专业
--【拾肆】--：
先赞后看，跟大佬学习！
--【拾伍】--：
我上真不行
--【拾陆】--：
666，这个干货硬啊
综述
Cursor 发布的官方论文：Composer2.pdf
image828×466 50.3 KB
最近Cursor针对套壳Kimi的事情沸沸扬扬，之后Cursor直接通过论文的形式开放了训练过程。论坛里也有很多人在聊 Cursor 的 Composer 2的效果，作为一个练习时长两年半的大模型饲养员（bushi），也想给大家详细拆解下，让大家也可以尝试着自己训练一个~
由于domain gap（域间隙，即在一个数据集上训练模型，在另外一个数据集上进行预测性能下降很大）几乎为0，Composer 2 上线就直接把Opus 4.6按在地上摩擦（SWE-bench直接能干到 Multilingual 73.7%）当然这里指的是部分场景，Composer 2还是会过渡乱改（特别在老代码库）。
Cursor的核心思路就是：先让模型更懂代码，再把它放进真实开发环境里反复练。
Cursor 公布的数据里，Composer 2 在 CursorBench、Terminal-Bench 2.0 和 SWE-bench Multilingual 上都比前代明显提升。公开论文把这种提升归因于两件事：
1）continued pretraining（持续预训练）
先把底座继续喂大量更偏代码的数据，让模型的“代码直觉”更强。
2）reinforcement learning（强化学习）
不是只看它会不会答题，而是让它在真实 agent 式 coding 任务里学会：怎么找线索、怎么用工具、怎么少走弯路、怎么完成长任务。
这也意味着，对于一个特定领域的模型，RL确实是最佳方式。对于LoRA来说，作为finetuning的核心方法，应该叫做post-training。因为pretraining这个术语特指next token预测，LoRA本质上就是类似于MoE架构的“并联”操作，在这里Cursor的是full fine-tune + code-heavy数据，不是纯LoRA post-training.
总体来说，也就如下：
1.先准备一个足够强、适合交互式编码的基础模型
预训练…咱就不做了，太贵了。可以参考Cursor，选择Kimi这种开源大模型。
2.先做一轮 Continued Pretraining，让刚刚选择的模型更懂代码
这一步的目标不是教模型背答案，而是用 code-heavy 数据把它的分布拉近到真实软件工程任务。可以看到Cursor自己也说，Composer 2 质量提升来自他们第一次 continued pretraining run，这一步给后续 RL 提供了更强的基础。
3.把训练目标从“会答题”更改成“会在真实代码库里完成任务”
真正的 coding agent，不是只会给出一段看起来正确的回答，而是要能在大型代码库里理解问题、制定计划、执行修改并完成任务。这点是核心，需要用到数据集，要收集大量的项目+ Git提交历史（PR评论）打包成一整套的 code-heavy 数据集，可以用LoRA微调，让其保持一致的长上下文（例如256k）。至于从哪获得数据集嘛…
4.把真实工具链一起纳入训练，让模型学会正确地用工具
模型要学的不是“纯文本作答”，而是如何在任务里有效使用文件读写、terminal、grep、语义搜索等工具。在 RL 中不仅训练模型解决问题，还训练它更高效地用工具、尽量并行，并减少没必要的回复和无证据断言。这个是用于解决Agent调用问题的，也需要做。
5.用异步 RL 训练长任务，而不是只优化短回合
一旦任务变长，模型最大的挑战不是不会写，而是容易忘、跑偏、容易中断。要将 self-summarization 训练成模型行为：当上下文快满时，模型主动自己总结关键信息，再继续推进任务。这样训练出来的模型，才能稳定处理需要数百个动作的长链路 coding 任务。
6.把 Self-Summarization 训练成模型行为，而不是只当 Prompt 技巧
是官方博客里最值得抄的一点。Cursor 专门写了一篇文章解释：他们通过一种叫 self-summarization 的 RL 过程，让模型在上下文快满时，自己生成一个有用的工作总结，再继续推进任务。
也就是：“先总结上文关键信息，再输出下一步规划”（这个佬友们可以直接作为系统提示词用到自己的工作流里也是非常好的~）
7.最后用真实会话做评测闭环，形成自己的 benchmark
不要只盯公开榜单，而要用真实用户任务持续评估模型。Cursor 官方写得很清楚：他们采用 hybrid online-offline eval，离线部分是基于真实 Cursor 工程会话构建的 CursorBench，在线部分则看真实流量中的表现，从而让模型优化方向始终贴近真实开发场景。
综上，整个训练路径很清晰，但关键的是 Cursor坐在几百万真实session 上，每个用户的accept/reject/edit都是免费的reward signal。虽说可以照抄流程，但很难有那个数据量级。（坏Cursor！）
实战
接下来就是带佬友们实战啦，但由于直接微调 Kimi K2.5 全量参数 算力要求过大，Cursor自己做Composer-1都说是上千卡级别，当然我认为佬友们今后一年后就实力做了（毕竟大家都是AI Top）
这次微调目标是：训练一个 Python 后端 bugfix + PR 生成 assistant。使用 8 X H200（141GB HBM3e），冻结绝大多数权重，只训练 adapter / LoRA，并把 RL 做成小规模。
输入是这四类任务之一：
-
issue / 报错日志 → 定位根因
-
failing test → 生成最小修复 patch
-
PR diff + review comments → 生成修订方案
-
长上下文 repo 摘要 → 输出“当前状态 + 下一步计划”
输出统一成四段：
-
summary：当前已知事实 -
plan：下一步行动 -
actions：需要执行的工具/文件操作 -
final：patch / 解释 / PR note
这样做的好处是，把 Cursor 式 agent 行为 压缩成了一个窄场景模型，根据综述：Cursor 官方也明确强调：提升来自 continued pretraining + RL，以及把模型训练成能在真实 coding agent 环境里完成长任务。
因此，我们的路线要制定为三个阶段：
阶段 A：定向 SFT，先把模型训成“会按你想要的格式干活”
阶段 B：小规模在线 RL，让模型学会“少走弯路”
阶段 C：自总结（self-summarization）专项训练
首先准备数据集（对于这个任务无需几百万样本，可以通过爬虫或公开方法获取对应的，毕竟只是针对Git）：
训练数据 1：issue → patch
来源：
-
Git commit
-
PR diff
-
PR review comment
-
对应 issue / 报错
-
测试前后状态
把它整理成一条监督样本（这边我直接上Opus做蒸馏来辅助整理)：
{
"messages": [
{"role": "system", "content": "You are a code repair assistant."},
{"role": "user", "content": "Issue: login timeout after token refresh\nRepo summary: ...\nRelevant files: ...\nFailing tests: ..."}
],
"target": {
"summary": "Token refresh path updates cache but not session timestamp.",
"plan": [
"Inspect auth middleware",
"Patch timestamp update",
"Run auth test subset"
],
"actions": [
"open auth/middleware.py",
"edit refresh_session()",
"run pytest tests/auth/test_refresh.py"
],
"final": "```diff\n...\n```"
}
}
训练数据 2：长上下文总结
把一次真实修 bug 过程切成多段，人工或程序生成：
-
已读文件列表
-
已知结论
-
已尝试动作
-
下一步建议
专门训练 summary -> next plan。
训练数据 3：PR review 修订
输入：
-
原 diff
-
review comments
-
相关文件摘要
输出：
-
修改计划
-
精简 patch
-
回复 review 的说明
开跑：
阶段A：训练脚本层面，其实并不复杂，核心就是：8 张 H200 对应 8 个 worker→每个 worker 1 张 GPU，然后数据按 shard 切开，LoRA 只挂在 attention / MLP 的投影层，底座参数全部冻结
image1125×309 91.2 KB
阶段 B：小规模RL
这边不会真的去复刻 Cursor 的大规模异步集群，只做一个轻量版闭环：
-
从验证任务里取一条 issue / failing test
-
让当前模型采样 4 条候选轨迹
-
在本地 sandbox 里执行它生成的 patch 和命令
-
根据测试结果自动打分
-
把最优轨迹回流，继续训练
reward 我没有设计得太花，只保留最实用的几项：
-
测试是否通过
-
lint 是否通过
-
patch 是否足够小
-
工具调用是否过多
-
是否出现明显无效操作
阶段 C：
在这个简化版里，我没有做特别复杂的 compaction，而是直接规定：
当上下文长度接近阈值时，模型必须先输出：
-
repository_state -
known_facts -
files_touched -
open_questions -
next_step
然后再继续 patch 生成。这样训练后，模型在处理需要几百步的长链路任务时，几乎不会忘、不会跑偏、不会中断，稳定性很高。
image1153×552 141 KB
测试权重，稳定输出了四个既定目标的输出方式
image422×191 5.26 KB
image411×270 11.9 KB
Cursor调用工具准确执行了Exploring和修改工具以及代码工具（当然这是Kimi自带就有的能力）
此次实战只展示了一个小样例，具体来说如果整个框架可以的话就可以根据 Scaling Law 扩大数据集了，可惜我没有…
网友解答：--【壹】--：
哈哈哈
--【贰】--：
强
--【叁】--：
学习了
--【肆】--：
“Cursor调用工具准确执行了Exploring和修改工具以及代码工具（当然这是Kimi自带就有的能力）”
--【伍】--：
厉害厉害
--【陆】--：
太强了，大佬
--【柒】--：
太有实力了
--【捌】--：
好文 留个信标
--【玖】--：
强，学习了
--【拾】--：
牛牛牛
--【拾壹】--：
six
--【拾贰】--：
感谢佬的分享
--【拾叁】--：
这个就是专业
--【拾肆】--：
先赞后看，跟大佬学习！
--【拾伍】--：
我上真不行
--【拾陆】--：
666，这个干货硬啊