看到社区深入探索我们的新款 MiniMax M2,并纷纷称赞其在复杂智能体任务中展现的出色技能,这真是太棒了。这尤其让我感到兴奋,因为我的工作重点正是其后期训练中的智能体对齐部分。在这篇文章中,我想分享我们在该过程中获得的一些关键见解和经验教训。
真正的智能体对齐问题:基准测试还是现实?
如果你曾与大语言模型智能体合作过,你一定体会过这种痛苦:同一个模型在一个框架中可能表现得非常出色,在另一个框架中却毫无用处。一个智能体可能在工具使用排行榜上独占鳌头,但在一个简单的现实任务中却彻底失败。这种基准测试性能与实际可用性之间的差距,是该领域最大的挑战之一。
在设计 M2 时,我们知道必须直面这个问题。这引导我们确立了两个核心且有时相互冲突的目标:
- 在开源基准测试中表现出色。基准测试对于衡量“纯粹”能力至关重要。例如,像 BrowseComp 这样的基准测试,考验的是复杂的搜索技能。虽然用户很少会提出像“找到那篇论文,其中第 n 位作者名字的第三个字母是‘x’”这样刻意的问题,但能够解决它的模型证明了其具备扎实的基础能力。
- 稳健地泛化到现实世界。这是更困难、也更重要的一点。一个优秀的智能体必须能在不熟悉的工具、集成开发环境/命令行界面、智能体框架以及用户设置中可靠地执行任务。它不能只会一招鲜,而需要具备泛化能力。
那么,我们该与谁对齐?答案是两者都要。我们通过基准测试对齐来构建技能,但最终必须通过确保这些技能在任何地方都能发挥作用来与用户对齐。
虽然攻克基准测试的方法是一个值得另文详述的深刻话题,但我想重点谈谈第二个更棘手的目标:我们如何训练一个能在真实环境中应用的智能体?
交错式思维的必要性
在项目早期,我们遇到了一个令人沮丧的瓶颈。智能体的性能不稳定,我们很难诊断出原因。经过多次讨论,特别是与何俊贤教授和陈文虎教授的交流,我们得出了第一个重要结论:智能体需要交错式思维。
这意味着智能体的内心独白——即它的“思考”——可以在任务过程中的任何时刻发生,而不像标准推理模型那样仅在开始时进行一次。这种设计至关重要,原因有二:
- 在长周期任务中保持专注。复杂的智能体任务拥有极长的上下文。仅在开始时进行一次思考过程,不足以维持对指令的遵循和连贯性。
- 适应外部扰动。这是关键区别所在。智能体任务会引入来自外部世界(即工具输出)持续且不可预测的扰动。模型必须足够稳健,以处理这些扰动、诊断错误并提取有用信息。“思考”过程使模型能够不断重新评估并适应来自环境的新信息。
这一原则成为 M2 高效性的基石。
M2 用户进阶提示:由于 M2 依赖交错式思考,其上下文就是它的记忆。为获得最佳性能,你必须保留完整的会话历史,包括思考步骤。我们注意到,社区中许多关于性能差距的反馈,都源于意外丢弃了这一关键上下文——这在较简单的推理模型中是一种常见做法。
真正的泛化关乎扰动
我们最初的理论很简单:工具扩展就是智能体泛化。
我们从最少的工具集(一个 Python 解释器、搜索引擎、一个浏览器)开始,构建工具调用能力的基线。路线图很清晰:扩展工具的数量和种类,智能体泛化到未见工具的能力自然会随之而来。
起初,这确实有效。我们的基准测试分数攀升到了可观的水平。但当我们深入研究后,意识到我们解决的是错误的问题。模型在测试中表现出色,但如果我们对环境稍作改变——比如换用不同的脚手架框架——它的性能就会骤降。我们距离“实际可用”模型的目标仍然很远。
这引出了我们第二个、更深刻的领悟:智能体泛化不仅仅是适应新工具,更是适应模型整个操作空间中的扰动。
这听起来有些抽象,我们来拆解一下。想想在一个智能体任务中,所有可能发生变化的部分:
- 工具信息与可用工具集。
- 定义智能体角色和规则的系统提示词。
- 用户提示词及其具体目标。
- 环境本身(文件、代码库、API)。
- 每一步返回的工具响应。我们过去“工具扩展”的方法只解决了第一项,忽略了流程中其他所有部分的扰动。基于这一新认识,我们的团队构建了一个专为全轨迹泛化设计的综合数据管道。该管道生成的数据能训练模型在每一步都稳定应对扰动。结果令人非常振奋。在内部测试中,我们向 M2 抛出了晦涩的“冷启动”脚手架——那些我们几乎未曾考虑过的框架——其表现超出了我们的预期。它的工具调用能力和指令遵循能力都实现了出色的泛化。
下一步是什么?
我们在 M2 上的工作让我们对智能体、泛化和数据有了极其深刻的理解,但它引发的问题比解答的更多。我们的许多想法仍停留在白板上。在接下来的几个月里,我们将更深入地探索这些前沿领域,并迫不及待地想为您带来下一代强大且真正实用的模型。
参与进来
- 使用模型:我们真诚希望您能对 M2 进行测试。您可以通过我们的官方渠道访问它,或找到开源版本进行自己的研究。
- 加入我们:如果这类挑战让您感到兴奋,我们正在招聘。我们一直在寻找充满热情的人加入我们,共同完成构建 AGI 的使命。请将您的简历发送给我们!
本文中提到的模型 1
It's been fantastic to see the community dive into our new MiniMax M2, with many highlighting its impressive skills in complex agentic tasks. This is particularly exciting for me, as my work was centered on the agent alignment part of its post-training. In this post, I'd like to share some of the key insights and lessons we learned during that process.
The Real Agent Alignment Problem: Benchmarks or Reality?
If you've worked with LLM Agents, you've felt this pain: the same model can feel brilliant in one framework and useless in another. An agent might crush a tool-use leaderboard but fail spectacularly at a simple, real-world task. This gap between benchmark performance and practical usability is one of the biggest challenges in the field.
When we designed M2, we knew we had to tackle this problem head-on. This led us to two core, and sometimes conflicting, objectives:
- Excel on Open-Source Benchmarks. Benchmarks are essential for measuring "pure" capabilities. A benchmark like BrowseComp, for instance, tests for sophisticated search skills. While users will rarely ask a question as contrived as, "Find the paper where the third letter of the nth author's name is 'x'," a model that can solve it proves it has strong foundational abilities.
- Generalize Robustly to the Real World. This is the harder, more important part. A great agent must perform reliably across unfamiliar tools, IDEs/CLIs, agent scaffolding, and user setups. It can't be a one-trick pony; it needs to generalize.
So, who do we align with? The answer is both. We align with benchmarks to build skill, but we must ultimately align with the user by ensuring those skills work everywhere.
While the methods for acing benchmarks are a deep topic for another day, I want to focus on that second, trickier objective: How do we train an agent for the wild?
The Need for Interleaved Thinking
Early in the project, we hit a frustrating wall. Agent performance was inconsistent, and we struggled to diagnose why. After many discussions, especially with Professor @Junxian He and @Wenhu Chen, we arrived at our first major conclusion: Agents require Interleaved Thinking.
This means that an agent's internal monologue—its "thinking"—can and should happen at any point during a task, not just once at the beginning like a standard reasoning model. This design is critical for two reasons:
- Maintaining Focus on Long-Horizon Tasks. Complex agent tasks have extremely long contexts. A single thought process at the start isn't enough to maintain instruction-following and coherence.
- Adapting to External Perturbations. This is the crucial difference. Agent tasks introduce constant, unpredictable perturbations from the outside world (i.e., tool outputs). The model must be robust enough to handle these perturbations, diagnose errors, and extract useful information. The "thinking" process allows the model to constantly re-evaluate and adapt to new information from the environment.
This principle became a cornerstone of M2's effectiveness.
Pro Tip for M2 Users: Because M2 relies on Interleaved Thinking, its context is its memory. For best performance, you must retain the full session history, including the thinking steps. We've noticed that much of the community feedback about performance gaps stems from accidentally discarding this vital context, which is a common practice with simpler reasoning models.
True Generalization is About Perturbation
Our initial theory was simple: tool scaling is agent generalization.
We started with a minimal set of tools (a Python interpreter, search engine, a browser) to build a baseline of tool-calling capability. The roadmap was clear: scale up the number and variety of tools, and the agent's ability to generalize to unseen tools would naturally follow.
At first, this worked. Our benchmark scores climbed to respectable levels. But as we dug deeper, we realized we were solving the wrong problem. The model aced the tests, but if we changed the environment even slightly—like swapping to a different scaffolding framework—its performance would plummet. We were still far from our goal of a "practically useful" model.
This led to our second, more profound realization: Agent generalization is not just about adapting to new tools; it's about adapting to perturbations across the model's entire operational space.
This sounds abstract, so let's break it down. Think about everything that can change in a single agent task:
- The Tool Info and available toolset.
- The System Prompt defining the agent's persona and rules.
- The User Prompt and its specific goal.
- The Environment itself (files, codebases, APIs).
- The Tool Responses returned at each step. Our old "tool scaling" approach only addressed the first item. It ignored perturbations in all the other parts of the process. Armed with this new understanding, our team built a comprehensive data pipeline designed for full-trajectory generalization. The data it generates trains the model to be stable against perturbations at every step. The results have been incredibly encouraging. In internal tests, we threw obscure, "cold-start" scaffolding at M2—frameworks we'd barely considered—and its performance exceeded our expectations. Both its tool-calling and instruction-following abilities generalized beautifully.
What's Next?
Our work on M2 taught us an immense amount about agents, generalization, and data, but it has opened up more questions than it answered. Many of our ideas are still on the whiteboard. In the coming months, we will be exploring these frontiers even more deeply, and we can't wait to bring you the next generation of powerful and genuinely useful models.
Getting Involved
- Use the Model: We sincerely hope you'll put M2 to the test. You can access it through our official channels or find the open-sourced version to conduct your own research.
- Join Our Team: If these are the kinds of challenges that excite you, we're hiring. We are always looking for passionate people to join us in the mission to build AGI. Please send us your resume!