我下了一個(gè)任務(wù)，agent 開啟了 plan 模式，規(guī)劃了 7 個(gè)步驟。

我批準(zhǔn)了，它開始跑，跑了三個(gè)步驟，然后停下來匯報(bào)：「我已經(jīng)完成了 1、2、3，結(jié)果有這些和哪些……請(qǐng)問是否繼續(xù) 4、5、6、7？」

我說繼續(xù)。它又跑了兩步，然后又停了下來：「我已經(jīng)完成了 4、5，結(jié)果有這些和哪些……請(qǐng)問是否繼續(xù) 6、7？」

一個(gè)晚上下來，讓 agent 干點(diǎn)長程的任務(wù)，并沒有長程的效果，對(duì)話框來回來去的全都是「繼續(xù)」。

很長時(shí)間以來，我在使用各種 Agent 完成工作，就是這樣的體驗(yàn)。

這種體驗(yàn)很不合邏輯。雖然「停下來確認(rèn)」是個(gè)與 AI 共事時(shí)的好工作習(xí)慣，但在很多任務(wù)當(dāng)中我從來沒主動(dòng)要求它停，但它就是會(huì)停下來。

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

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

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

多 Agent 系統(tǒng)，需要一套持續(xù)運(yùn)行、持續(xù)維護(hù)，并且多個(gè) agent 之間不會(huì)「媾和」的可靠基礎(chǔ)設(shè)施。這就是 MiniMax 在做的事。

實(shí)測(cè)體驗(yàn)：讓 agent 給對(duì)方「挑刺」

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

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

前段時(shí)間，APPSO 正好在研究一個(gè)課題：「所有對(duì) Coding/Agent 有所抱負(fù)的模型廠商，都要做自己的獨(dú)立 Coding/Agent 產(chǎn)品」。

（沒錯(cuò)，MiniMax 在此之前是個(gè)反面案例，但沒想到文章還沒發(fā)出來，就已經(jīng)證明自己了！）

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

這個(gè)任務(wù)拆分出了 5 個(gè) worker，每個(gè) worker 完成任務(wù)后，都會(huì)整理結(jié)果交給 leader（顯示狀態(tài)「Mavis 發(fā)給 General」或者「General 發(fā)給 Mavis」等等。）

有一個(gè) worker，運(yùn)行了 12 分鐘還沒有返回結(jié)果。APPSO 注意到，這個(gè) leader等不及了，于是發(fā)了一條 bash 命令檢查其工作狀態(tài)：

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

Verifier 很快就找到了錯(cuò)誤！其中一個(gè) verifier 發(fā)現(xiàn)了對(duì)應(yīng)的 worker 交付成果中存在明確的數(shù)據(jù)錯(cuò)誤，給出了「失敗」的判罰。緊接著，與之對(duì)應(yīng)的 worker 重新啟動(dòng)（顯示為運(yùn)行中，會(huì)有一個(gè)藍(lán)色小圈的標(biāo)識(shí)）。

點(diǎn)進(jìn)對(duì)應(yīng)的 worker 工作區(qū)觀察一下它的思考過程：「verifier 拒絕了我之前的交付成果，基于以下三個(gè)錯(cuò)誤……我需要返回去重新核查關(guān)鍵事實(shí)，并檢查修正具體的數(shù)字問題……」

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

這樣的來來回回，在五組 1v1 的 agent 對(duì)抗當(dāng)中，總共發(fā)生了數(shù)十次。過程中，Mavis 還表示這次「學(xué)到了新東西」，并順手更新了一下記憶。

上一個(gè)任務(wù)先跑著，我們?cè)匍_啟一個(gè)新的深度研究，基于權(quán)威口徑數(shù)據(jù)分析五一假期的旅游市場(chǎng)，并交付一份多維度分析報(bào)告。

這個(gè)研究比剛才的任務(wù)更加復(fù)雜。而且因?yàn)橐掷m(xù)對(duì)抗，Agent Team 在深度研究上所花的時(shí)間，也遠(yuǎn)比一般的單 Agent 要長。

但最終呈現(xiàn)的報(bào)告，和其它 AI 深度研究交付的內(nèi)容相比起來，確實(shí)干凈不少，也更加可信。

最近 APPSO 籌備了很多場(chǎng)線下活動(dòng)，做策劃想方案一直是個(gè)難題。我們也把這個(gè)任務(wù)交給 Mavis 看看效果怎么樣。

我需要策劃一場(chǎng)在廣州舉辦的 AI 開發(fā)者線下沙龍，請(qǐng)你盡可能全面的給我提供多個(gè)適合百人千人科技活動(dòng)的場(chǎng)地及大概報(bào)價(jià)，以及抓取同類活動(dòng)的信息，然后幫我策劃這張 AI 活動(dòng)的主題，宣傳，運(yùn)營整個(gè)全部的工作，幫我把這些都整理成一份嚴(yán)格的商業(yè)計(jì)劃書格式，以及一個(gè)符合主題特色，設(shè)計(jì)精美的網(wǎng)頁。

光是制定計(jì)劃的時(shí)間，就比之前的深度研究任務(wù)要長。Mavis 回復(fù)「這個(gè)任務(wù)規(guī)模很大，需要多個(gè) Agent 并行工作——場(chǎng)地調(diào)研、競(jìng)品抓取、主題策劃、商業(yè)計(jì)劃書、網(wǎng)頁開發(fā)。」

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

給我長報(bào)告的同時(shí)，最好還能給我起草一份初步的正式合同，和場(chǎng)地的合作、以及和邀請(qǐng)嘉賓的合作、等等可能涉及的合同，還有前期的財(cái)務(wù)表格，再給我一份用來匯報(bào)這套方案的 PPT，越詳細(xì)越好。

Agent Team 收到新需求后，會(huì)進(jìn)一步完善計(jì)劃并啟動(dòng)更多的工作流，最后，我們啟動(dòng)了多達(dá) 9 個(gè)并行任務(wù)。

我們點(diǎn)開 Mavis 的思考過程，能看到里面有大量的 agent 之間互相發(fā)送的消息，這些 Agents 會(huì)在專門的 Team Engine 下工作，傳遞彼此的狀態(tài)，有的在等待、有的在執(zhí)行、有的在驗(yàn)證。

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

最終整個(gè)任務(wù)交付的文件數(shù)量達(dá)到了驚人的 10 多個(gè)，包括 xls、ppt、html 網(wǎng)頁，以及對(duì)應(yīng)的 .md 版本。

▲ Agent Team 生成的財(cái)務(wù)預(yù)算表格，包括項(xiàng)目預(yù)算總表、現(xiàn)金流預(yù)測(cè)、票價(jià)和贊助定價(jià)模型，以及成本明細(xì)臺(tái)賬。

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

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

一般的 Agent 產(chǎn)品連接到 IM 當(dāng)中里，我們給他安排一項(xiàng)需要長時(shí)間完成的任務(wù)，往往是消息發(fā)送之后，就不能再和他咨詢別的問題。

一部分原因，在于這些 agent 時(shí)無法同時(shí)打開多個(gè)對(duì)話窗口；另一個(gè)原因則是 agent 工作模式的限制，在一個(gè)會(huì)話里運(yùn)行多個(gè)任務(wù)，極易出現(xiàn)語境錯(cuò)亂的情況，導(dǎo)致上下文污染。

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

APPSO在飛書里讓它研究一下最近石油漲價(jià)；任務(wù)開始之后，我又讓它研究最近一個(gè)月硅谷 AI 巨頭發(fā)布的重要產(chǎn)品。

Mavis 沒有停止之前的任務(wù)，直接告訴我新任務(wù)已經(jīng)完成了，而石油漲價(jià)的任務(wù)還在處理。

這正是 Mavis 的另一大設(shè)計(jì)理念：上下文隔離的好處。

每個(gè) Agent Team，以及 team 里的每個(gè) agent，都只看到跟自己任務(wù)相關(guān)的信息摘要，只有需要細(xì)節(jié)的時(shí)候才會(huì)去讀全文。

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

在最極限的場(chǎng)景下，我們?cè)囘^通過飛書在極短時(shí)間內(nèi)給他分配 8 個(gè)任務(wù)，都沒有發(fā)生語境錯(cuò)亂的情況。

整個(gè)體驗(yàn)，很像跟一個(gè)認(rèn)知帶寬極高的同事共事：不僅能秒回信息、同時(shí)后臺(tái)干活也不會(huì)被打斷。想了解一下進(jìn)度，大可直接問，不用擔(dān)心干擾它的「心流」。

處理不同會(huì)話的 Agent，只看到和自己任務(wù)相關(guān)的信息，不會(huì)共享一個(gè)不斷膨脹的對(duì)話歷史。

可以說，Mavis 實(shí)現(xiàn)了一個(gè)從 IM 渠道，到任務(wù)中樞，再到分子任務(wù)里的每個(gè)分子 agent——端到端的上下文隔離。

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

經(jīng)過實(shí)測(cè)之后，你有沒有發(fā)現(xiàn)，Mavis 這套編排策略，其實(shí)有點(diǎn)像此前火過一陣的「三省六部」skill？

每個(gè)角色做什么，何時(shí)啟動(dòng)、何時(shí)交接，將會(huì)由引擎層面的狀態(tài)機(jī)來決定，而非模型的黑箱自己「拍腦門」說了算。

說白了，這就是在多 agent 工作編排當(dāng)中，用工程層面的可控性、嚴(yán)密性、確定性，來根治模型的不可控、隨機(jī)性。

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

額度統(tǒng)一，Agent 管夠

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

合并了之后，無論是普通用戶的「日常使用」，比如官網(wǎng)上和 App 里對(duì)話和使用 Agent，還是接入官方 API 來調(diào)用其他工具（例如 coding 產(chǎn)品或 OpenClaw/Hermes Agent）——現(xiàn)在都可以使用統(tǒng)一的套餐額度了。并且，無論是 M2.7 以及后續(xù)的旗艦?zāi)Ｐ?，還是音樂、視頻、語音的多模態(tài)模型，全部包含在這一個(gè)套餐之下。

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

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

說白了，Agent 時(shí)代，用戶付費(fèi)動(dòng)機(jī)來自于對(duì)「模型算力」的需求，而這些需求的場(chǎng)景隨著模型在 coding、agent、多模態(tài)能力上的提升，只會(huì)變得愈發(fā)多元，會(huì)自然而然地發(fā)生在模型廠商的產(chǎn)品里（官網(wǎng)、獨(dú)立產(chǎn)品、CLI）以及產(chǎn)品之外（接入外部 API 的獨(dú)立部署的 agent）。

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

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

再回到產(chǎn)品本身。

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

在今天，Mavis 也不是第一個(gè)押注多 agent 架構(gòu)的產(chǎn)品。在過去半年里，ChatGPT、Manus、Genspark 等公司都參與到這場(chǎng)「多 agent」的戰(zhàn)爭當(dāng)中。

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

不過，這套架構(gòu)看起來美好，也有繞不開的現(xiàn)實(shí)：貴。

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

根據(jù) MiniMax 梳理，其 Agent Team 架構(gòu)具體來說有三類成本：

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

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

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

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

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

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

當(dāng)然，MiniMax 團(tuán)隊(duì)也做了一些工程設(shè)計(jì)去避免程序冗余帶來的 token 浪費(fèi)。

MiniMax 對(duì)用戶的建議是：Agent Team 是為「貴且復(fù)雜」的任務(wù)準(zhǔn)備的，是一個(gè)策略選項(xiàng)，而非默認(rèn)選項(xiàng)。用戶自行判斷任務(wù)的復(fù)雜程度、鏈路長短、風(fēng)險(xiǎn)、經(jīng)驗(yàn)復(fù)用的價(jià)值——這些越高，越值得用 Agent Team。反之，完全可以用單 agent，甚至普通的 chat。

多 Agent 一定多聰明嗎？非也。但 Mavis 的意義，是讓那些真正復(fù)雜、知識(shí)密集型的任務(wù)，不給模型自己拍腦門，而是交給一套經(jīng)過驗(yàn)證的，有對(duì)抗、有核查、有權(quán)責(zé)劃分和獎(jiǎng)懲制度的工程系統(tǒng)。

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

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

文｜杜晨、張子豪