M2.1-Coding 多语言/多任务与泛化性

MiniMax-M2.1 的编程能力在前代模型的基础上实现了显著提升, 在多个内外部 benchmark 上追平或超越了全球一线模型的水平。作为一款专为 Agentic 场景优化的开源模型, M2.1 在代码生成、工具使用、指令遵循和长程规划等方面都展现出了卓越的能力。想要在此分享我们在提升真实场景 Coding 能力过程中积累的一些认知和实践经验。

SWE-Bench 与真实场景 Coding 的 Gap

在 2025 年, SWE-Bench 已经成为代码生成场景最权威的评测标准。在评测中, LLM 需要面对 Github 上真实仓库中的 Bug, 通过多轮代码阅读和测试进行修复。SWE-Bench 的核心价值在于它所评测的任务与程序员日常工作高度接近, 同时任务结果可以通过测试用例客观校验——这一特性对于强化学习训练尤为重要, 我们可以直接将测试通过率作为 reward signal, 在真实代码环境中持续优化模型, 而不需要依赖人工标注或模型评估带来的噪声。

然而, 和其他所有评测标准一样, SWE-Bench 并不完美。对于真实场景可用的 Coding Agent 来说, SWE-Bench 之外还有更多能力维度需要关注:

1. 语言覆盖单一: SWE-Bench 目前只覆盖了 Python 一种语言。而在真实的开发场景中, 开发者需要处理 Java、Go、TypeScript、Rust、C++ 等多种语言, 甚至经常需要在同一项目中使用多种语言协作。
2. 任务类型受限: SWE-Bench 只涉及修复 Bug 这一类任务。其他诸如实现新 Feature、生成测试用例、项目重构、代码审阅、性能优化、CI/CD 配置等真实场景的能力无法被评估。
3. 脚手架绑定: SWE-Bench 通常只评估模型在某一个特定脚手架 (Scaffold) 上的表现, 因此模型在其他脚手架上的泛化性无法得到准确观测。同时, 不同的 Agent 脚手架会设计各种不同的上下文管理策略, 模型需要能够适应这些差异。

如何填补这些 Gap

1. 多语言环境规模化 (Environment Scaling)

   我们经常看到开发者抱怨现在的 Coding Agent 在 Python / JavaScript 类的语言上表现不错, 但在更多严肃的企业级开发场景上效果不那么好。如果任务本身再涉及比较复杂的项目理解, 效果会变得更差。

   为了解决这个问题, 在 M2.1 的训练周期里, 我们构建了一套完善的数据管线, 覆盖了 Top 10+ 的主流编程语言, 从对应的测试用例, 到 Github 获取大量的 Issue、PR 和对应的测试用例, 并基于这些原始数据进行严格的筛选、清洗和改写, 最终产出了总计超过 10 万个可用于多语言 Training的数据质量。Coding Agent本身就非常适合批量制造这种训练环境, 在这个过程中, 我们发现不管M2模型还是其他前沿模型, 多语言环境构造的成功率都比Python语言上更低。这里主要有几种不同的情况:

   • 编译型语言的环境复杂性: Python作为解释型语言, 环境配置相对简单。但对于编译型语言, 我们需要处理复杂的编译工具链、版本兼容性和交叉编译等问题。一个 Java 项目可能依赖特定版本的JDK、Maven/Gradle, 以及大量的第三方库, 任何一个环节出错都会导致构建失败。
   • 多样的测试框架: Python 生态中 pytest 几乎一统天下, 但其他语言的测试框架则更加分散。Java 有 JUnit、TestNG; JavaScript 有 Jest、Mocha、Vitest; Go 有内置的 testing 包但也有 testify 等扩展; Rust 有内置测试和 criterion 等。我们需要为每种框架设计专门的测试执行和结果解析逻辑。
   • 依赖管理与项目结构: 不同语言的包管理器在依赖解析、版本锁定、私有仓库支持等方面差异巨大。npm 的 node_modules 嵌套结构、Maven 的中央仓库机制、Cargo 的语义化版本控制, 各语言的项目结构规范也各不相同: Python 项目结构相对灵活, 但 Java 项目通常遵循严格的 Maven/Gradle 目录规范, Go 项目有 GOPATH 和 Go Modules 两种模式, Rust 项目有 workspace 的概念。理解这些依赖管理机制和项目结构对于正确定位代码和运行测试至关重要。
   • 错误信息的解析难度: 不同语言和工具链产生的错误信息格式各异, 编译错误、链接错误、运行时错误的表现形式也不同。我们需要训练模型理解这些多样化的错误信息, 并从中提取有用的调试线索。

   最终, 我们构建了一套覆盖 JS、TS、HTML、CSS、Python、Java、Go、C++、Kotlin、C、Rust 等十余种语言的多语言训练体系, 从真实 Github 仓库中获取了超过 10 万个可用于训练和评测的环境, 每个环境都包含完整的Issue、代码和测试用例。为了支撑如此大规模的环境构建和 RL 训练, 我们搭建了高并发的沙盒基础设施, 能够在 10 秒内启动超过 5000 个隔离的执行环境, 同时支持数万个环境并发运行。这套基础设施让我们能够高效地进行大规模的多语言 Coding Agent 训练。

2. 超越 Bug Fix: 多任务能力

   真实的软件开发远不止修复 Bug。程序员的日常工作包括编写测试、代码审阅、性能优化等多种任务。我们在 M2.1 的训练中也针对这些场景进行了专项优化, 包括获取了大量高质量的问题和设计了对应的Reward信号:

   • 测试生成能力: 早在M1的研发过程中, 我们就发现, 写测试的能力是制约语言模型生成代码能力的一个重要卡点。在 Agentless框架中, 模型会并行生成多个修复方案, 再使用自己生成的测试验证并生成一个最终的方案。而由于M1在RL过程中的reward设计不合理, 总是会这一步写出过于简单的测试代码, 造成大量错误修复方案被选中。生成高质量的测试用例需要模型深入理解代码逻辑、边界条件和潜在的失败场景。M2.1 基于GitHub PR和自身生成的Code Patch合成出大量提升测试能力的的训练样本, 最终在评估测试能力的 SWT-bench上打平了 Claude Sonnet 4.5。
   • 代码性能优化: 除了代码实现的正确性, 运行效率也在实际开发中也非常关键。模型既需要理解算法复杂度、内存使用、并发处理等底层知识, 同时也需要掌握软件开发中具体API的最佳实践。在训练中, M2.1被鼓励写出运行效率更优的代码, 后续在 SWE-Perf 上也取得了明显进步, 平均能取得3.1%的性能提升。未来我们还会把对应的优化方法用到 Kernel 优化、数据库查询优化等其他关心性能的场景。
   • 代码审阅能力: 我们基于 SWE 框架构建了内部 Benchmark SWE-Review, 覆盖多种语言和场景, 评估代码缺陷的召回率和幻觉率。一次 review 只有在准确识别目标缺陷且不产生任何误报的情况下才被判定为正确, 这对模型的精准性提出了很高要求。
3. 脚手架泛化性 (Generalization on OOD Scaffolds)

   脚手架泛化性对于 Coding Agent 至关重要。开发者的使用脚手架各不相同, 有人用 Claude Code, 有人用 CURSOR, 有人用自有 Agent 框架。如果模型只针对某一个脚手架优化, 在其他环境下的表现就会大打折扣, 就会严重限制真实开发场景上的能力表现。在M2.1中, 我们认为脚手架泛化主要考察了模型的长程指令遵循能力和上下文管理策略的适应能力:

   • 长程指令遵循能力: 复杂的开发场景要求模型能够整合和执行来自多个来源的"复合指令约束", 包括 System Prompt、User Query、Memory、Tool Schema 以及各种规范文件 (如 Agents.md 、Claude.md 、Skill.md 等)。开发者通过设计这些规范严格约束了模型应有的表现。一旦Agent在推理过程中不满足某一步的要求就有可能导致端到端的效果严重衰变。
   • 上下文管理的适应能力: 在M2的发布初期, 社区对Interleaved Thinking这一设计还不太理解, 在很多脚手架里使用时, 效果都与模型本身的能力严重不符。当时我们发现一些热门脚手架的设计会在多轮对话中丢弃掉一些历史thinking内容, 这种设计让M2的效果在不同的评测集上出现不同幅度的下降。开发者使用Interleaved Thinking这一特性最大程度释放M2.1的全部能力, 另一方面我们仍然建议开发者保证用户在各种天马行空的上下文管理策略情况下模型智商仍然在线。

   为了验证M2.1的脚手架泛化性, 一方面我们直接测试了不同的脚手架上的表现, 另一方面我们构造了更接近真实场景用法的测试集, 观察模型的表现是否满足脚手架的各种指令约束。最终我们发现, 在 mini-swe-agent、Droid 和 Claude Code 里面, M2.1 的 SWE-bench 分数都维持在 67 分以上: