MiniMax M3 发布：百万上下文、多模态和 Agent 编程能力放到同一个模型里

MiniMax 在 2026 年 6 月 1 日正式发布 MiniMax M3。这个模型的卖点不是单一跑分，而是把三类能力放在同一个旗舰模型里：前沿 Coding 与 Agentic 任务、最高 1M tokens 上下文、原生多模态输入。

这次发布已经可以通过 MiniMax API、Token Plan 和 MiniMax Code 使用。MiniMax 同时表示，模型技术报告和对应权重会在接下来 10 天内发布。因此，对开发者来说，M3 现在是“可先从托管服务测试”的状态；如果你计划私有化部署或微调，还需要等权重、许可证和部署细节真正公开后再做决策。

M3 这次把重点押在长程 Agent 上

MiniMax 对 M3 的定位很明确：它不是只服务普通聊天的模型，而是面向长程 Coding、工具调用、多步推理、文档与视频理解，以及跨应用电脑操作的 Agent 基座。

官方页面列出的核心能力包括：

• 通过 MiniMax Sparse Attention 架构支持最高 1M tokens 上下文，并保证至少 512K tokens 可用。
• 从预训练阶段开始做多模态训练，支持图像、视频等输入。
• 面向代码生成、任务拆解、工具调用和多步执行强化。
• 支持在请求中切换 thinking 开关：复杂推理和长程 Agent 场景可以开启，低延迟对话和补全场景可以关闭。
• API 支持 standard 和 priority 服务层级，优先级通道当前主要通过销售支持开放。

真正值得注意的是能力组合。过去很多开源或开放权重模型会在某一项能力上很强：有的上下文长，有的代码强，有的多模态可用。但小团队做真实 Agent 时，需要的是这些能力同时出现。仓库级代码理解、长文档分析、论文复现、视频内容理解和多工具协作，都会遇到同一个问题：模型不能只看得多，还要能持续规划、调用工具、处理图像或表格，并在长时间执行中保持任务状态。

M3 的发布说明，国内模型厂商正在把“长上下文 + Coding Agent + 多模态”作为旗舰模型的基本规格，而不是拆成几个不同产品线。

官方跑分要看，也要看评测口径

MiniMax 给 M3 列出了大量 Coding、Agent 和多模态评测结果。例如，官方称 M3 在 SWE-Bench Pro、Terminal-Bench、SWE-fficiency、KernelBench Hard、MCP Atlas 等任务上达到前沿水平；在 BrowseComp 上得到 83.5 分，高于其列出的 Opus 4.7 对比结果；在 OmniDocBench 等多模态文档任务上也有靠前表现。

这些结果可以说明 M3 的研发方向，但不适合直接等同于你的项目效果。MiniMax 的评测说明里有不少内部基准、内部基础设施、指定 scaffolding 和多次运行平均值。对小团队更有价值的读法是：M3 明显在“长时间自主执行任务”上投入了训练和评测资源。

发布材料里有两个例子比单个榜单更能解释方向：

这里的重点不是把这些演示照搬到生产环境，而是用它们设计自己的测试集。比如独立开发者可以拿一个真实仓库，让 M3 做跨文件 bug 修复、迁移影响分析、单测补齐或性能优化建议。内容团队可以测试长视频、长报告、含图表 PDF 的摘要和结构化提取。结果比榜单更能说明模型是否适合你的工作流。

API 和 Token Plan 已经开放

M3 已经进入 MiniMax API。官方说明，输入长度在 512K 以内的请求使用标准长上下文价格档，超过 512K 到 1M 的请求会进入更高的超长上下文价格档，主要面向超长文档解析、完整代码仓库理解等高负载场景。

发布日公开价格信息显示，M3 API 在 512K 上下文以内有 7 天限时五折：

MiniMax 还提供 M3 和 M3-highspeed 两个 API 版本，官方表述是结果一致，后者速度更快。API 自动支持缓存，不需要开发者额外配置。

订阅侧，MiniMax Token Plan 也同步升级。官方文档列出的月付档位包括 Plus、Max 和 Ultra：

这些额度对 AI 编程工具用户很有吸引力，但要注意两个细节。第一，Token Plan 是按资源消耗折算的额度池，不是固定调用次数；复杂任务会消耗更多。第二，文本、图像、语音、音乐等支持资源共用一个额度池，不能只按单一文本模型估算实际使用时长。

MiniMax Code 可能是 M3 的主战场

M3 发布的同时，MiniMax Code 也更新为面向 M3 的 Agent 产品。官方描述里，MiniMax Code 可以把大型任务拆成多阶段、并发、动态调整的工作流，并通过 Producer + Verifier 的对抗循环不断产出、反思和修正。

这个方向和 Claude Code、OpenCode 等工具最近的变化很接近：AI 编程工具正在从“让模型补代码”，转向“让一组 Agent 长时间协同推进任务”。M3 的长上下文、多模态和工具调用能力，正好服务这个方向。

对小团队来说，可以先从低风险任务测试 MiniMax Code 或 M3 API：

1. 仓库级阅读：让模型理解项目结构、依赖、入口文件和潜在风险点。
2. 多文件修改：挑选一个范围清楚的 bug 或重构任务，让模型给出计划、补丁和测试建议。
3. 文档与截图混合输入：测试它能否同时读需求文档、界面截图、表格和代码。
4. 长任务复盘：让模型持续跟踪实验日志、错误输出和 commit 变化，观察它是否会重复走弯路。
5. 成本样本：记录输入、输出、缓存命中和重试次数，别只看单价。

如果你现在已经用 Claude Code、Codex CLI、OpenCode、Cline 或 Cursor，M3 最适合先作为候选模型进入评测池，而不是直接替换主力工作流。尤其是自动写文件、运行命令、访问私有仓库时，仍然需要权限隔离、测试门禁和人工 review。

开源权重还没有落地

MiniMax 在发布页和模型页都提到，M3 将在 Hugging Face 和 GitHub 上开放，支持私有集群部署和微调。但截至 2026 年 6 月 1 日发布时，官方措辞仍是即将发布或未来 10 天内发布技术报告和权重。

这意味着几个关键信息还不能提前下结论：

• 权重文件是否已经可下载。
• 许可证是否允许商业使用、二次分发和微调后的商用。
• 私有部署的显存、推理框架、量化方案和吞吐指标。
• M3-highspeed 与标准 M3 在成本、延迟和并发上的实际差异。
• 1M 上下文在你的任务里是否稳定、是否会显著增加延迟。

开发者可以现在做 API 和产品层测试，但不要把“将开源”直接写进采购、私有化部署或客户交付计划里。等权重、许可证和技术报告落地后，再判断它是否适合作为本地 Agent 基座。

小团队该怎么判断要不要试

M3 值得关注的原因很简单：它把长上下文、多模态和 Agent 编程能力捆在一起，并且给出了相对激进的 Token Plan 额度。对独立开发者和小团队来说，这可能降低几类实验的门槛：

• 用一个模型处理长文档、代码仓库和视觉材料，减少多模型路由复杂度。
• 把高成本的仓库级分析、代码审查和长程任务拆解重新拿出来测试。
• 在 MiniMax Code 或其他 Agent 工具里评估国产模型的稳定性。
• 为未来本地部署或私有化微调提前准备任务集和验收标准。

但它还不是一个可以只凭发布页就押注的模型。短期内最实际的做法，是用自己的任务跑一个小型评测：

MiniMax M3 的发布不是“又一个模型上新”这么简单。它把模型公司的竞争焦点推向更具体的工程问题：谁能让 Agent 在更长上下文、更复杂材料和更长执行周期里稳定工作。对小团队来说，真正的机会不在于追逐每一个榜单分数，而是把这些新模型放进真实任务里，找出哪一段工作流终于可以被可靠地自动化。