作者 | 姚戈

就在今年春節(jié)假期期間，OpenRouter 上出現(xiàn)了一組耐人尋味的數(shù)據變化。

作為目前全球最主要的大模型 API 聚合網關之一，OpenRouter 的 Token 調用量在 2026 年 1 月下旬出現(xiàn)了明顯躍升。自 1 月 26 日當周開始，平臺 Token 周增量首次突破 1.5T，這一幅度在過去的調用曲線中并不常見。時間點同樣值得玩味——這一輪增長幾乎與 OpenClaw 的迅速傳播高度重合。人們開始發(fā)現(xiàn)，OpenClaw 簡直就是 Token 碎紙機。

2 月 13 日發(fā)布的 MiniMax M2.5，在上線不到一周內便迅速登頂 OpenRouter Token 調用榜首。在 2 月 9 日至 2 月 15 日這一統(tǒng)計周期內，OpenRouter 的 Token 周調用量較此前一周激增 3.19T Tokens，其中僅 MiniMax M2.5 就貢獻了 1.44T Tokens，調用規(guī)模超過 Kimi K2.5 、GLM-5、DeepSeek V3.2 的總和。

隨后，OpenRouter 官方披露了另一項關鍵信號：過去數(shù)周內，平臺長文本生成需求顯著上升，在 100K 至 1M Token 區(qū)間，MiniMax M2.5 的調用量處于領先位置。這個 Token 區(qū)間正是 Agent 工作流中最具代表性的消耗范圍。

從定價維度看，MiniMax M2.5 的確呈現(xiàn)出極具沖擊力的成本結構：其每百萬 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 美元（以上數(shù)據均基于 2 月 23 日 OpenRouter 官網統(tǒng)計）。

然而，如果只將 M2.5 的調用激增理解為“價格驅動”，就很難看到數(shù)據背后的結構性變化。

從 MiniMax 此次在 OpenRouter 上的“異常波動”中可以看到，以 Openclaw 為代表的 AgentOS ，并非只是放大了 Token 消耗，它同時迫使模型廠商將 Agent 與 LLM 的關系視作基礎設施問題。在這一意義上，M2.5 的增長也呈現(xiàn)出不同于傳統(tǒng)模型競爭的特征：此前因成本過高或推理效率不足而難以落地的 Agent 場景，開始具備了現(xiàn)實可行性。

當 AgentOS 成為 Token 的重要傳輸渠道，成為人和機器與 LLM 打交道的重要媒介，它必定會改變 LLM 廠商，對 LLM 技術架構的設計，甚至商業(yè)模式。

AgentOS 來了

AgentOS 的興起，本質上并不是產品類別的變化，而是對 LLM 使用方式的重構。

以 OpenClaw 為例，這個最初由 Peter Steinberger 在周末構建的“小玩具”，在短短數(shù)月內，演變?yōu)槟苤苯硬倏乇镜匚募到y(tǒng)的開源 Agent 內核。

盡管它的安全架構、工程設計仍遭人詬病，處于風暴的中心的 OpenClaw 依舊向科技行業(yè)證明了 AgentOS 這個概念的吸引力：行業(yè)快速接受了“模型直接參與操作系統(tǒng)級任務執(zhí)行”這件事。

這意味著，大模型開始從“受限于云端沙箱的文本生成器”，轉向“具備環(huán)境操作能力的執(zhí)行節(jié)點”。模型的輸出不再只是語言，而是可以通過工具鏈條轉化為對真實系統(tǒng)狀態(tài)的改變。

更重要的是，AgentOS 讓 Token 的 ROI 衡量更加明確了。

在對話式產品中，Token 的消耗對應的是文本輸出；而在 AgentOS 框架下，Token 的消耗可以直接轉化任務結果。Token 從交互成本轉變?yōu)樾袆映杀荆Ｐ屯评硎状尉邆淞丝捎嬃康默F(xiàn)實產出。

當 AgentOS 開始成為 Token 的主要傳輸渠道，并逐漸演變?yōu)槿藱C交互與任務執(zhí)行的重要媒介，大模型廠商面臨的便不再只是模型能力問題，而是一次更底層的系統(tǒng)適配挑戰(zhàn)：模型如何在復雜的執(zhí)行環(huán)境中保持效率與穩(wěn)定性？

從模型架構與訓練范式的角度看，這種變化至少帶來了五個層面的影響。

第一，從“提示詞工程”轉向“系統(tǒng)級適配”。

Axiom Partners 的 AI 負責人在剖析 OpenClaw 開源代碼后指出，其核心設計理念在于將智能體定義為磁盤上的文件集合，而非單純的代碼或需反復注入的提示詞。記憶以 Markdown 文件的形式持久化存在于工作區(qū)中。

這一轉變將智能體從一次性腳本升維為可版本控制的基礎設施，進而倒逼模型廠商在構建 LLM 時，必須確保模型具備處理模塊化、動態(tài)組裝指令堆棧的能力。模型不僅需理解單一 Prompt，更要在包含 session 歷史、技能定義及內存檢索結果的復雜系統(tǒng)提示詞中，保持推理的穩(wěn)定性，避免因結構復雜化而“迷失”。

第二，內化“上下文管理”能力以應對長程任務。

傳統(tǒng)的 Agent 通常將上下文管理看作是一個外部的動作：由開發(fā)者預設死規(guī)則，硬性截斷，或或調用另一個更便宜的模型把舊對話總結成一段話，再喂給主模型。

隨著交互輪次增加，模型看到的是一個被開發(fā)者閹割過的上下文，這會導致模型產生幻覺或邏輯不連貫。

而將“上下文管理”從外部邏輯轉化為 Agent 的內在行為，已經成為當前的集中實踐。例如 Letta/MemGPT 能通過一套分頁 (Paging) 算法，讓 Agent 通過函數(shù)調用，自主地將舊記憶從上下文移動到外部存儲，或者根據當前需求從外部提取特定歷史。Mem0 則用 LLM 提取出結構化的事實并與現(xiàn)有記憶進行沖突檢測，并將其轉化為結構化的記憶條目存入向量數(shù)據庫。

第三，追求極致的“工程效率”以節(jié)省高 Token 消耗帶來的開銷。

Agent 場景是 Token 消耗的大戶，一次任務往往產生極長且包含大量重復前綴的軌跡。為了讓 Agent 在商業(yè)上具備可行性，廠商必須在模型架構中引入極致的工程優(yōu)化。

例如 Prompt Caching 技術，廠商通過緩存 API 請求的“前綴”，讓重復發(fā)送的系統(tǒng)提示詞或歷史對話成本大幅降低。

第四，訓練目標從“刷榜”轉向“效率與協(xié)作”。

在 AgentOS 架構下，用戶不僅關注結果的正確性，更在意執(zhí)行的速度與安全性。這促使廠商在強化學習階段引入更復雜的獎勵函數(shù)。

需要注意的是，模型的能力也會影響 Agent 的自主性（Agency）邊界。模型也被賦予更強的結果驗證能力，在輸出前能自我檢查是否符合安全規(guī)范，從而降低因執(zhí)行錯誤操作而導致的回滾成本。

第五，構建應對“黑盒”環(huán)境的魯棒性。

OpenClaw 讓我們看到，當 AgentOS 運行在用戶的本地私有基礎設施上時候，對模型廠商而言，這些執(zhí)行環(huán)境將成為難以觀測的“黑盒”。因此，廠商必須采用非侵入式集成的訓練方案，在不感知 Agent 內部實現(xiàn)細節(jié)的前提下，穩(wěn)定地調用工具并處理錯誤。

MiniMax M2.5 的設計巧思

一位來自保加利亞的開發(fā)者，最近完成了一次極具代表性的實驗。他將 MiniMax M2.5 部署在一臺搭載 GB10 芯片、手掌大小的 ZGX 設備上。為了在有限算力與散熱條件下維持可用推理性能，他對模型進行了結構裁剪，并將整體精度壓縮至 NVFP4。

現(xiàn)在，M2.5 已被這位開發(fā)者作為日常主力模型使用。在本地 vLLM 推理框架支持下，MiniMax-M2.5 可以與 “Claude Code” 多智能體系統(tǒng)協(xié)同運行。為避免不同智能體在代碼修改與上下文管理中產生沖突，他為每個智能體劃分了彼此隔離的獨立工作區(qū)，從而維持并發(fā)任務執(zhí)行的穩(wěn)定性。

這個掌上硬件的極限案例，印證了 M2.5 在極端資源約束下，仍能維持高精度的邏輯執(zhí)行。這種穩(wěn)健的落地能力，核心得益于 MiniMax 的 Forge 系統(tǒng)——它在訓推階段便對模型泛化性進行了極致推演。

而 Forge 系統(tǒng)的誕生，正是為了應對 Agent 應用范式的演進。 MiniMax 在 M2 系列研發(fā)中意識到，傳統(tǒng)的對話式訓練框架已難以覆蓋復雜智能體的使用形態(tài)。因此在訓推階段便強化了模型在 Agent 場景的適應性。

不同于僅關注對話的傳統(tǒng)模型，F(xiàn)orge 將模型置于成千上萬個真實的 Agent 腳手架中進行實戰(zhàn)演練，通過模擬工具調用、長程搜索及復雜邏輯推理，驅動模型在不斷的試錯中進化為高效執(zhí)行任務的“行動派”。

Forge 的設計試圖回應大模型訓練中的一個典型矛盾，即在系統(tǒng)吞吐量、訓練穩(wěn)定性與 Agent 靈活性之間尋求最優(yōu)解。為了在支持高達 200k 超長上下文的同時確保高效吞吐，并實現(xiàn)跨數(shù)百種框架與數(shù)千種工具格式的泛化，F(xiàn)orge 在架構與工程層面進行了深度重構。

在系統(tǒng)結構上，F(xiàn)orge 將 Agent 執(zhí)行邏輯與底層訓推引擎徹底解耦。

Agent 層被統(tǒng)一抽象為軌跡生產者，負責與執(zhí)行環(huán)境交互并生成 trajectory 數(shù)據。通過將環(huán)境交互與模型生成過程分離，Agent 可以專注于上下文管理與任務邏輯，而無需感知底層訓練或推理機制的變化。

中間件抽象層承擔系統(tǒng)隔離與通信標準化的角色。Gateway Server 負責處理 Agent 與模型之間的交互請求，通過統(tǒng)一協(xié)議屏蔽模型差異；Data Pool 則以異步方式收集交互軌跡與過程信號，作為生成與訓練之間的緩沖與調度樞紐。訓練與推理引擎分別承擔策略生成與模型更新職責，前者聚焦高吞吐 Token 生成，后者通過調度機制持續(xù)更新策略分布并與采樣過程保持同步。

備注：MiniMax Agent RL "Forge" 架構圖

在工程優(yōu)化層面，MiniMax 提出了 Prefix Tree Merging 以降低冗余計算。

Agent 多輪請求之間通常存在大量共享的上下文前綴，若將每次請求視為獨立樣本，系統(tǒng)將重復計算公共部分，造成算力浪費。Prefix Tree Merging 將線性訓練樣本重構為可共享前綴的樹形結構，使不同采樣分支能夠在樣本級別合并。借助 Attention Mask 等底層原語，系統(tǒng)在數(shù)學邏輯上保持與傳統(tǒng)方案一致，而冗余前綴被有效消除。實踐結果顯示，該方案在不影響 loss 計算與指標統(tǒng)計的前提下，實現(xiàn)了數(shù)量級的訓練加速，并顯著降低顯存開銷。

在調度策略上，為了平衡效率和穩(wěn)定性，F(xiàn)orge 采用了一種介于“排隊等候”與“誰快誰先練”之間的折中策略。

Windowed FIFO 設置了一個可見窗口，使短任務獲得一定優(yōu)先級，同時避免長任務被持續(xù)餓死，從而在保證吞吐效率的同時抑制分布偏移風險。

在窗口內，完成快的任務可以先練（局部貪婪）；但如果最前面的長任務沒完，窗口就不移動（全局阻塞）。

獎勵機制的設計則體現(xiàn)了 Agent 場景的另一項關鍵特征：執(zhí)行效率與結果質量同等重要。Forge 在強化學習中引入復合獎勵函數(shù)，不僅關注任務完成結果，也顯式建模中間行為與時間成本。過程獎勵用于約束工具調用質量與行為一致性，任務完成時間被納入優(yōu)化目標以抑制過度推理傾向，而 Reward-to-Go 機制則通過標準化長周期任務回報降低梯度方差，提升信用分配精度。模型由此學習到的，不只是正確決策路徑，也包括更具資源效率的執(zhí)行策略。

從系統(tǒng)設計角度看，F(xiàn)orge 并非單純的訓練加速工具，而是圍繞 Agent 使用結構變化所構建的一套訓練基礎設施。它所解決的核心問題，是模型如何在高 Token 消耗、高環(huán)境復雜度的執(zhí)行框架中保持可擴展性與泛化能力。這一方向性的調整，也構成了 M2.5 在 Agent 場景中表現(xiàn)差異的重要基礎。

結 語

MiniMax M2.5 在 OpenRouter 上的調用躍升，為 MiniMax 帶來了極高的關注度。但在大模型領域，發(fā)布初期的爆發(fā)式增長從來都不是終局指標。模型真正的競爭力，往往要在隨后的新一輪競爭中才能顯現(xiàn)。

模型同樣擁有自身的“生命曲線”。a16z 與 OpenRouter 的研究顯示，模型在發(fā)布后的數(shù)月內都會經歷用戶快速流失，并在大約第五個月附近收斂至相對穩(wěn)定的留存水平。他們還觀察到，一小部分早期用戶群表現(xiàn)出持久的留存率，這些用戶群體并非僅僅是早期采用者，他們代表的是那些工作負載與模型之間已形成深度且持久契合的用戶。一旦這種契合建立，便會產生經濟和認知上的慣性，即使出現(xiàn)更新的模型，也難以被替代。

這也預示著，大模型競爭正在發(fā)生更深層的遷移。參數(shù)規(guī)模、榜單排名與單點能力的重要性正在下降，而模型與工作負載之間的匹配效率、系統(tǒng)協(xié)同能力與長期粘性，正成為新的核心變量。

從這一視角看，MiniMax M2.5 及其背后的 Forge 架構所試圖解決的，正是 Agent 場景下長期存在的效率與適配問題。與單純提升生成性能不同，M2.5 的核心目標在于增強模型在復雜任務鏈條中的執(zhí)行能力，以更低的系統(tǒng)開銷承載此前難以穩(wěn)定覆蓋的高價值工作負載。