MiniMax M3：MiniMax 官方 M3 长程 Agent 工作流：论文复现与 Producer/Verifier 自校验

一句话结论

M3 的长任务应把论文、代码、日志和可执行验证一起交给 Agent，并让它按“计划—执行—反馈—再计划”循环推进；MiniMax Code 的 Producer + Verifier 结构可作为多 Agent 自校验模板。

适用场景

• 适合的任务：论文复现、CUDA/内核优化、跨文件工程迭代、长时间实验和需要连续工具反馈的 Agent 任务。

• 不适合的任务：没有可执行测试或反馈信号的开放式创作；需要低延迟即时回答的简单任务。

• 适用的模型版本：MiniMax M3；产品侧为 MiniMax Code + M3。

• 适用的客户端、Agent 或 API：MiniMax Code、基于 OpenCode/Pi 的 Agent harness、可运行命令和测试的自建工作流。

• 推荐的推理档位和参数：复杂任务开启 thinking；短对话或代码补全可关闭 thinking 以换取速度。其余参数按官方默认。

可直接使用的内容

Task: [明确研究/工程目标与成功指标]
Inputs: [论文、代码、数据、日志、硬件和限制]
Plan: 先拆成可验证阶段，说明每阶段的产物、命令和停止条件。
Execution: 每次修改后运行最小验证；记录结果、失败原因和下一步假设。
Iteration: 根据测试/基准反馈重新排序计划，不要在没有新证据时重复相同尝试。
Verification: 独立复核实现、结果和图表；列出未复现的结论与剩余风险。
Deliverable: 提交变更、实验结果、可复现命令、图表和结论边界。

多 Agent 版本：

Producer：提出实现方案并运行实验，输出变更与证据。
Verifier：独立检查需求、测试、数据和结果，指出失败或过拟合。
Coordinator：根据 Verifier 反馈决定继续、回滚、改计划或结束。

测试/工作流步骤

1. 将任务资料放入可访问目录，先让模型列出目标、约束和验收指标。

2. 每个阶段只保留一个可验证目标；让模型执行命令并把输出写入日志。

3. 用基准反馈驱动下一轮，不允许以“看起来更快”替代测试结果。

4. 在最终交付前运行独立验证，核对代码、图表、实验配置和原始日志。

5. 对长任务设置人工接管点、成本上限和停止条件，避免无反馈循环。

原始证据与数据

• MiniMax 官方描述：M3 自主复现一篇 ICLR 论文近 12 小时，产出 18 个 commit 和 23 张实验图，完成核心实验。

• CUDA 优化案例中，约 24 小时完成 147 次 benchmark 提交和 1,959 次工具调用；FP8 Hopper 峰值利用率从 7.6% 提升到 71.3%，相对初版 9.4× 加速。

• MiniMax Code 的 Agent Team 采用 Producer + Verifier 对抗式循环，持续生成、反思和纠错。

适用边界

• 官方没有公开完整 system prompt、硬件配置、所有中间结果和失败样本；这里的模板是基于公开工作流结构的可复用转写，不是原始提示词。

• 结果依赖明确反馈信号、工具权限和 harness；没有测试闭环时不应期待同样的长时程表现。

• “自主运行若干小时”不是质量保证，仍需安全隔离、成本上限和人工验收。

来源摘录或观察（仅做合规短引）

• 官方把下一代 Agent 编码的重点从单次代码生成扩展到“long-term collaboration capability”。