---
title: "MiniMax Token调用第一后：AgentOS现实与模型厂商的系统适配挑战"
created: 2026-05-28
updated: 2026-05-28
type: raw
tags: [agentos, minimax, forge, model-training, context-management, prefix-tree-merging, windowed-fifo, composite-reward, openrouter, peter-steinberger, openclaw]
sources:
  - https://mp.weixin.qq.com/s/0vAWHzlEZnhZYolHTvM1bg
review_value: 8
review_confidence: 8
sha256: 4f5dc199fbd1063d3ce46d7e8e44e4f271fa0d2b2e323db47cb10f1a10c0cd1c
---

## 背景

作者：姚戈，InfoQ。

2026年春节假期期间，OpenRouter Token 调用量出现明显跃升。1月26日当周周增量首次突破 1.5T，与 OpenClaw 迅速传播高度重合——OpenClaw 堪称 Token 碎纸机。

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

**定价对比**（2月23日 OpenRouter）：
- MiniMax M2.5：输入 $0.103/M，输出 $1.34/M
- Kimi K2.5：$0.254/$2.84
- Gemini 2.5 Flash：$0.278/$3.00
- Claude Opus 4.6：$2.52/$25.31

## AgentOS 兴起：Token 从交互成本变为行动成本

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

OpenClaw 最初由 Peter Steinberger 周末构建的"小玩具"，在短短数月演变为能直接操控本地文件系统的开源 Agent 内核。行业快速接受了"模型直接参与操作系统级任务执行"这件事。

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

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

## AgentOS 对模型厂商的五大影响

### 1. 从"提示词工程"转向"系统级适配"

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

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

### 2. 内化"上下文管理"能力

传统 Agent 通常将上下文管理看作外部动作：由开发者预设死规则，硬性截断，或调用另一个更便宜的模型把旧对话总结成一段话再喂给主模型。随着交互轮次增加，模型看到的是被开发者阉割过的上下文，导致幻觉或逻辑不连贯。

**将"上下文管理"从外部逻辑转化为 Agent 内在行为**已成为当前集中实践：
- **Letta/MemGPT**：通过 Paging 算法，让 Agent 通过函数调用自主将旧记忆从上下文移动到外部存储，或根据当前需求从外部提取特定历史
- **Mem0**：用 LLM 提取结构化事实并与现有记忆进行冲突检测，转化为结构化记忆条目存入向量数据库

### 3. 追求极致工程效率

Agent 场景是 Token 消耗大户，一次任务往往产生极长且包含大量重复前缀的轨迹。

**Prompt Caching 技术**：缓存 API 请求的"前缀"，让重复发送的系统提示词或历史对话成本大幅降低。

### 4. 训练目标从"刷榜"转向"效率与协作"

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

- **过程奖励**：约束工具调用质量与行为一致性
- **任务完成时间纳入优化目标**：抑制过度推理倾向
- **Reward-to-Go**：标准化长周期任务回报，降低梯度方差，提升信用分配精度
- 模型被赋予更强的结果验证能力，在输出前能自我检查是否符合安全规范，降低回滚成本

### 5. 构建应对"黑盒"环境的鲁棒性

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

## MiniMax Forge 系统架构

MiniMax 研发 M2 系列时意识到传统对话式训练框架已难以覆盖复杂 Agent 使用形态，因此在训推阶段便强化了模型在 Agent 场景的适应性，核心是 **Forge 系统**。

### 设计目标
在系统吞吐量、训练稳定性与 Agent 灵活性之间寻求最优解。支持高达 200K 超长上下文同时确保高效吞吐，并实现跨数百种框架与数千种工具格式的泛化。

### 三层架构：Agent 层 → 中间件抽象层 → 训练与推理引擎

**Agent 层（轨迹生产者）**：
- 负责与执行环境交互，生成 trajectory 数据
- 专注于上下文管理与任务逻辑，无需感知底层训练或推理机制变化

**中间件抽象层（系统隔离+通信标准化）**：
- **Gateway Server**：处理 Agent 与模型之间的交互请求，通过统一协议屏蔽模型差异
- **Data Pool**：以异步方式收集交互轨迹与过程信号，作为生成与训练之间的缓冲与调度枢纽

**训练与推理引擎**：
- 训练引擎：聚焦高吞吐 Token 生成
- 推理引擎：通过调度机制持续更新策略分布，与采样过程保持同步

### 工程优化：Prefix Tree Merging

**问题**：Agent 多轮请求之间存在大量共享上下文前缀，若将每次请求视为独立样本，系统将重复计算公共部分，造成算力浪费。

**方案**：将线性训练样本重构为可共享前缀的树形结构，使不同采样分支能够在样本级别合并。借助 Attention Mask 等底层原语，系统在数学逻辑上保持与传统方案一致，冗余前缀被有效消除。

**效果**：不影响 loss 计算与指标统计前提下，实现数量级的训练加速，并显著降低显存开销。

### 调度策略：Windowed FIFO

介于"排队等候"与"谁快谁先练"之间的折中策略：

- **设置可见窗口**：短任务获得一定优先级，同时避免长任务被持续饿死，从而在保证吞吐效率的同时抑制分布偏移风险
- **窗口内**：完成快的任务可以先练（局部贪婪）
- **但如果最前面的长任务没完，窗口就不移动**（全局阻塞）

### 复合奖励函数设计

Agent 场景关键特征：执行效率与结果质量同等重要。引入复合奖励函数：

- **过程奖励**：约束工具调用质量与行为一致性
- **时间成本**：任务完成时间被纳入优化目标，抑制过度推理倾向
- **Reward-to-Go**：通过标准化长周期任务回报，降低梯度方差，提升信用分配精度

模型由此学习到的，不只是正确决策路径，也包括更具资源效率的执行策略。

## 结论

a16z 与 OpenRouter 的研究显示：模型发布后数月内都会经历用户快速流失，在大约第五个月附近收敛至稳定留存水平。**一小部分早期用户群表现出持久的留存率，他们代表的是工作负载与模型之间已形成深度且持久契合的用户**。一旦这种契合建立，便会产生经济和认知上的惯性，即使出现更新的模型，也难以被替代。

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

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