原文：MiniMax M3.1 Flash: Redefining Agent Performance and Cost · MiniMax · 2026-10-19
发布重点是长流程能力与使用成本
M3.1 Flash 把复杂业务工作流、编程、Computer Use 和网络安全放在同一次发布中。官方称匿名运行的 Space Bunny 是其早期版本，并称已处理超过 200 万亿 token。这可以说明厂商描述的使用规模，却不能替代可靠性、任务成功率或特定业务场景的评估。
最值得关注的变化是：厂商试图以更低单价支撑多步 Agent 执行，而不是只展示一次问答能力。长流程会反复输入历史、读取工具结果、生成中间动作，单次模型价格的小变化可能累积成明显支出差异；反过来，更多重试、更长轨迹也会吞掉价格优势。判断发布价值，必须把单价、任务行为和成功质量连起来。
公告公开了什么机制
对推理效率，官方给出的机制说明是更激进的稀疏性，并报告在线推理接近三倍速度、日常输出可达 200+ TPS、P50 达 170+ TPS。文章没有披露足以重建实现的专家数量、激活比例、训练流程或服务调度细节，也没有给出这些速度对应的硬件、上下文长度、并发和请求分布。
因此能够确认的是厂商提出的机制方向与服务侧观察，不能据此补写一套未经公开的 MoE 架构。稀疏性如何减少每 token 计算、又是否引入通信和路由开销，是一般工程问题；在 M3.1 Flash 上各因素的份额仍无法从该公告量化。原文没有适合的架构图，下图保留官方评测表及完整条件说明。
先看红框的模型列，再逐项读下方 harness、上下文和数据集脚注；不同列的评测来源并不完全一致，空白不是零分。
分数体现不同任务，不宜混成一个能力值
官方报告 DeepSWE v1.1 为 73.7%，BankerToolBench 为 76.2，OSWorld 2.0 为 61.7，Agents’ Last Exam（ALE）为 29.6。它们分别涉及软件任务、工具工作流、计算机操作和复杂专业任务，分数不能相加或直接比较难度。官方正文把 CyberGym 写作 82%，配图为 82.2；这里保留这处精度差异，不擅自视为两个结果。
配图脚注提供了重要条件。DeepSWE 使用 mini-SWE-agent 2.4.5、最大上下文 512K；BankerToolBench 使用 OpenCode 1.17.18，MiniMax-M2.7 作 judge；CyberGym 使用 Claude Code 2.1.263、最大上下文 1M。AutomationBench v1.0.6 采用 600 个公开任务。因而这些成绩反映模型与各自 harness 的组合，不能假定仅替换模型后就保持原分数。
ALE 表格只纳入官方 Overall 全集结果，空白不表示零分；OSWorld 使用推荐的 0808 Full Release，其他模型主要取发布时最高成绩，DS-V4.1 则来自内部复现。这些说明让表格更可读，也提醒我们它不是统一 harness、统一预算、同日重跑所有模型的受控比较。
单价下降如何转化为任务成本
公告给出的每百万 token 单价是：普通输入 0.15 美元、输出 0.60 美元、缓存命中输入 0.015 美元，并称 Agent 任务总体使用成本比前代低 70%。后一比例没有完整工作负载和分母，不能当成每个用户账单的保证。
可以先做一个明确标注的算术示例。假设一次任务有 100 万未缓存输入、20 万输出，再加 200 万缓存命中输入，按公告价计算，模型 token 费用为 0.15 + 0.12 + 0.03 = 0.30 美元。这不是 MiniMax 实验，也未包含工具、浏览器环境、重试和人工复核支出。缓存命中部分只能按实际命中计价，不能把所有历史输入都默认视作缓存。
工程上更有用的量是“每个验收成功任务的总费用”。如果降低单价后任务需要更多动作或失败重试，总成本未必同比下降；如果成功率与轨迹长度稳定，价格下降才更可能直接转化为收益。这是从计费结构作出的判断，不是公告已验证的结论。
TPS 不等于用户等待时间
200+ TPS 描述的是输出 token 速率，P50 说明中位水平；两者都没有覆盖首 token 等待、工具执行、界面交互或排队。一个 Computer Use 任务可能主要等待网页响应，软件任务可能主要等待测试运行，此时模型输出更快不一定让整项任务接近三倍提速。
评估长流程时，还需把重试次数、结束条件和最终外部状态一起看。模型声称完成、工具返回成功和真正达到业务目标是不同观测。公告的基准成绩提供阅读优先级线索，却没有证明任意无人值守工作流已经可靠，尤其不能从网络安全 benchmark 分数直接推断实际防护效果。
把一次模型更新拆成可回答的问题
如果已有任务能稳定完成，比较重点可以放在相同验收标准下的费用与等待时间；如果原来经常失败，应先确认新模型是否减少失败，再谈单价。两类问题的分母不同：前者关注成功任务的开销，后者还要记录失败尝试消耗，避免只统计完成的样本，让难任务悄悄消失。
缓存也是需要单列的条件。公告提供缓存输入价格，却未在本文说明命中生命周期、前缀匹配条件或某个业务的实际命中率。即使名义缓存价很低，工具返回持续改变上下文时，可复用的输入比例仍可能有限。费用估算应保留普通输入与缓存命中输入两个计数，不能只乘最便宜的价格。
对长流程，偶发严重错误还可能比平均基准分更影响使用价值。例如软件补丁通过测试之后是否引入额外改动，或者桌面任务是否改变了不应触碰的文件，都需要最终状态验收。上述例子是工程评估维度，不是对该模型已经观察到的缺陷。公告没有提供这类细分错误统计，因此值得后续验证，而不能用模型排名代替答案。
哪些结论现在成立
官方称 M3.1 Flash 已通过 MiniMax API、M Plan 和 MiniMax Code 提供，权重将在以后发布。可调用服务与可下载权重是不同状态；文章没有给出权重发布日期、参数规模或可本地复现的完整部署条件。本篇没有验证账号侧可用性，也不扩展为购买建议。
这次发布值得跟进的是能力、轨迹长度与低价能否共同保持，而不仅是某一排行榜位置。面向已有 Agent 系统，最有解释力的比较是固定任务、工具权限、harness 与预算，同时记录成功率、输出质量、总 token、缓存命中、费用和端到端延迟。模型更新提供了一个可测试的新候选；公告本身仍留下服务条件与详细架构两类证据缺口。