一位运营人员让智能体把两套系统中的客户记录对齐，再生成一份待回访清单。模型先读表，随后调用搜索、浏览器和脚本工具；第三次尝试才把字段映射正确。屏幕上答复的速度很快，账单却可能由反复传入的上下文、工具等待和人工核对共同决定。对这样的任务，采购会上只比较模型输出速度和输入单价，很容易选错。
10月19日，MiniMax 宣布 M3.1 Flash 上线 API、M Plan 和 MiniMax Code，面向编程、计算机操作、跨应用自动化与安全分析。官方称在线推理接近前代三倍，智能体任务整体使用成本下降约70%；公布的 API 价格为每百万输入 Token 0.15 美元、输出 Token 0.60 美元、缓存输入 Token 0.015 美元。[1][2] 企业拿固定权限、固定验收标准去测，最后该比的是每项合格任务总成本。一项工作做不成，再低的调用价也白花。尤其在同一任务要来回读写多个系统时，单次回答的流畅程度与最终交付质量之间，常隔着权限检查和数次失败恢复。
便宜的 Token 为什么未必带来便宜的任务
假设一次工单处理平均消耗100万普通输入 Token、20万输出 Token、200万缓存命中输入 Token。依照10月19日公布的标价，模型计费部分是 0.15＋0.12＋0.03＝0.30 美元。这个例子只是计费结构演示，不是 MiniMax 对真实工单的报价：同样一项任务，若中途多做两轮搜索、长篇解释或者失败后重跑，输出量和缓存命中率都会变化。工具执行、网页服务、人工复核以及系统基础设施也不在这笔模型账单里。
MiniMax 官方把“70%”表述为相较前代模型的智能体任务总体使用成本差异，同时列出输入、输出、缓存三个单价。[1] 企业至少要把两种指标拆开记录：模型服务的请求账单，与一项业务任务从开始到验收的全额费用。后者的分母是“成功且可用”的结果，而非所有回答。若便宜模型完成率下降，原本省下的 Token 开支可能在重试和人工修正中消失。反过来，较高的单次输出量也可能因为少走几次错误路径而降低最终成本。任何结论都要在同一批任务上得出。
速度也有类似问题。发布文章写到日常输出可达每秒200多个 Token，P50 持续超过每秒170 Token；这是厂商公布的输出吞吐口径。[1] 用户感受到的等待时间还包括排队、首个 Token 返回、工具启动、网络请求、浏览器加载和校验结果。评估自动处理工单时，应另记首字延迟、模型生成耗时、工具耗时、总历时的 P50/P95；把生成速度直接写成整条业务链快三倍，缺少对应的业务测量。
基准成绩能说明什么，不能替企业验收什么
MiniMax 报告 M3.1 Flash 在 DeepSWE v1.1 上为73.7%，在 OSWorld V2 上得61.7分，在 BankerToolBench 上得76.2分，并披露 CyberGym 成绩为82%。[1] 这些数字把“写代码”“操作电脑”“跨文件金融任务”“安全问题处理”分开观察，至少比一句“适合所有智能体”更有信息量。但不同基准的分母、任务设置、工具权限和评分方法不同；不能把73.7%、61.7分和82%排在同一张百分比榜单上直接比较。
以电脑操作为例，OSWorld 项目由研究者提供任务环境、评估程序和数据；其仓库在2025年7月28日特别提示，更新后的 OSWorld-Verified 修复了问题，比较成绩应注意所用版本。[4] MiniMax 博客使用“OSWorld V2”的名称。企业若想复现61.7分，需要先向供应商确认任务集、代理框架、浏览器环境、最大步骤数和失败重试规则，再拿自身的 CRM、ERP 或内网知识库测一遍。模型在标准桌面任务上表现良好，仍可能在企业单点登录、审批权限或页面动态加载处卡住。
软件工程同样如此。73.7%的 DeepSWE v1.1 成绩指向一组复杂开发任务，[1] 采购侧关心的则可能是能否在已有代码库中改动恰当文件、通过原有测试、保留安全约束，以及审查者需要花多少时间理解补丁。为避免把“能生成提交”当成“可以合并”，每道内部题都应配复现步骤、允许修改范围、自动测试和审阅清单。请同一名评审盲看不同模型的补丁，而不是让模型自评模型。
接口细节会改变实际账单
MiniMax 的模型调用文档列出 MiniMax-M3.1-Flash，上下文窗口为100万 Token，提供 Anthropic 兼容与 OpenAI 兼容入口；文档将思考深度列为 low、medium、high、xhigh、max，缺省为 max，思考不能关闭。[2] 这几项配置对智能体应用有直接影响。若现有程序只读取回答正文，迁移时应确认单独返回的思考内容不会被误存成给客户看的结果；若任务很简单，测试较低 effort 是否能省时、省输出 Token，同时保持准确率。最高上下文窗口是一项容量上限，不意味着每个任务都适合把整个代码库或所有历史对话塞进去。
API 定价页按普通输入、输出及缓存读取分列价格，[3] 因此做成本归因时，日志要分别留存三类用量。固定系统提示词、长期不变的工具说明和重复引用的资料更有机会受益于缓存；用户每次上传的动态文件、不断改写的上下文未必能按理想命中率计费。试验中应以实际账单回填估算表，并记下不同提示词模板的缓存命中率、输出长度、异常重试次数。随意换模板造成缓存下降时，“模型价格很低”也无法回答为什么账单没有降。
需要留意产品状态。10月19日的发布博客明确写明 API、M Plan 和 MiniMax Code 已可使用，同时称模型权重“稍后发布”。[1] API 服务可调用和权重可下载是两项不同的采购选项。若合同要求本地部署、权重审计或离线备份，团队当前应索取确切的许可、交付时间和部署文档，而不能仅凭线上服务已开通做项目排期。
编程、桌面操作、安全分析，别共用一套验收标准
代码代理的工作往往以仓库为边界，任务结束时可以看测试是否通过、补丁有没有碰到未授权目录。桌面操作代理则会进入不断变化的页面：同一张表格经过排序、弹窗遮挡或会话过期，操作坐标和页面结构就可能改变。把桌面任务的“点击到了提交按钮”当作成功也不够，后台记录有没有保存、审批链有没有触发，才是业务事实。两类任务所需的工具记录、环境快照和事后追责材料并不一样。
安全分析又多一层约束。厂商列出 CyberGym 82%的成绩，[1] 企业自测时应先限定仓库、镜像和网络访问范围，由安全人员提供可复现的漏洞样本与预期修复结果。给模型一个发现漏洞的题目，可以观察它的定位与补丁质量；直接让它对生产服务器做渗透测试，会混淆研究能力和行动授权。模型建议利用路径的内容，还要经过静态扫描、人工代码审查与独立复测，才能进入修复流程。
跨应用智能体常见的损耗来自交接处。CRM 里客户名称相同但 ID 不同，邮件里有用户临时改口，财务表中货币单位各异。一次错误的自动补全可能很难被最终回复发现。为每个任务保留操作轨迹与工具原始返回，在提交前要求代理展示拟改动的记录 ID 和字段差异；敏感字段还需人工签核。这样做会占用时间，却能把“看起来写好了”转成“系统里确实改对了”。
用两周试验给采购会一份可用的账
先挑三类真实任务，每类取30至50件近期已解决且脱敏的样本：一类是跨应用表单或工单，一类是代码修改，一类是有明确引用或计算过程的分析。每件任务提供同一份输入资料、相同的工具许可和截止时间；现有方案与 M3.1 Flash 分别运行，评审只看到产物而不知道模型。随机抽样避免把最顺手的例子当作常态。涉及权限、客户资料和代码库时使用测试环境与最小权限账户；智能体只允许提出变更，生产系统中的付款、删除、发信等动作交给审批闸门。
然后画一张任务级流水账：输入 Token、输出 Token、缓存读取、工具调用次数与费用、人工复核分钟数、首次通过率、重试后通过率、总历时 P50/P95。对于失败件，记录原因是模型计划错误、工具接口返回异常、数据缺失，还是验收标准本身不清楚。把“成功任务的平均费用”与“全部样本平均费用”同时列出，才能识别某款模型靠反复尝试抬高成功率的情况。安全分析与自动执行类任务另设边界：测试环境里能识别漏洞，与在生产环境里拥有修改权限，风险完全不同。
第三步是做敏感性测试。同一工作流固定模型和工具，只调整上下文裁剪、缓存策略、思考深度与最大重试次数，每次只改一个条件。若降低思考深度后，简单工单成本下降而复杂改代码任务错误增多，便分别设定路由规则；没有必要让所有任务都跑最高档，也不宜把省钱参数强加给高风险工作。逐项保留版本、时间、请求 ID 和验收记录，产品更新后才有可比的基线。
最后看推广门槛。内部试验若显示模型账单低、但人工复核翻倍，可先让它处理信息抽取和建议草稿；若它在低风险任务中能稳定达到既定通过率，再逐步扩大自动执行范围。采购合同还要问清限流、故障切换、日志留存、数据处理和模型版本变更机制。推理速度是用户体验的一部分，长期可控的任务交付才是企业愿意持续付费的东西。
试点预算不妨再做两张表。第一张按业务部门分配，列出工单、代码和分析任务各自的数量、平均失败成本、人工复核时间，避免将开发团队的高产出与客服团队的低通过率取平均。第二张按问题严重程度划分：格式瑕疵可以自动重跑；误发通知或错误改写客户资料需要立即暂停并审计。两张表合起来，才知道低价模型适合先进入哪个流程，哪个流程宁可多付模型费也得有人盯住。
一个常被忽略的变量是任务进入模型前的准备成本。仓库没有可运行测试、知识库存在过期文档、系统账户权限配置混乱时，模型会花费大量上下文去猜“正确做法”。试点期间要把输入资料版本固定，记录缺失信息造成的失败；改好资料后再重新测一次。如果整理知识库本身就带来明显收益，应把这部分收益归给数据治理，别全记在新模型名下。
正式运行还需要持续抽检。上线首周可对所有自动完成的样本复核，稳定后按风险层级抽样；一旦模型版本、工具接口或业务表单变化，就恢复较高比例的人工审核。每天看失败原因分布，比月底看一张总成本图更早发现问题。所谓“便宜”，最终要包括错单恢复的成本和负责人睡得安不安心。
还可以设置一组专门考查信息不足的题目：客户没有给出订单号、工单附件打不开、代码需求彼此矛盾。优秀的智能体应当在必要时停下来追问，或者把无法确认的字段明确留空。若测试集全是输入完整、答案唯一的理想题，自动化率看起来会很高，正式接入却容易凭空补全数据。审核这些题时要把合理拒绝和正确请求澄清计入合格结果，别用“没有立刻交付”扣分。
这些试验结束后，每个部门给出自己的上线阈值。客服可以规定字段准确率与人工抽检频率；研发要求关键测试全过且改动可回退；财务分析要让引用和公式可以追溯到原始文件。经理最终拿到一份按业务分组的清单：哪些任务本周能试，哪些还缺数据准备，哪些必须保留人工决策。
M3.1 Flash 的价格足以让采购团队拿出几周做实测，服务渠道也已公布。[1] 下个季度究竟能省多少，还得在企业自己的工单、代码库和审批系统中，以验收通过的结果计价。
参考资料
- MiniMax Research，《MiniMax M3.1 Flash: Redefining Agent Performance and Cost》，2026-10-19。上线渠道、报价、性能与基准、权重后续发布。原文
- MiniMax API Docs，《Model Invocation》，2026-10-19 查阅（页面未标发布日期）。模型名、上下文、兼容入口、思考设置和返回字段。原文
- MiniMax API Docs，《Pricing Overview》，2026-10-19 查阅（页面未标发布日期）。普通输入、输出和缓存读取计价类别。原文
- OSWorld 研究项目，《OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments》，仓库2024-04-11首次发布、2025-07-28说明 Verified 更新；2026-10-19 查阅。基准环境与版本比较的背景。原文