MiniMax 成为 Token 调用第一后，模型厂商必须面对的 AgentOS 现实

作者 | 姚戈

就在今年春节假期期间，OpenRouter 上出现了一组耐人寻味的数据变化。

作为目前全球最主要的大模型 API 聚合网关之一，OpenRouter 的 Token 调用量在 2026 年 1 月下旬出现了明显跃升。自 1 月 26 日当周开始，平台 Token 周增量首次突破 1.5T，这一幅度在过去的调用曲线中并不常见。时间点同样值得玩味——这一轮增长几乎与 OpenClaw 的迅速传播高度重合。人们开始发现，OpenClaw 简直就是 Token 碎纸机。

2 月 13 日发布的 MiniMax M2.5，在上线不到一周内便迅速登顶 OpenRouter Token 调用榜首。在 2 月 9 日至 2 月 15 日这一统计周期内，OpenRouter 的 Token 周调用量较此前一周激增 3.19T Tokens，其中仅 MiniMax M2.5 就贡献了 1.44T Tokens，调用规模超过 Kimi K2.5 、GLM-5、DeepSeek V3.2 的总和。

随后，OpenRouter 官方披露了另一项关键信号：过去数周内，平台长文本生成需求显著上升，在 100K 至 1M Token 区间，MiniMax M2.5 的调用量处于领先位置。这个 Token 区间正是 Agent 工作流中最具代表性的消耗范围。

从定价维度看，MiniMax M2.5 的确呈现出极具冲击力的成本结构：其每百万 token 的输入与输出单价分别低至 0.103 美元和 1.34 美元。作为对比，即便是以低价著称的 Kimi K2.5，其单价也达到了 0.254 美元和 2.84 美元，Gemini 2.5 Flash 为 0.278 美元和 3.00 美元，而 Claude Opus 4.6 更是高达 2.52 美元和 25.31 美元（以上数据均基于 2 月 23 日 OpenRouter 官网统计）。

然而，如果只将 M2.5 的调用激增理解为“价格驱动”，就很难看到数据背后的结构性变化。

从 MiniMax 此次在 OpenRouter 上的“异常波动”中可以看到，以 Openclaw 为代表的 AgentOS ，并非只是放大了 Token 消耗，它同时迫使模型厂商将 Agent 与 LLM 的关系视作基础设施问题。在这一意义上，M2.5 的增长也呈现出不同于传统模型竞争的特征：此前因成本过高或推理效率不足而难以落地的 Agent 场景，开始具备了现实可行性。

当 AgentOS 成为 Token 的重要传输渠道，成为人和机器与 LLM 打交道的重要媒介，它必定会改变 LLM 厂商，对 LLM 技术架构的设计，甚至商业模式。

AgentOS 来了

AgentOS 的兴起，本质上并不是产品类别的变化，而是对 LLM 使用方式的重构。

以 OpenClaw 为例，这个最初由 Peter Steinberger 在周末构建的“小玩具”，在短短数月内，演变为能直接操控本地文件系统的开源 Agent 内核。

尽管它的安全架构、工程设计仍遭人诟病，处于风暴的中心的 OpenClaw 依旧向科技行业证明了 AgentOS 这个概念的吸引力：行业快速接受了“模型直接参与操作系统级任务执行”这件事。

这意味着，大模型开始从“受限于云端沙箱的文本生成器”，转向“具备环境操作能力的执行节点”。模型的输出不再只是语言，而是可以通过工具链条转化为对真实系统状态的改变。

更重要的是，AgentOS 让 Token 的 ROI 衡量更加明确了。

在对话式产品中，Token 的消耗对应的是文本输出；而在 AgentOS 框架下，Token 的消耗可以直接转化任务结果。Token 从交互成本转变为行动成本，模型推理首次具备了可计量的现实产出。

当 AgentOS 开始成为 Token 的主要传输渠道，并逐渐演变为人机交互与任务执行的重要媒介，大模型厂商面临的便不再只是模型能力问题，而是一次更底层的系统适配挑战：模型如何在复杂的执行环境中保持效率与稳定性？

从模型架构与训练范式的角度看，这种变化至少带来了五个层面的影响。

第一，从“提示词工程”转向“系统级适配”。

Axiom Partners 的 AI 负责人在剖析 OpenClaw 开源代码后指出，其核心设计理念在于将智能体定义为磁盘上的文件集合，而非单纯的代码或需反复注入的提示词。记忆以 Markdown 文件的形式持久化存在于工作区中。

这一转变将智能体从一次性脚本升维为可版本控制的基础设施，进而倒逼模型厂商在构建 LLM 时，必须确保模型具备处理模块化、动态组装指令堆栈的能力。模型不仅需理解单一 Prompt，更要在包含 session 历史、技能定义及内存检索结果的复杂系统提示词中，保持推理的稳定性，避免因结构复杂化而“迷失”。

第二，内化“上下文管理”能力以应对长程任务。

传统的 Agent 通常将上下文管理看作是一个外部的动作：由开发者预设死规则，硬性截断，或或调用另一个更便宜的模型把旧对话总结成一段话，再喂给主模型。

随着交互轮次增加，模型看到的是一个被开发者阉割过的上下文，这会导致模型产生幻觉或逻辑不连贯。

而将“上下文管理”从外部逻辑转化为 Agent 的内在行为，已经成为当前的集中实践。例如 Letta/MemGPT 能通过一套分页 (Paging) 算法，让 Agent 通过函数调用，自主地将旧记忆从上下文移动到外部存储，或者根据当前需求从外部提取特定历史。Mem0 则用 LLM 提取出结构化的事实并与现有记忆进行冲突检测，并将其转化为结构化的记忆条目存入向量数据库。

第三，追求极致的“工程效率”以节省高 Token 消耗带来的开销。

Agent 场景是 Token 消耗的大户，一次任务往往产生极长且包含大量重复前缀的轨迹。为了让 Agent 在商业上具备可行性，厂商必须在模型架构中引入极致的工程优化。

例如 Prompt Caching 技术，厂商通过缓存 API 请求的“前缀”，让重复发送的系统提示词或历史对话成本大幅降低。

第四，训练目标从“刷榜”转向“效率与协作”。

在 AgentOS 架构下，用户不仅关注结果的正确性，更在意执行的速度与安全性。这促使厂商在强化学习阶段引入更复杂的奖励函数。

需要注意的是，模型的能力也会影响 Agent 的自主性（Agency）边界。模型也被赋予更强的结果验证能力，在输出前能自我检查是否符合安全规范，从而降低因执行错误操作而导致的回滚成本。

第五，构建应对“黑盒”环境的鲁棒性。

OpenClaw 让我们看到，当 AgentOS 运行在用户的本地私有基础设施上时候，对模型厂商而言，这些执行环境将成为难以观测的“黑盒”。因此，厂商必须采用非侵入式集成的训练方案，在不感知 Agent 内部实现细节的前提下，稳定地调用工具并处理错误。

MiniMax M2.5 的设计巧思

一位来自保加利亚的开发者，最近完成了一次极具代表性的实验。他将 MiniMax M2.5 部署在一台搭载 GB10 芯片、手掌大小的 ZGX 设备上。为了在有限算力与散热条件下维持可用推理性能，他对模型进行了结构裁剪，并将整体精度压缩至 NVFP4。

现在，M2.5 已被这位开发者作为日常主力模型使用。在本地 vLLM 推理框架支持下，MiniMax-M2.5 可以与 “Claude Code” 多智能体系统协同运行。为避免不同智能体在代码修改与上下文管理中产生冲突，他为每个智能体划分了彼此隔离的独立工作区，从而维持并发任务执行的稳定性。

这个掌上硬件的极限案例，印证了 M2.5 在极端资源约束下，仍能维持高精度的逻辑执行。这种稳健的落地能力，核心得益于 MiniMax 的 Forge 系统——它在训推阶段便对模型泛化性进行了极致推演。

而 Forge 系统的诞生，正是为了应对 Agent 应用范式的演进。 MiniMax 在 M2 系列研发中意识到，传统的对话式训练框架已难以覆盖复杂智能体的使用形态。因此在训推阶段便强化了模型在 Agent 场景的适应性。

不同于仅关注对话的传统模型，Forge 将模型置于成千上万个真实的 Agent 脚手架中进行实战演练，通过模拟工具调用、长程搜索及复杂逻辑推理，驱动模型在不断的试错中进化为高效执行任务的“行动派”。

Forge 的设计试图回应大模型训练中的一个典型矛盾，即在系统吞吐量、训练稳定性与 Agent 灵活性之间寻求最优解。为了在支持高达 200k 超长上下文的同时确保高效吞吐，并实现跨数百种框架与数千种工具格式的泛化，Forge 在架构与工程层面进行了深度重构。

在系统结构上，Forge 将 Agent 执行逻辑与底层训推引擎彻底解耦。

Agent 层被统一抽象为轨迹生产者，负责与执行环境交互并生成 trajectory 数据。通过将环境交互与模型生成过程分离，Agent 可以专注于上下文管理与任务逻辑，而无需感知底层训练或推理机制的变化。

中间件抽象层承担系统隔离与通信标准化的角色。Gateway Server 负责处理 Agent 与模型之间的交互请求，通过统一协议屏蔽模型差异；Data Pool 则以异步方式收集交互轨迹与过程信号，作为生成与训练之间的缓冲与调度枢纽。训练与推理引擎分别承担策略生成与模型更新职责，前者聚焦高吞吐 Token 生成，后者通过调度机制持续更新策略分布并与采样过程保持同步。

备注：MiniMax Agent RL "Forge" 架构图

在工程优化层面，MiniMax 提出了 Prefix Tree Merging 以降低冗余计算。

Agent 多轮请求之间通常存在大量共享的上下文前缀，若将每次请求视为独立样本，系统将重复计算公共部分，造成算力浪费。Prefix Tree Merging 将线性训练样本重构为可共享前缀的树形结构，使不同采样分支能够在样本级别合并。借助 Attention Mask 等底层原语，系统在数学逻辑上保持与传统方案一致，而冗余前缀被有效消除。实践结果显示，该方案在不影响 loss 计算与指标统计的前提下，实现了数量级的训练加速，并显著降低显存开销。

在调度策略上，为了平衡效率和稳定性，Forge 采用了一种介于“排队等候”与“谁快谁先练”之间的折中策略。

Windowed FIFO 设置了一个可见窗口，使短任务获得一定优先级，同时避免长任务被持续饿死，从而在保证吞吐效率的同时抑制分布偏移风险。

在窗口内，完成快的任务可以先练（局部贪婪）；但如果最前面的长任务没完，窗口就不移动（全局阻塞）。

奖励机制的设计则体现了 Agent 场景的另一项关键特征：执行效率与结果质量同等重要。Forge 在强化学习中引入复合奖励函数，不仅关注任务完成结果，也显式建模中间行为与时间成本。过程奖励用于约束工具调用质量与行为一致性，任务完成时间被纳入优化目标以抑制过度推理倾向，而 Reward-to-Go 机制则通过标准化长周期任务回报降低梯度方差，提升信用分配精度。模型由此学习到的，不只是正确决策路径，也包括更具资源效率的执行策略。

从系统设计角度看，Forge 并非单纯的训练加速工具，而是围绕 Agent 使用结构变化所构建的一套训练基础设施。它所解决的核心问题，是模型如何在高 Token 消耗、高环境复杂度的执行框架中保持可扩展性与泛化能力。这一方向性的调整，也构成了 M2.5 在 Agent 场景中表现差异的重要基础。

结 语

MiniMax M2.5 在 OpenRouter 上的调用跃升，为 MiniMax 带来了极高的关注度。但在大模型领域，发布初期的爆发式增长从来都不是终局指标。模型真正的竞争力，往往要在随后的新一轮竞争中才能显现。

模型同样拥有自身的“生命曲线”。a16z 与 OpenRouter 的研究显示，模型在发布后的数月内都会经历用户快速流失，并在大约第五个月附近收敛至相对稳定的留存水平。他们还观察到，一小部分早期用户群表现出持久的留存率，这些用户群体并非仅仅是早期采用者，他们代表的是那些工作负载与模型之间已形成深度且持久契合的用户。一旦这种契合建立，便会产生经济和认知上的惯性，即使出现更新的模型，也难以被替代。

这也预示着，大模型竞争正在发生更深层的迁移。参数规模、榜单排名与单点能力的重要性正在下降，而模型与工作负载之间的匹配效率、系统协同能力与长期粘性，正成为新的核心变量。

从这一视角看，MiniMax M2.5 及其背后的 Forge 架构所试图解决的，正是 Agent 场景下长期存在的效率与适配问题。与单纯提升生成性能不同，M2.5 的核心目标在于增强模型在复杂任务链条中的执行能力，以更低的系统开销承载此前难以稳定覆盖的高价值工作负载。