MiniMax M2.1：在 Agent 场景下的后训练技术与实践经验

M2.1 在上一代 M2 模型基础上进行了进一步的后训练优化，同时也是上个月开源的最新主力模型。该模型采用 MoE 架构，总参数量约230B，激活参数约10B。

M2.1 在Agent 场景下表现出优异的可用性，即使在激活参数较小的条件下，也能够保持高效的推理速度和出色的性能表现，为各类生产级应用提供稳定的工程化能力。

首先是数据合成。数据合成大概分为三个部分：

• 真实数据驱动的数据合成：SWE Scaling
• 专家驱动的数据合成：AppDev
• 虚拟长程任务合成：WebExplorer

前面两个其实是关于 Coding 的场景，后面这个是偏通用的搜索场景。

首先是比较核心是整个软件工程场景下的数据 Scaling，要利用好 GitHub 这样一个非常庞大且结构化的数据来源，去合成各种各样 Verifiable（可校验）的任务。有了这些任务之后，无论是去做拒绝采样、构建 SFT 数据，还是去做 RL，都会有非常好的数据基础。

我大致介绍一下整体流程。最原始的数据来源是 GitHub 的 PR（Pull Request）和 Commit。这里会去做质量筛选，方法有很多，简单一点的可以筛选最终被 Merge 的 PR，当然也会有一些其他的规则，比如是否带相关的测试用例。

有了这些 PR 之后，接下来一步是相对核心的点，我们要针对这些 PR 构建一个能够运行的 Docker 镜像环境。

镜像环境的构建本身不是一件容易的事情。现在的通用做法是通过 Agent 在代码沙盒里给它一些工具，让它不断地 Build，并根据 Build 结果进行自我迭代循环，尝试把环境构建出来。

理想情况下，这个过程可以完全自动化，但目前还没有达到特别理想的状态。在特定语言或特定库的版本中，环境不一定能构建得很好，这时会需要一些有经验的专家知识来帮助优化 Agent 的执行流程，这种流程算是一种 Skill（技能）的注入。

这样，我们就针对这些 PR 构建了一个可以运行的虚拟 Docker 镜像环境。

在这一步之后，会对 PR 本身做一些 Tagging（清理）和分流。PR 本身包含很多种数据类型，比如 Bugfix、增加 Feature、性能优化、测试用例的构建与重构等，大概有几十种。

做分流的目的是因为对于不同种类的 PR 或 Commit，后续利用的方法是不太一样的。

举个最简单的例子，比如最主流的 Bugfix 场景，我们会去抽取它的一些 F2P 以及 P2P 的测试用例。有了这些测试用例之后，我们可以去校验。例如当一个 Golden Patch 能通过时，我们认为这条数据是可以通过的，那么最后让模型作为一个 Agent 在沙盒里修复这个 Bug，并用 F2P 和 P2P 的 Test Case 去校验它是否真的通过了。

这里 P2P 的主要作用是防止在修复 Bug 的过程中引入额外的 Bug。如果进入新增 Feature 的场景，上述做法可能就不一定成立。例如在新增 Feature 的情况下，写的测试用例可能会依赖新增功能本身的代码脚本（如函数签名）。

这种情况下，它在构建阶段可能就失败了，不一定会存在 F2P 或 P2P 的测试用例，而且测试用例的抽取逻辑就会不同。例如需要专注于抽取 PR 过程中新增的测试点，然后同样需要校验原始 Golden Patch 至少在这些新增测试点上是能够通过的。

再比如在性能优化上，并不存在修复 Bug 的过程，所以不一定存在 F2P 测试，这种情况下就是抽取 P2P 测试，包括定位真正做了性能改进的测试点，去验证它在修复前后确实有稳定且显著的性能差异。

这里举的是一些基础例子，不同种类的 PR 也会有不同的做法。

在这一步之后，进入第三步（列），即模型对数据做校验。校验的目的是因为，即使在基础的 Bugfix 场景下，由于使用的是原始 GitHub PR 数据，有的并不规范，或者测试用例不一定能准确涵盖原始描述的 Issue。这种情况下会出现按照问题描述永远解不了 Bug 的情况。

这时就需要通过模型对原始测试用例和问题做校验，确保其一致性。如果确实缺失关键信息，可以通过模型在原始问题描述中做补充，保证它是一个自包含的完整问题。

在这一步之后，对于同一个 PR 或 Issue，有很多种不同的利用方式。比如，可以增加额外的 Bug，或者把多个相邻的 Commit 或 PR 合并到一起，增加难度，类似于 SWE-smith 的做法。

还有一种做法是，Bugfix 场景和 SWE-Test 场景是可以完全等价转换的。原先 Bugfix 是指在应用 Golden Patch 之前会挂掉，应用后能通过。

如果把它改造成写测试用例的任务，任务就反转过来了：要求模型写一个测试用例，使得它在应用 Patch 前的代码库状态下会 Fail，而修复后能通过。这对应到模型需要有较强的写测试用例的能力，且该任务与原先的 Bugfix 同源，并且是 Verifiable 的。

再者，可以做代码审阅类的任务。代码审阅任务与前面有些不同，它可以直接从 GitHub Filtering 这一步连线到 SWE Review，原因是本质上可以构建一些不需要完全运行环境的代码审阅任务。

比如我们平时在本地开发项目，本地环境不一定能完整运行所有测试或跑起整个代码库。这种情况下，模型需要看代码库，静态分析文件间的依赖关系并提出问题。由于不依赖环境构建，它可以做到更好的多样性。

工作原理是类似的，PR 包含修改前后的文件，如果模型能 Review 出修改前已包含的 Bug，再用一个 LLM 校验其一致性，本身也可以作为近似可校验的任务。总的来说，可以有很多问题的变形和增强方式。

最终，我们会得到一个 SWE 类的数据及其运行环境，包括原始问题描述、基于测试用例的完全 Verifiable 的 Reward，以及 Docker 运行环境。

有了数据之后，用法包括 SFT 和 RL。在 SFT 方面，我们会通过多脚手架（Multi-scaffold）去做拒绝采样，以此优化模型的泛化性。

另外在 RL 方面，使用多脚手架的原因是现在的脚手架往往包含复杂的上下文管理逻辑。如果只在一个简单的 React Agent 框架里做数据，模型很难泛化到其他脚手架的行为上。

比如在 Claude Code 里会有很多 System Reminder 或 Skill claude MD 等内容，如果模型从未见过，它就没有办法泛化到训练数据未涉及的空间。所以我们会有一套完善的工程基建，确保能在多脚手架环境中对模型做拒绝采样，生成更好的轨迹。

整个 SWE 数据核心思想的总结：基于原始 GitHub 数据构建 Agent 驱动的自动化数据管线，产出多样的、可校验的 SWE 类数据和环境。

这方面很需要创造力，比如任务的合成方法以及可校验任务的构建。目前这方面的研究很多，最近也有很多新的开源工作出来，大家可以关注。

截止到 M2.1，我们整个 SWE 数据的 Scaling 已经做到了不错的状态。覆盖了超过 10 种主流编程语言，涵盖了各种代码任务类型和编程场景。最终可用的 Repo（能直接跑 SFT）数量大于 1 万个 PR，可变任务数量超过 14 万个。

最后是在几个 SWE 类核心榜单上的指标。对比 M2.1 和 M2，尤其在 Multi-SWE、SWE-bench 等多语言场景上，由于做了更充分的 Scaling，有显著提升。

另外在不同脚手架上评测，能发现模型保持了较好的性能稳定性。不同脚手架的上限不同，比如 Claude Code 设计较好，而 Mini-SWE-agent 本质是纯 Bash 脚手架，通过 Bash 读写文件会消耗更多 Context，导致模型上限更低，这符合预期，但模型对不同脚手架展现了较好的适应性。

Coding 方向，我们将其分为两类：SWE 类和 APPDev 类。

我们将 APPDev 定义为从零到一完成全栈软件开发任务。将其与 SWE 区分的原因是，APPDev 开发无法预先定义一系列固定的测试用例。SWE 场景基于 GitHub，行为空间受限，是在成熟 Repo 中操作；而 AppDev 是从零到一编写，无法预先限定死测试用例，其 Reward 链路与 SWE 完全不同。

在 APPDev 场景中，会用到 Expert in the Loop，利用数据专家的经验来帮助迭代和生成数据。

目前 M2.1 重点关注前端、后端、安卓和 iOS。公司内相关场景的专业研发同学会作为数据专家加入，帮我们优化 APPDev 的数据合成。

比如最开始，专家会写一些 Prompt 或 Meta Query。这些 Meta Query 结合特定场景的 Random Seed，能合成多样化的用户 Query。有了 Query 后进行采样，采样前需要构建 Rubric-based Reward，这非常依赖专家经验，因为不同专家对不同任务的校验标准不同，无法通过全自动方法完成。

除了 Rubric，专家还可以在流程中注入经验。例如在写网页前端时，上一代模型 M2 会有一些不好的习惯，比如写出较丑的渐变色。而专家可以设计一些先验 Prompt 指导页面设计。如果模型有不错的 System Prompt 遵循能力，就能在指导下采样出更好的轨迹。有了轨迹后，可以使用类似于 Prompt distillation 的方法，采样时带有 System 信息，但训练时去掉，这样专家的 Best Practice 就会变成模型的默认行为。

最后是在多脚手架上做拒绝采样及 RL。此外，还会利用 Agent as a Verifier 来做 Reward 校验。原因是在前端等场景，仅给出一个 Rubric 很难根据静态代码做判断。我们会让模型在沙盒环境中把项目完整部署起来，通过 Playwright 等工具与界面交互，根据交互后的状态变化对照 Rubric 打分。

这与 LLM-as-a-judge 的区别在于，它需要利用工具做多轮交互才能进行判断。

整个 AppDev 领域目前开源榜单中较受关注的是 Hot Arena，我们在上面排行开源模型第一。关于 App 我们也有自建榜单 VIBE Arena，后面会展开介绍。

除了 Coding Agent 场景，我们也在投入精力做偏通用的 Agent 场景。Search（搜索）是通用场景的基础。

我们之前有一篇 WebExplorer 的工作：Explore and Evolve for Training Long-Horizon Web Agents，该工作目前在 arXiv 上可见。核心思想包含两部分：第一步是通过智能体自由探索构建信息丰富的种子问题；第二步是迭代式地进行 Query 进化来提升问题复杂度。

展开一个例子：对于 WebExplorer 来说，最开始只有一个随机种子，比如“巴西国家队”。模型通过搜索找到 1950 年世界杯及“马拉卡纳惨案”。比赛信息中提到裁判叫 George Reader，他多年后在英格兰俱乐部担任主席，该俱乐部在 1976 年足总杯击败曼联夺冠，制胜球由 Bobby Stokes 打进。

模型最后将搜索链路的线索综合，生成一个信息丰富的初始问题。这个问题虽然信息量大，但有明显的搜索入口。进化的策略包括移除、模糊化和替换。比如：

• 把具体的比赛信息模糊化为“赛制独特、没有淘汰赛的世界杯”；
• 把“足总杯击败曼联”这种显著信息改为“带领乙级联赛俱乐部战胜甲级豪门”，增加搜索难度；
• 把球员去世年龄等容易在 Wiki 搜到的信息移除。

最终进化出的 Query 相比初始问题复杂得多，没有明显的搜索入口，模型必须根据线索一步步探索。

这种长程任务合成的标准是解决问题的平均轮次。初始问题约 7.9 轮解决，进化后达到 9.9 轮。该策略已上线 M2.1。最终 M2.1 在 BrowsComp 榜单上，尤其在带有 Context Management（上下文管理）的情况下，表现接近 GPT-4.5 的 SOTA 指标。上下文管理是目前 Search Agent 的主流做法，即在评测过程中不断清空上下文，保持其清晰干净，使模型能持续进行 Test-time Scaling。

接下来介绍 RL 框架和算法。

我们使用的是内部自研框架 Forge，它在 M2 研发之初就是面向 Agent 场景设计的。Forge 的一个重要 Feature 是支持任意 Agent 脚手架运行 RL。接入 Forge 只需实现四种接口：

• agent_reprocess：预处理（初始化）
• agent_run：运行
• agent_postprocess：后处理
• calculate_reward：计算 Reward

例如，即使是只有二进制程序的黑盒 Agent 也可以接入。在 Agent 运行时，将其 Base URL 替换为 Forge 内部的推理引擎服务。目前该引擎已支持内部推理框架及 SGLang。替换后，Agent 运行循环中的所有日志都会在推理服务器端落盘。Data Coordinator 会对日志做后处理，提取 Sub-agent 的轨迹。为了提升训练效率，框架还会对 Trajectory 做智能的前缀合并。

算法方面，其实我们截止到 M2.1 时代，整个 RL（强化学习）算法的核心仍然沿用了原先在 MiniMax M1 论文中所提出的 CISP 算法。当时在 M1 里面提到了两个比较核心的点：一个是 CISP 本身的重要性采样截断（Importance Sampling Truncation）设计，另一个是当时针对 FP32 精度做的修复。

第一部分是 CISPO 的目标函数。你可以将其理解为：它与 Reinforce 的目标函数非常相似。它本质上就是一个 Reinforce 在 Off-policy 场景下做了重要性采样修正的目标函数。CISPO 改变的点在于，它会对重要性采样的权重——也就是标量加权的量——进行 Clip（裁剪）。在实践中，这个 Clip 通常是指限制其上限，从而确保梯度不会过大，本质上是在控制梯度的运行幅度。

CISPO 算法最初设计是在大家都在复现 R1-ZERO 那套东西（包括字节的 DAPO）的时候，当时我们在复现过程中有一个核心观察：在整个 RL 运行过程中，有一些 Token 会一直被 PPO 的 Clip 机制过滤掉。一旦被 Clip，这些 Token 就永远失去了梯度。统计发现，这些 Token 往往是类似于 “wait” 这种转折词。这意味着 PPO 的裁剪机制会导致很多 Token 无法通过训练涌现出来。

在这种情况下，DAPO 的做法是提高 PPO Clip 的上界。而我们 CISPO 的想法是让所有的 Token 都可以计算梯度，只是我们需要控制梯度重要性采样的加权系数。通过这种方式，我们虽然引入了一些 Bias（偏差），但减少了整体优化的方差。

当时我们在前期完成小模型实验并迁移到 MiniMax M1 这个更大的模型做 RL 时，发现整体 Reward 几乎不增长。我们将训练概率和推理概率打印出来后发现，它们出现了一些明显的分段横线，且相关系数相比 Dense 模型低很多。后来推理同学进行逐层排查，最终发现预测层 LLM_head 的精度至关重要。将该层精度修复到 FP32 之后，整个训推一致性得到了显著加强，从而实现了稳定的训练提升。

再到 M2 这一代，主要的变化在于它进入了 Agentic RL 的场景，涉及多轮工具调用。这些工具调用本质上会引入来自外界环境的噪声注入，导致运行轨迹变得更加极端、更加 Off-policy，或者出现统计值异常的情况。

在这种情况下，我们吸收了社区提出的一些主要方法，包括 MIS（重要性采样修正）以及基于 PPO 的轨迹过滤。这里的核心思想是过滤掉统计值偏离异常、处于长尾分布的轨迹，防止梯度出现巨大波动，从而保障整体 RL 训练的稳定性。

这个图引用了 Meta 论文《The Art of Scaling Reinforcement Learning Compute for LLMs》里的一张图。当时他们其实做了一个比较系统的实验对比，他们的实验结论与我们也是比较一致的。

实验发现，整个 CISPO 算法无论从收敛速度还是收敛上限来看，在整个 Scaling 的过程中表现都非常出色。图中左侧部分刻画的是 CISPO 的重要性采样（Importance Sampling Trick）的效果，右侧部分则刻画了 FP32 精度修复带来的收益。

总的来说，这篇文章的实验做得非常充分。如果对强化学习（RL）感兴趣的同学，我建议并推荐大家可以去看一看。

接下来分享一下我们在 M2.1 时代同步推出的三个评测。

• VIBE: Visual & Interactive Benchmark for Execution in Application Development
• SWE-Review
• OctoCodingBench

目前 VIBE 评测的数据已经在 Hugging Face 上开源了，不过它的基建现在还没有完全就绪，我们也在紧锣密鼓地推进中。

首先说 VIBE，它对应的是 AppDev（应用开发）场景。由于市面上缺乏衡量此类效果的榜单，我们自建了该评测，涵盖了前端、模拟安卓、iOS 和后端。M2.1 相比 M2 在这方面有长足进步。

在校验逻辑上，我们采用了 Agent as a Verifier 的方案，即利用智能体在真实环境中执行。其 Reward（奖励）包含三个维度：

• 执行层：验证代码是否编译成功；
• 交互层：使用工具与界面进行交互，判断业务逻辑是否正确；
• 视觉层：基于美学标准打分，虽然这带有主观性，但我们会关注一致性较高的标准。

相比传统的 LLM-as-a-judge 仅通过静态截图进行评估，Agent 验证能够通过动态交互，更全面地反映 Bug 和实现上的缺陷。

另外两个是 SWE Review 和 OctoBench。SWE Review 对应管线中的审阅场景，设计了覆盖多语言、多场景的评测集，指标同时考虑召回率和幻觉率。OctoBench 评估 Agent 场景下的指令遵循能力。

与传统的 IF 榜单不同，Agent 场景中的指令不只来自 User 或 System Prompt，还可能来自 System Reminder、Claude.md 或工具 Schema。OctoBench 同步自研，通过 Checklist 进行 Rubric-based 打分。

最后是这个指标。M2.1 相比于 M2，因为我们在这方面做了一些优化，所以其实整体提升还是比较显著的，包括 SWE review、OctoBench 的这个指令遵从的效果。