在我最近的模型评估中，一个问题反复出现： 当任务涉及多文件编辑、反复调试和工具使用（而不仅仅是单次回答）时，编码代理还能保持快速、可靠和经济实惠吗？ MiniMax M2.5 是少数几款配备足够配件的产品之一。 端到端效率和定价详情 以具体的方式检验这个问题。
我为什么关注M2.5
我不太关注“最佳基准测试分数”，而更关注模型能否完成实际工作流程：
- 端到端交付范围界定 → 实施 → 验证 → 交付成果
- 运营效率工具调用迭代、令牌使用和运行时稳定性
- 代理人 经济学定价模型是否支持长期运行的代理和重复迭代
MiniMax M2.5之所以有趣，是因为它旨在优化 能力、效率和成本 在同一版本中发布——这对做出部署决策的工程团队来说是一个重要的组合。
M2.5 的设计用途
基于 官方材料, MiniMax M2.5 针对实际生产工作负载，主要分为三个方向：
- 软件工程（智能编码）：以 SWE-Bench 验证、Multi-SWE-Bench 为代表，并强调在不同测试平台上的稳定性能。
- 用于交互式搜索和工具包括 BrowseComp、Wide Search 和 MiniMax 的内部 RISE 基准测试，旨在反映对专业网络资源的更深入探索。
- 提高办公效率：专注于 Word、PowerPoint 和 Excel 中的交付导向型任务，并由评估框架 (GDPval-MM) 提供支持，该框架考虑输出质量、代理执行轨迹和令牌成本。
MiniMax还会披露一些代表性结果，例如 SWE-Bench 验证 80.2%, 多SWE测试台 51.3%， 和 浏览Comp 76.3%.
MiniMax M2.5 对比 M2.1 和 Claude Opus 4.6：我的对比评测
M2.5 vs M2.1 vs Claude Opus 4.6（关键指标表）
| 方面 | M2.5 | M2.1 | 克劳德作品 4.6 |
| SWE-Bench 验证 | 80.20% | 74.0% | 81.42% （人类学报告） ~78-80%（公开平均值） |
| 每个软件工程任务的平均端到端时间 | 22.8分钟 | 31.3分钟 | 22.9分钟 |
| 每个SWE任务的令牌数（平均值） | 352万 | 372万 | — （由于篇幅较长，可能超过400万字） |
| 搜索/工具迭代与上一代相比 | 迭代次数减少了约 20% 次（据报道） | 基线 | — |
| 交叉式 SWE-Bench（Droid） | 79.7 | 71.3 | 78.9 |
| 交叉线束 SWE-Bench（OpenCode） | 76.1 | 72.0 | 75.9 |
| 吞吐量选项 | ~50 个代币/秒（标准） ~100 个代币/秒（闪电网络） | 约 57 个代币/秒 | 约 67-77 个代币/秒 |
| 定价（每百万个输入代币） | $0.3（标准版和 Lightning 版） | $0.3 | $5.0 |
| 定价（每百万个代币） | $1.2（标准） $2.4（闪电） | $1.2 | $25.0 |
| 每小时直觉（持续输出） | ~$0.3/小时 @ 50 吨/秒 ~$1/小时 @ 100 吨/秒 | ~$0.3/小时 @ 57 吨/秒 | ~$6.50/小时 @ 70 吨/秒 |
笔记：
- “—”表示此处总结的材料中未提供该值。
- 基准测试结果会因测试框架、工具设置、提示信息和报告规范的不同而有所差异，因此我将它们视为…… 范围指示器并非绝对排名。
M2.5 对比 M2.1：端到端速度更快、令牌使用量更低、搜索迭代次数更少
官方对比报告以便于工程师理解的方式呈现。我主要关注以下三个指标：
- 端到端运行时平均软件工程任务时间下降 31.3分钟（M2.1） 到 22.8 分钟（M2.5）被描述为 37% 改进.
- 每个任务的代币每个任务的令牌使用量减少 372万 到 352万.
- 搜索/工具迭代效率在 BrowseComp、Wide Search 和 RISE 测试中，MiniMax 报告称，在迭代次数较少的情况下，结果更好，迭代成本约为 20% 下部 比 M2.1 更甚。
对我而言，这些改进比单一的基准分数更重要，因为它们直接决定了 代理吞吐量 和 可持续运营成本.
M2.5 与 Claude Opus 4.6：编码范围相似，评估环境至关重要
比较时 M2.5 和 克劳德作品 4.6我将分数视为 范围 而不是绝对排名，因为工具配置、提示和报告约定可能有所不同。
- 人择 注意到 Opus 4.6 的 SWE-bench 已验证 结果为平均值 25项试验并提到，在及时调整下，观测值更高（81.42%）。
- MiniMax报告 SWE-Bench 验证 80.2% 为了 MiniMax M2.5.
从数值上看，两者在编码代理基准测试中似乎处于相近的竞争区间。但从工程角度来看，我更关注的是它们在实际项目结构（包括前端和后端、不同的框架以及第三方集成）中的稳定性，而不是单一的指标数值。
M2.5 如何改变我的工作流程（实战笔记）
速度和工作流程风格
整合后 MiniMax M2.5 在编码代理工具链中，有两点尤为突出：
- MiniMax M2.5 的速度显著提升了短任务迭代能力。许多实际任务都遵循“小幅修改 → 运行 → 调整”的循环。如果每次循环都引入长时间的等待，上下文切换的成本就会很高。MiniMax 明确地将“更快的端到端速度”和“更低的令牌使用量”作为其核心目标。
- MiniMax M2.5 倾向于在实现之前编写规范。对于涉及多个文件和多个模块的任务，我更倾向于在编写代码之前，先明确定义范围边界、模块关系和验收标准。这样便于代码执行的审计和标准化，而且 M2.5 在这种架构下表现良好。
这些要点不容忽视
即使整体性能表现出色，我仍然将以下几点视为需要工作流程防护措施的限制因素：
- 调试策略并非总是主动的。对于难以定位的错误，模型可能会反复修改实现，而不会自动切换到单元测试、日志记录或最小复现步骤。我经常需要明确指示：“添加日志/编写测试/缩小故障路径”。
- 外部检索和第三方集成可能不可靠。在集成某些外部服务时，该模型可能会生成错误的集成步骤。我更倾向于使用官方文档示例来约束输入，而不是依赖“检索组装”的代码。
- 代码和文档同步并非始终默认启用。当一项任务需要“更新代码并更新文档/技能标记”时，我会使用明确的检查清单来降低只更新代码的可能性。
这些限制并非 M2.5 独有；它们是我应用于大多数编码代理工作流程的护栏。
现阶段，我的立场 MiniMax M2.5 作为一个 面向工程的智能体生产力模型它不仅提供基准测试结果，还披露了端到端运行时间、代币消耗、迭代效率和定价结构，使我能够使用一套一致的指标来评估实际部署成本。
一些用户可能会质疑，在编写代码之前生成规范是否会增加代币成本，从而削弱“低成本”的说法。我的实际结论是：
- 是的，编写规范会增加一些输出标记。
- 在许多实际工作流程中，这种成本会被更少的返工循环和更少的来回迭代所抵消。尤其适用于多文件、跨模块或调试密集型任务。
- 只要规范不太长，不重复实现细节，开销通常是可控的。
以下是一些减少 Spec Token 开销的实用技巧：
- 对于小型任务明确要求“无需规范；提供代码差异和测试步骤”。
- 中大型任务将规范限制为 X 行 / X 个项目符号 （例如，10-15），仅关注 结构和验收标准而不是实现细节。
- 在代理工具链中：将规范视为 唯一真理来源当需求发生变化时，首先更新相关的规范章节，然后再进行编码和验证。这样可以减少重复解释和因重新阐述上下文而造成的代码浪费。
