MiniMax M3.1 Flash发布：Agent执行力、速度与成本如何验证？

AI 大模型的竞争，正在从单纯比较生成能力，逐步延伸到完整任务的执行效率。对于开发者来说，模型能否生成一段正确的代码固然重要，但当 AI 开始参与软件开发、跨系统操作和企业业务自动化时，真正影响使用体验的，往往是它能否持续推进任务、正确调用工具，并在遇到错误后找到解决办法。

2026 年 10 月 19 日，MiniMax 正式发布新一代 M3.1 Flash，将重点放在 Agent 任务、软件工程、Computer Use 和网络安全等方向。该公司称，新模型的线上推理速度较前代提升近 3 倍，Agent 类任务的综合使用成本降低约 70%。

此次发布还有一个值得关注的背景。MiniMax 确认，此前以匿名身份运行、累计处理超过 200 万亿 Token 的 Space Bunny，正是 M3.1 Flash 的早期版本。这个信息让新品发布不再只是一次常规的模型迭代，也为观察模型在实际调用环境中的表现提供了一个切入点。

不过，累计处理量大并不等于模型在所有任务中都处于领先位置，官方公布的速度和成本改善也不能直接套用到每一个应用。对于准备使用新模型的开发者来说，更重要的问题是：M3.1 Flash 究竟强化了哪些能力？这些变化能否转化为更高的任务完成率，以及更低的实际开发成本？

一、Space Bunny 的身份揭晓，为什么值得关注？

在正式发布之前，Space Bunny 已经以匿名模型的形式在开发者使用环境中出现。10 月 19 日，MiniMax 在官方公告中确认了它与 M3.1 Flash 的关系，并披露该早期版本累计处理了超过 200 万亿 Token。

这一经历值得注意，但需要区分两个概念：模型的线上使用规模，与模型的客观能力表现。

大规模调用能够说明模型经历了较多真实请求，但不能单独证明其代码生成质量、工具调用准确率或任务成功率一定更高。真实使用环境虽然比固定测试集复杂，却也会受到用户任务分布、调用平台、上下文长度和工具配置等因素影响。

对于 Agent 模型而言，线上运行经验的价值主要体现在问题发现与持续改进上。一个需要连续执行多步骤任务的模型，可能遇到错误参数、工具返回异常、上下文信息遗漏和重复执行等问题。如果模型能够在实际运行中不断改善这些环节，就有机会提升整个工作流的效率。

但早期版本与正式版本之间仍然可能存在差异。开发者不能仅凭匿名运行期间的表现，就推断正式版本在所有任务中都能达到同样结果。真正有参考价值的做法，是结合官方基准测试、可复现的实际任务和自身业务数据进行判断。

二、为什么 Flash 模型开始受到 Agent 开发者重视？

Flash 通常用于描述强调推理效率、响应速度或成本控制的模型产品。不过，不同厂商对这一名称的定义并不完全一致，不能仅凭 Flash 这个标签判断模型能力。

在普通对话中，模型接收用户输入并生成回答，任务链路相对简单。但在 Agent 场景中，回答只是执行过程的一部分。

以自动编程 Agent 为例，开发者要求它修复一个登录流程中的 Bug。模型需要先理解现有项目结构，找到相关文件，分析问题原因，修改代码，再运行测试。如果测试失败，还要判断是修改本身存在问题，还是环境配置或测试数据导致了异常。

这个过程涉及多轮模型调用和工具交互。模型如果无法正确理解任务，或者在测试失败后反复执行相同操作，就可能增加开发时间和 API 费用。即使单次生成速度很快，最终完成任务的时间仍然可能较长。

因此，开发者真正关心的指标不只是每秒生成多少 Token，还包括工具调用准确率、任务完成率、平均执行轮数和失败恢复能力。

这也是效率型模型受到关注的原因。对于大量重复、结构相对明确的任务，如果模型能够在满足质量要求的前提下减少无效调用，就有机会降低系统的整体运行成本。

不过，速度提升不等于所有任务都会按相同比例提速。复杂代码修改可能需要更充分的推理，外部工具的响应时间也可能成为瓶颈。模型的推理速度只是完整执行链路中的一个因素，不能直接等同于 Agent 的端到端效率。

三、M3.1 Flash 的能力有哪些变化？

根据 MiniMax 官方于 10 月 19 日发布的数据，M3.1 Flash 在编程、企业自动化、电脑操作和网络安全等方面取得了多项基准成绩。需要说明的是，以下数据均为官方公布的测试结果，尚不能视为所有独立测试环境下的统一结论。

表格

这些指标分别对应不同能力，不能直接合并为一个综合排名。例如，DeepSWE v1.1 侧重复杂软件工程任务，OSWorld V2 关注计算机操作，而 CyberGym 则用于评估网络安全相关能力。它们的任务设置、评分方式和难度不同，不能仅凭数字大小判断哪个方向更强。

在编程场景中，M3.1 Flash 的 DeepSWE v1.1 成绩为 73.7%。这类任务要求模型理解代码、开发功能、修复问题，并通过测试验证工作成果。相比只考察代码片段生成的测试，这种任务更接近真实软件开发中的连续执行过程。

企业自动化方面，MiniMax 表示，模型在 AutomationBench-AA 中处于领先表现区间，并在 BankerToolBench 中取得 76.2 分。这类能力与跨系统工作流有关，例如整理业务数据、核对不同文件中的信息，以及通过连续工具调用完成任务。

Computer Use 则是另一个值得关注的方向。模型需要理解计算机环境，并执行跨应用操作，而不是只提供操作建议。M3.1 Flash 在 OSWorld V2 中取得 61.7 分，在 ALE 中取得 29.6 分。MiniMax 称其在这两项测试中位居中国模型之首，但这一结论应当限定在官方采用的评测口径内。

网络安全方面，官方公布的 CyberGym 成绩为 82%。不过，基准测试成绩不能直接证明模型能够独立承担生产环境中的安全审计或漏洞处置。实际使用仍然需要专业人员复核，并通过隔离环境验证模型生成的操作和修复建议。

整体来看，这些成绩表明，MiniMax 希望 M3.1 Flash 覆盖的不只是快速生成文本，而是包含规划、工具使用和结果验证的完整任务流程。其实际价值仍需要开发者结合自己的项目进行测试。

四、推理速度接近提升 3 倍，实际开发效率会怎样变化？

MiniMax 官方称，M3.1 Flash 的线上推理速度较前代提升近 3 倍，日常使用场景下输出速度可达到 200+ TPS，中位数速度（P50）稳定达到 170+ TPS。

TPS 是 Tokens Per Second 的缩写，表示每秒生成的 Token 数量。P50 则是中位数指标，意味着一半被统计的观测值不高于该数值，另一半不低于该数值。它与平均速度并不是同一概念。

高吞吐量对于代码生成、批量文本处理和高频 Agent 调用有一定价值。模型可以更快生成中间结果，减少某些任务中的等待时间。不过，实际体验还受到首 Token 延迟、输入上下文长度、服务端负载、并发情况和工具执行时间的影响。

例如，Agent 在修改代码之前，需要先调用终端读取文件。即使模型能够以较高速度生成 Token，终端操作本身仍然需要时间。如果工作流需要反复调用多个工具，最终任务耗时就不仅取决于模型的输出速度。

因此，评估 M3.1 Flash 时，应当同时记录首 Token 延迟、整体生成耗时、工具执行时间和最终任务完成时间。只有将这些指标结合起来，才能判断模型的速度优势是否真正转化为开发效率。

此外，模型生成得更快，并不意味着结果一定更准确。如果输出速度提升，却导致开发者需要花更多时间检查和修正结果，整体效率未必会提高。对于生产环境，速度、质量和稳定性应当一起评估。

五、API 价格降低之后，开发者还需要关注什么？

根据 MiniMax 官方公布的价格，M3.1 Flash 的 API 单价为每百万输入 Token 0.15 美元、每百万输出 Token 0.60 美元、每百万缓存读取 Token 0.015 美元。官方同时表示，Agent 类任务的综合使用成本较前代降低约 70%。

这组价格对高频调用的应用具有参考意义，但不能将其理解为所有项目的账单都会降低 70%。官方所说的综合成本下降，与具体任务、用量分布和前代模型的比较口径有关。

假设一个 Agent 每次任务消耗 10 万输入 Token 和 1 万输出 Token，并且暂时不考虑缓存命中，那么按官方单价计算：

表格

如果每天执行 1,000 次这样的任务，按 30 天计算，模型费用约为 630 美元。这个结果是基于固定 Token 用量的估算，不包含外部工具、存储、运行环境和人工审核费用，也不代表实际 Agent 每次都会消耗相同数量的 Token。

对于复杂任务，真正影响账单的因素通常不只有单价。模型可能多次读取上下文、生成中间结果，或者在工具执行失败后重新尝试。假如任务需要更多调用轮数，即使单次费用较低，总支出也可能超出预期。

因此，更合理的指标是平均每个成功任务的成本。开发者可以记录任务调用次数、输入与输出 Token、缓存命中率、失败重试次数和最终验收结果，再判断模型是否真正提高了单位预算的产出。

缓存机制同样值得关注。对于反复使用固定系统提示词或项目说明的应用，缓存读取可能降低输入成本。但缓存能否命中，取决于请求内容和具体服务规则，不能简单假设所有重复文本都会自动获得折扣。

六、如何验证 M3.1 Flash 是否适合自己的项目？

对于刚发布的模型，开发者不必立即迁移所有现有工作负载。更稳妥的方式，是选取一组具有代表性的真实任务，与当前使用的模型进行对照测试。

如果主要用途是编程，可以选择真实代码仓库中的功能开发、Bug 修复和自动化测试任务；如果主要用途是 Computer Use，可以测试网页导航、表单填写和跨页面信息核对；如果目标是企业自动化，则应当检查模型能否正确调用工具、保持任务状态，并在执行失败后采取合理的恢复措施。

测试时应尽量固定任务输入、工具权限和成功标准，同时记录执行时间、Token 用量、工具调用次数和最终结果。复杂任务最好重复运行多次，以减少单次成功或失败带来的偶然性。

对于需要接入多种模型的开发团队，还可以考虑通过统一的 API 接入层管理模型调用、请求日志和费用统计。KoalaAPI 是一种可供评估的 API 中转站方案，可用于考察多模型接入与调用管理需求。实际使用前，应确认平台当前是否支持 M3.1 Flash、接口参数是否符合项目要求，以及实际价格和服务规则。统一接入并不自动意味着更低成本，仍然需要通过真实请求进行验证。

无论采用哪种接入方式，都建议保留独立的验收流程。代码修改需要通过测试，数据提取需要核对字段，跨系统操作需要检查最终状态。模型生成了结果，不代表任务已经成功完成。

结语：国产 Flash 模型的竞争，正在进入任务效率阶段

Space Bunny 的身份揭晓，为 MiniMax M3.1 Flash 的发布增加了一个值得观察的背景。相比单纯推出一个新版本，这次更新更值得讨论的地方，是国产 Flash 模型正在将编程、Agent 执行、推理速度和调用成本放到同一个产品目标中。

官方公布的基准成绩和价格数据，为开发者提供了初步判断依据。但真实项目中的效果仍然取决于任务类型、工具环境、上下文管理和验收标准。模型在某项基准测试中表现良好，不意味着它一定适合每一种业务工作流。

对于准备接入 M3.1 Flash 的团队，更有价值的做法是先建立自己的测试集，再对比任务完成率、执行时间、Token 消耗和人工干预次数。只有这些指标共同改善，模型的速度与价格优势才能真正转化为生产效率。

随着国产大模型持续迭代，未来的竞争不仅是每百万 Token 的价格竞争，也将是完成同一项有效任务需要多少时间、多少调用，以及多少人工修正的竞争。

了解更多：https://koalaapi.com