我下了一個任務，agent 開啟了 plan 模式，規劃了 7 個步驟。

我批準了，它開始跑，跑了三個步驟，然后停下來匯報：「我已經完成了 1、2、3，結果有這些和哪些……請問是否繼續 4、5、6、7？」

我說繼續。它又跑了兩步，然后又停了下來：「我已經完成了 4、5，結果有這些和哪些……請問是否繼續 6、7？」

一個晚上下來，讓 agent 干點長程的任務，并沒有長程的效果，對話框來回來去的全都是「繼續」。

很長時間以來，我在使用各種 Agent 完成工作，就是這樣的體驗。

這種體驗很不合邏輯。雖然「停下來確認」是個與 AI 共事時的好工作習慣，但在很多任務當中我從來沒主動要求它停，但它就是會停下來。

MiniMax 在最新的技術博客文章中，將 agent 產品的這種行為歸因于「上下文焦慮」。核心在于，模型本身對于「超長任務啥時候才算做完」的判斷是模糊的。說白了，不是不會做，而是不敢做，每完成一步都怕做錯，所以才會干一半就停下來問。

今天，MiniMax Agent 桌面端完成了一次重大更新。新加入了一個名為 Mavis 的模式（其實它是「MiniMax as a Jarvis」的縮寫）。

要知道讓一個 agent 當老板，一組 agent 當員工——這種傳統的多 agent 框架已經不是什么新鮮事了。但 MiniMax 指出，此前的主流多 agent 框架，其實本質上就是靠提示詞編排來讓模型玩「角色扮演」role play。但這種做法撐不了多久，就會遇到包括前面提到的上下文焦慮、長程任務退化、自檢等難題。

多 Agent 系統，需要一套持續運行、持續維護，并且多個 agent 之間不會「媾和」的可靠基礎設施。這就是 MiniMax 在做的事。

實測體驗：讓 agent 給對方「挑刺」

MiniMax 給它的 Agent Team 基礎設施起的名字叫做 Team Engine，引擎下面掛著三類核心角色：Leader、Worker、Verifier。顧名思義，一類做管理，一類干活，一類驗收。

最關鍵的差異在于，Worker 和 Verifier 之間是「對抗」的關系，誰也沒法蒙混過關。

前段時間，APPSO 正好在研究一個課題：「所有對 Coding/Agent 有所抱負的模型廠商，都要做自己的獨立 Coding/Agent 產品」。

（沒錯，MiniMax 在此之前是個反面案例，但沒想到文章還沒發出來，就已經證明自己了！）

于是我們又用這個課題再在 MiniMax 的 Agent Team 上跑了一次。

這個任務拆分出了 5 個 worker，每個 worker 完成任務后，都會整理結果交給 leader（顯示狀態「Mavis 發給 General」或者「General 發給 Mavis」等等。）

有一個 worker，運行了 12 分鐘還沒有返回結果。APPSO 注意到，這個 leader等不及了，于是發了一條 bash 命令檢查其工作狀態：

在 5 個 worker 都完成后，leader 又生成了 5 個 verifier——在任務列表中顯示為帶著「小黃帽」的 agent：

Verifier 很快就找到了錯誤！其中一個 verifier 發現了對應的 worker 交付成果中存在明確的數據錯誤，給出了「失敗」的判罰。緊接著，與之對應的 worker 重新啟動（顯示為運行中，會有一個藍色小圈的標識）。

點進對應的 worker 工作區觀察一下它的思考過程：「verifier 拒絕了我之前的交付成果，基于以下三個錯誤……我需要返回去重新核查關鍵事實，并檢查修正具體的數字問題……」

還別說，agent 跟 agent 之間「鐵面無私」，工作起來真的可靠。

這樣的來來回回，在五組 1v1 的 agent 對抗當中，總共發生了數十次。過程中，Mavis 還表示這次「學到了新東西」，并順手更新了一下記憶。

上一個任務先跑著，我們再開啟一個新的深度研究，基于權威口徑數據分析五一假期的旅游市場，并交付一份多維度分析報告。

這個研究比剛才的任務更加復雜。而且因為要持續對抗，Agent Team 在深度研究上所花的時間，也遠比一般的單 Agent 要長。

但最終呈現的報告，和其它 AI 深度研究交付的內容相比起來，確實干凈不少，也更加可信。

最近 APPSO 籌備了很多場線下活動，做策劃想方案一直是個難題。我們也把這個任務交給 Mavis 看看效果怎么樣。

我需要策劃一場在廣州舉辦的 AI 開發者線下沙龍，請你盡可能全面的給我提供多個適合百人千人科技活動的場地及大概報價，以及抓取同類活動的信息，然后幫我策劃這張 AI 活動的主題，宣傳，運營整個全部的工作，幫我把這些都整理成一份嚴格的商業計劃書格式，以及一個符合主題特色，設計精美的網頁。

光是制定計劃的時間，就比之前的深度研究任務要長。Mavis 回復「這個任務規模很大，需要多個 Agent 并行工作——場地調研、競品抓取、主題策劃、商業計劃書、網頁開發。」

Mavis 的過人之處，就在于我們還可以持續追加新的需求：

給我長報告的同時，最好還能給我起草一份初步的正式合同，和場地的合作、以及和邀請嘉賓的合作、等等可能涉及的合同，還有前期的財務表格，再給我一份用來匯報這套方案的 PPT，越詳細越好。

Agent Team 收到新需求后，會進一步完善計劃并啟動更多的工作流，最后，我們啟動了多達 9 個并行任務。

我們點開 Mavis 的思考過程，能看到里面有大量的 agent 之間互相發送的消息，這些 Agents 會在專門的 Team Engine 下工作，傳遞彼此的狀態，有的在等待、有的在執行、有的在驗證。

你看這個 Verifier，像不像吹毛求疵的「甲方」？

最終整個任務交付的文件數量達到了驚人的 10 多個，包括 xls、ppt、html 網頁，以及對應的 .md 版本。

▲ Agent Team 生成的財務預算表格，包括項目預算總表、現金流預測、票價和贊助定價模型，以及成本明細臺賬。

接下來再說一下這次 Mavis 的另一大特性：能連接到聊天平臺，還支持多任務。

和 MiniMax 此前已經支持的 OpenClaw、Hermes Agent 類似，Mavis 本身也可以通過微信、飛書這兩個 IM 管道來實現任務分配。接入流程也極度簡化，只要點擊設置按鈕、掃碼、命名，我們就能在微信/飛書里面使用 Mavis 了。

一般的 Agent 產品連接到 IM 當中里，我們給他安排一項需要長時間完成的任務，往往是消息發送之后，就不能再和他咨詢別的問題。

一部分原因，在于這些 agent 時無法同時打開多個對話窗口；另一個原因則是 agent 工作模式的限制，在一個會話里運行多個任務，極易出現語境錯亂的情況，導致上下文污染。

MiniMax 的解決方案，是把「秒回」和「執行」的邏輯解耦。

APPSO在飛書里讓它研究一下最近石油漲價；任務開始之后，我又讓它研究最近一個月硅谷 AI 巨頭發布的重要產品。

Mavis 沒有停止之前的任務，直接告訴我新任務已經完成了，而石油漲價的任務還在處理。

這正是 Mavis 的另一大設計理念：上下文隔離的好處。

每個 Agent Team，以及 team 里的每個 agent，都只看到跟自己任務相關的信息摘要，只有需要細節的時候才會去讀全文。

這么做一來 token 成本受控，團隊規模再大，上下文也不容易撐爆；二來防上下文污染，agent 在搜索中接觸到的錯誤信息不會讓全隊陣亡。

在最極限的場景下，我們試過通過飛書在極短時間內給他分配 8 個任務，都沒有發生語境錯亂的情況。

整個體驗，很像跟一個認知帶寬極高的同事共事：不僅能秒回信息、同時后臺干活也不會被打斷。想了解一下進度，大可直接問，不用擔心干擾它的「心流」。

處理不同會話的 Agent，只看到和自己任務相關的信息，不會共享一個不斷膨脹的對話歷史。

可以說，Mavis 實現了一個從 IM 渠道，到任務中樞，再到分子任務里的每個分子 agent——端到端的上下文隔離。

最后，它在解答 AI 大廠本月新發布和具身智能重要產品的同時，也順利完成了石油任務這條主線程，給了我們一版詳細的報告，里面甚至提到最近日本薯片包裝要變成黑白的消息。

經過實測之后，你有沒有發現，Mavis 這套編排策略，其實有點像此前火過一陣的「三省六部」skill？

每個角色做什么，何時啟動、何時交接，將會由引擎層面的狀態機來決定，而非模型的黑箱自己「拍腦門」說了算。

說白了，這就是在多 agent 工作編排當中，用工程層面的可控性、嚴密性、確定性，來根治模型的不可控、隨機性。

這種思路，徹底解決了過去的 agent/模型「既當裁判又當選手」的經典問題。

額度統一，Agent 管夠

實測 Mavis 之后，再說說 MiniMax 做的另一件同樣重要的事情，影響所有的付費用戶：這次，Token Plan 和 Agent Plan 合并了。

合并了之后，無論是普通用戶的「日常使用」，比如官網上和 App 里對話和使用 Agent，還是接入官方 API 來調用其他工具（例如 coding 產品或 OpenClaw/Hermes Agent）——現在都可以使用統一的套餐額度了。并且，無論是 M2.7 以及后續的旗艦模型，還是音樂、視頻、語音的多模態模型，全部包含在這一個套餐之下。

所有額度共享，怎么花用戶可以自己說了算。MiniMax 還給出福利：此前同時訂閱兩個方案的用戶，將會額外送一個月的會員。

為什么要做這件事？站在用戶視角其實還是很合理的。

說白了，Agent 時代，用戶付費動機來自于對「模型算力」的需求，而這些需求的場景隨著模型在 coding、agent、多模態能力上的提升，只會變得愈發多元，會自然而然地發生在模型廠商的產品里（官網、獨立產品、CLI）以及產品之外（接入外部 API 的獨立部署的 agent）。

這其實也是各大 AI 巨頭都在面對的問題：OpenAI 目前用戶訂閱和 API 計費還是分開的，Anthropic 同樣；至于更小的 agent 創業公司，則是用自己的訂閱費用去代替用戶支付支付底層的 api 費用。

這一次，MiniMax 先一步把自己產品矩陣內部的墻拆掉了。而 APPSO 認為，在模型極度商品化、用戶總是一窩蜂涌向最新、最便宜模型 API 的今天，這種統一套餐的策略，反而有助于為模型廠商維護用戶忠誠度。

再回到產品本身。

如前所述，APPSO 正在寫一篇關于「對 coding/agent 認真的模型廠商，必須要做自己的 coding/agent 產品」的文章。MiniMax 可以說是雖遲但到。

在今天，Mavis 也不是第一個押注多 agent 架構的產品。在過去半年里，ChatGPT、Manus、Genspark 等公司都參與到這場「多 agent」的戰爭當中。

而在實測跑完之后，APPSO 的感受是，Mavis 在「產品自己跑完一個極復雜/極長程任務」這件事上，做的比同行效果更好、架構也更穩定。當其它產品的多 agent 停留在提示詞編排、拆任務上的時候，Mavis 做出了工程層面的對抗式硬約束——這帶來的體感差異，足夠明顯。

不過，這套架構看起來美好，也有繞不開的現實：貴。

MiniMax 在技術博客中提出了多 agent 的「共識成本」(Cost of Consensus) 。用人話來說，幾個 agent 彼此「制衡」，的確讓工作過程和結果更靠譜，但取得共識的過程是有成本的，token 消耗數倍于單一 agent；而且就像吵架一樣，吵急眼了也有可能偏離主題，準確率不升反降。

根據 MiniMax 梳理，其 Agent Team 架構具體來說有三類成本：

一是交接成本。信息在 agent 之間傳遞時需要重新組織，每次交接都要把信息「翻譯」為下一個 agent 能用的形態，耗費 token；

二是共享（上下文信息的）成本。上下文隔離設計，一定程度上就是為了控制這一成本。但即便每個 agent 只看其他 agent 傳遞過來的「摘要」，隨著 Agent Team 的量級擴大，存儲和分發摘要都會帶來成本。

三是聚合成本。其實這個道理，APPSO 一直很想跟大家講：別以為那種成百上千個 skill、設計了極其復雜的「三省六部」制度的工作流就是卍解——很多時候并非如此，反而可能中了 token 廠商的計……你的確讓工作變得更細致了，但你同時也需要花更多的 token去聚合和整理最終結果。

這些成本加起來，意味著多 agent 這件事從來不是「越多 agent 越好」的簡單邏輯。

但換個角度看：信息交互越復雜的工作，往往本身價值就越高。一份需要多方核查、反復校驗的深度研究報告，和一個隨手問的問題，或許就不應該用同一套邏輯去衡量成本。Mavis 貴，貴在它認真，而認真處理的那些任務，本就值得這個價。

寧愿花更多成本去確保萬無一失，也不愿意糊弄了事，這才是復雜任務背后的高價值用戶所看重的。

當然，MiniMax 團隊也做了一些工程設計去避免程序冗余帶來的 token 浪費。

MiniMax 對用戶的建議是：Agent Team 是為「貴且復雜」的任務準備的，是一個策略選項，而非默認選項。用戶自行判斷任務的復雜程度、鏈路長短、風險、經驗復用的價值——這些越高，越值得用 Agent Team。反之，完全可以用單 agent，甚至普通的 chat。

多 Agent 一定多聰明嗎？非也。但 Mavis 的意義，是讓那些真正復雜、知識密集型的任務，不給模型自己拍腦門，而是交給一套經過驗證的，有對抗、有核查、有權責劃分和獎懲制度的工程系統。

它不一定讓 AI 變得更聰明，但絕對會讓 AI 更難偷懶——這也是大模型本身長期存在的老大難。

畢竟在真正的人際工作中，我們其實真的不需要同事多聰明……只是別偷懶，別耍小聰明，往往就夠了，不是嗎？

文｜杜晨、張子豪