社区文章 · 发布日期：2026 年 1 月 5 日
src: https://huggingface.co/blog/MiniMaxAI/multilingual-and-multi-task-coding-with-strong-gen
MiniMax-M2.1 在编码能力上较前一代取得了显著提升，在多个内部和外部基准上达到了甚至超过全球顶级模型的水平。作为一个专门针对代理场景优化的开源模型，M2.1 在代码生成、工具调用、指令遵循和长程规划等方面表现卓越。本文旨在分享我们在提升真实世界编码能力过程中获得的一些见解和实战经验。
The Gap Between SWE-Bench and Real-World Coding
到 2025 年，SWE-Bench 已成为代码生成场景中最具权威的评估标准。在该评估中，大型语言模型必须处理来自真实 GitHub 仓库的 Bug，并通过多轮代码阅读与测试修复这些 Bug。SWE-Bench 的核心价值在于评估任务非常贴近程序员的日常工作，并且其结果可以通过测试用例客观验证——这一特性对强化学习训练尤为重要，可直接将测试通过率作为奖励信号，在真实代码环境中持续优化模型，而无需依赖人工标注或模型评估带来的噪声。
尽管如此，与所有评估标准一样，SWE-Bench 并不完美。要在真实开发场景中让编码代理可用，还需要关注更多能力维度：
- 语言覆盖范围有限：目前 SWE-Bench 仅覆盖 Python，而现实开发中往往涉及 Java、Go、TypeScript、Rust、C++ 等多种语言，甚至同一项目中跨语言协作。
- 任务类型受限：SWE-Bench 只包含 Bug 修复任务，而真实开发还包括实现新功能、生成测试用例、项目重构、代码评审、性能优化、CI/CD 配置等多种任务类型，这些能力无法通过单一 SWE-Bench 评估。
- 框架依赖性强（Scaffold Binding）：SWE-Bench 通常只评估模型在特定脚手架上的性能，因此无法准确评估模型在其他脚手架上的泛化能力。而不同的 agent 框架对上下文管理策略的设计各不相同，模型需具备适应这些差异的能力。
How to Fill These Gaps
Environment Scaling
许多开发者抱怨当前编码代理在 Python/JavaScript 等语言表现尚可，但在更复杂的企业级开发场景中性能不佳。如果涉及复杂项目理解，性能会进一步下降。
为了解决这一问题，在 MiniMax-M2.1 的训练周期中，我们构建了一个覆盖 10+ 主流编程语言 的完整数据管道。我们收集了 GitHub 上大量 Issues、PR 及其对应测试用例，并对这些原始数据进行了严格过滤、清洗和重写，以保证训练数据的质量。
我们发现，不论是 M2 模型还是其他前沿模型，在构建多语言执行环境时的成功率均低于 Python，主要原因包括：
- 编译型语言的环境复杂性：Python 作为解释型语言配置相对简单，而对于 Java、Go、Rust、C++ 等编译型语言，需要处理复杂的编译链、版本兼容和交叉编译问题。例如 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 概念。理解这些机制对于正确定位代码和运行测试至关重要。
- 错误信息格式解析困难：不同语言和工具链产生的错误信息格式差异巨大，包括编译错误、链接错误和运行时错误。我们需要训练模型理解这些多样化的错误输出，并从中提取有用的调试线索。
最终，我们构建了覆盖包括 JavaScript、TypeScript、HTML、CSS、Python、Java、Go、C++、Kotlin、C、Rust 等语言的多语言训练体系，并从真实 GitHub 仓库中获取了 超过 100,000 个可用于训练与评估的执行环境。每个执行环境均包含完整的 Issues、代码和测试用例。
为了支持如此大规模的执行环境扩展和强化学习训练，我们搭建了一个高并发沙箱基础设施，能在 10 秒内启动 5,000+ 个隔离执行环境，并支持数万环境并发运行，从而高效开展大规模多语言编码代理训练。
Beyond Bug Fix: Multi-Task Capabilities
真实的软件开发远不止修复 Bug，还包括编写测试、代码评审、性能优化等日常任务。在 MiniMax-M2.1 的训练中，我们针对这些场景进行了专项优化，包括获取高质量训练问题及设计对应的奖励信号：
测试生成能力（Test Generation Capability）
在 M1 研发过程中我们发现，编写高质量测试代码是限制模型代码准确率的一个重要瓶颈。在无代理框架下，模型并行生成多个修复方案，然后使用自己生成的测试代码来选择最终方案。然而，由于 M1 强化学习阶段的奖励设计不合理，它倾向于生成过于简单的测试代码，导致大量错误修复方案被错误选择。
生成高质量测试用例要求模型深入理解代码逻辑、边界条件及潜在失败场景。MiniMax-M2.1 基于 GitHub PRs 和自生成 Code Patch 构建了大量训练样本以提升测试能力，在专注测试能力的 SWE-Bench 评估中与 Claude Sonnet 4.5 持平。
代码性能优化（Code Performance Optimization）
除了功能正确性之外，执行效率在实际开发中也至关重要。模型需要理解算法复杂度、内存使用和并发处理等底层知识，并掌握具体 API 的最佳实践。在训练过程中，M2.1 通过奖励设计鼓励模型生成更高效的代码，在性能评估 SWE-Perf 上平均提升了 **3.1%**。未来我们计划将这一优化方法应用于其他性能敏感场景，例如内核优化和数据库查询优化。
代码评审能力（Code Review Capability）
基于 SWE 框架，我们构建了内部基准 SWE-Review，该评估覆盖多语言和多种场景，用于衡量模型在发现代码缺陷时的召回率和幻觉率。只有当模型准确识别目标缺陷且不产生误报时，评审才被视为正确，这对模型的精确性提出了高要求。
Generalization on OOD Scaffolds
对于编码代理而言，在各种不同的 agent 框架下保持良好性能至关重要。因为开发者可能使用 Claude Code、Cursor 或专有代理框架，如果模型只针对某一框架优化，就会在其他环境中性能大打折扣，限制其真实开发能力。
在 MiniMax-M2.1 中，我们认为泛化测试主要考验模型的两项核心能力：长程指令执行能力和适应不同上下文管理策略的能力。
长程指令执行能力（Long-Range Instruction Following）：复杂开发场景通常需要模型整合来自多个来源的“复合指令约束”，包括系统 Prompt、用户 Query、模型记忆、工具 Schema 以及各种规范文件（例如 Agents.md、Claude.md、Skill.md 等）。这些规范严格限定模型行为，一旦在推理过程中某一步未满足要求，可能导致端到端的结果严重下降。
适应上下文管理的能力（Adaptability to Context Management）：在 M2 初版早期发布时，社区对交错思维（Interleaved Thinking）设计并未完全理解。在许多脚手架中，由于设计会丢弃部分历史思考内容，导致模型实际能力表现不符合其原本潜力。MiniMax-M2.1 在建议使用交错思维以释放全部潜力的同时，还设计了相应训练方法，确保即使在各种想象的上下文管理策略下，模型的“智商”仍然在线。
为验证 MiniMax-M2.1 的跨脚手架泛化能力，我们分别在不同脚手架上直接测试 SWE-Bench 性能，并构建更贴近真实使用场景的测试集，观察模型是否满足各种脚手架指令约束。最终我们发现，MiniMax-M2.1 在 mini-swe-agent、Droid 和 Claude Code 等脚手架上均能保持 SWE-Bench 分数在 67 以上。
| Benchmark（基准） | MiniMax-M2.1 | MiniMax-M2 | Claude Sonnet 4.5 | DeepSeek V3.2 |
|---|---|---|---|---|
| SWE-bench Verified（Claude Code） | 74 | 69.2 | 77.2 | 73.1 |
| SWE-bench Verified（Droid） | 71.3 | 68.1 | 72.3 | 67 |
| SWE-bench Verified（mini-swe-agent） | 67 | 61 | 70.6 | 60 |
| OctoCodingBench | 26.1 | 13.3 | 22.8 | 26 |
相比 M2，MiniMax-M2.1 在不同 OOD 脚手架上表现都有显著提升。在 OctoCodingBench 上，M2.1 从 M2 的 13.3 提升至 26.1，展现了更强的脚手架指令服从能力。
2026 TODOs
我们认为编码代理的发展仍然任重道远。因此在 2026 年我们计划探索以下几个方向：
定义开发者体验的奖励信号（Reward Signal for Developer Experience）：目前评估标准主要关注任务最终是否完成，而忽略了过程中用户体验。我们计划探索更丰富的奖励维度，例如代码质量（可读性、模块化、注释完整性）、交互体验（响应延迟、信息透明度、中间结果可解释性）、工程规范（提交信息质量、PR 描述完整性、代码风格一致性）等。尽管自动评估这些指标存在难度，我们正在探索结合静态分析工具、Agent-as-a-Verifier 和人类偏好学习的混合方案，希望使编码代理不仅完成任务，还能像优秀工程师一样输出高质量代码。
提高问题解决效率（Improving Problem-Solving Efficiency）：MiniMax-M2.1 仍存在一些过度探索问题，例如反复读取相同文件或执行冗余测试。我们计划从多个角度优化效率：通过更精确的规划能力减少试错；通过更精确的代码定位减少不必要的文件读取；通过更优内存机制避免重复探索；通过自适应思考深度快速响应简单任务。
强化学习扩展（RL Scaling）：强化学习扩展律在编码代理上仍具有巨大潜力。我们已验证环境数量、训练步骤与模型能力之间存在正相关，但尚未达到收敛。我们将在三个维度继续探索：计算维度（增加并发环境数量和训练迭代次数）、数据维度（构建更大规模、更具多样性的训练任务池）、算法维度（探索更高效探索策略、更稳定训练目标、更优奖励设计方法）。同时我们还在研究如何使 RL 训练过程本身更加高效，包括更好的课程学习设计、更智能的样本重用策略和跨任务知识迁移。
构建代码世界模型与用户行为模拟器（Coding World Model & User Simulator）：如前所述，本代编码代理（M2.1）的训练高度依赖真实环境执行，带来巨大的计算开销和环境构建成本。我们正在研究构建一个可预测代码执行结果的世界模型：给定一段代码和环境状态，该模型即可预测测试是否通过、会产生何种错误信息以及程序将如何运行。这将使我们无需实际执行代码就能进行大规模 rollout 和策略优化。同时，我们还在构建用户行为模拟器，以模拟真实开发者与代理之间的交互模式，包括模糊需求描述、中途需求变更以及对中间结果的反馈，从而在训练阶段使模型适应各种真实场景下的用户行为模式。
超高效数据管道（Extremely Efficient Data Pipeline）：打造能够自动发现、过滤和生成更难、更长程任务的数据管道，以持续提升模型上限。高质量训练数据是编码代理进步的关键瓶颈。我们正在构建自动化数据飞轮：自动从 GitHub 发现高质量 Issues 和 PR；使用模型评估任务难度并进行分层；自动增强模型能轻易解决的任务以提升难度；分析失败案例生成针对性训练数据。理想状态是构建一个“取之不尽”的高质量任务源，使训练数据难度略高于模型当前能力以保持最优学习效率。此外，我们还探索自动生成需要数小时甚至数天才能完成的超长任务，以推动模型在复杂项目理解和长期规划方面的能力边界。
覆盖更多专业场景（More Scenario Coverage）：扩展至更专业领域，例如 GPU 内核开发、编译器开发、智能合约和机器学习等。每个领域都有独特的知识体系、工具链和最佳实践，同时具备真实应用场景和商业价值。我们计划逐步构建这些专业领域的训练环境和评估体系，使编码代理能够处理更专业、更高价值的开发任务。展望更远的未来，我们认为“定义问题 — 定义奖励 — 环境构建 — 模型训练”这一编码代理训练范式可迁移至更多需要复杂推理与执行反馈的场景。
结语
第三百七十篇博文写完，开心！！！！
今天，也是充满希望的一天。
