Mavis：讓兩個Agent“互掐”，比一個聰明Agent靠譜

前幾天看姚順宇在張小珺最近那期4小時訪談里說，他在Google DeepMind主要做ML Coding和Long Horizon（長程任務）。后者就是讓模型能夠連續干好幾個小時甚至好幾天才能完成的復雜活。他說的是讓單個AI變得更聰明。

但同樣的事情，另一條路徑上也在發生。這件事現在像個隱秘的共識，所有頭部大模型公司都在做。

OpenAI從去年起推了讓開發者搭多AI協作的工具集，又補上了讓AI跑長任務的能力。Anthropic做了兩套獨立的產品，一套在他們的對話產品里、一套在Claude Code里的Agent Teams，都是讓一個AI帶一堆AI干活的架構。Google也推了開發框架，還和一百多家公司一起搞了讓不同廠商的AI能互相通訊的協議。

這些公司不約而同地造同一個東西，試圖回答同一個問題：長程任務該怎么靠譜地交付。

昨天MiniMax發布了Mavis（MiniMax as a Jarvis），同步出了一份相當詳盡的技術報告。讀完發現他們在這個問題上走得很遠，有了相當成熟的解法。

所以今天想聊聊這事。

寫的不審，審的不寫

先講一條我最近一個月為了讓我的AI寫作工作流更加Harness而調整的一條流程規則。

在我的AI寫作工作流了內容寫完之后一直有要求按規則審校的流程存在。但我最近改的規則是：審校必須啟動一個獨立的Agent，寫內容的AI不審自己的內容。這條規矩貼在我所有寫作項目的CLAUDE.md里。原因是踩過太多次坑。同一個AI寫完一篇文章，緊接著讓它自己檢查，它會誠懇地告訴你「我又通讀了一遍，沒問題」。但它檢查的對象，就是它自己剛剛構造出來的現場。

我后來把審校AI單獨拎出來，寫的不審，審的不寫。

上面這張是我每次寫完稿啟動三審三校時的截圖。兩個審校AI被丟到后臺并行跑，各自只看產出文件，看不到我和寫作AI之間的過程對話；它們出意見之后由一個編輯AI合稿。整個過程從頭到尾，寫內容的AI不參與任何一輪審校。

讀到MiniMax官方對Mavis的描述時我笑了一下。這家公司花了一整份技術報告論證一件事：別讓AI當自己的裁判。他們的判斷是「多Agent系統是runtime，不是prompt編排」。意思是讓多個AI一起干活，關鍵不是給它們寫更好的指令，而是給它們搭一個能長期運行、能管它們的底座。

這個底座的核心機制叫Worker和Verifier的對抗循環。一個AI干活，另一個AI找茬，兩個AI心思完全相反。

我從公眾號寫作里踩坑摸出來的一條樸素規則，跟一家頭部大模型公司從工程嚴謹性推出的狀態機設計，落點完全一樣。他們做的事比我深得多，把流程紀律做成了由程序自動調度的對抗循環。

Agent干長活，都是怎么爛尾的

要看懂為什么需要讓兩個AI互掐，得先看單個AI干長活的時候是怎么壞掉的。

第一個癥狀是「上下文焦慮」。

舉我熟的場景。我用AI輔助寫一篇文章時，整個流程不是一步：讀brief、做多源調研、列大綱、寫初稿、跑獨立審校、按反饋改稿、生成配圖、寫小標題、做封面圖、最后排版發布，前后十幾步。

任何一步只要交給AI接著上一步往下走，大概率出現兩種情況。要么它把十幾步壓成兩三步草草交付；要么它每做一步就停下來問你「123已完成，要不要繼續做4」。你說「繼續」。它又做了兩步停下來。一個晚上下來，你有一半時間在打「繼續」、「繼續」、「繼續」。

AI對一個任務什么時候算「做完」的判斷是模糊的。它不知道你的真實預期，所以干一半就停下來確認，寧可啰嗦也不冒險。

姚順宇在訪談里講過一個挺貼的哲學，原話是「用短的context去訓練，但讓它能做長的context的事」。意思是讓AI在長任務里不漂移、不停下，關鍵不在上下文窗口做多大，而在它會不會自己管理上下文：該存的存起來、該扔的扔掉。

第二個癥狀更隱蔽。AI干長任務的時候，會逐步漂移。

我做橙皮書的時候踩過這個坑。讓一個agent幫我寫一整章AI技術解讀，開頭是技術分析的語氣，寫到第三節能不知不覺變成營銷文案的口吻；讓它列參考資料，它會把自己之前搜過的二手緩存當成一手來源貼上去。這時候你追問它，它會誠懇地回頭自檢，但它檢查的對象，就是它自己剛剛漂移生成的現場。一個被自己污染過的記憶里，做不出真正的糾偏。

第三個癥狀是長任務期間沒法快速響應你。在微信、飛書這種IM場景下，你發一條消息就期待幾秒內有反饋。但很多任務天然需要幾分鐘甚至更久。AI要么給一個淺答案應付，要么讓你盯著對話框等十幾分鐘。MiniMax官方文章里說，「我的Agent怎么不回我了」是他們收到的大量用戶反饋。我估計很多人不管是用OpenClaw還是Hermes都感受過這種痛苦。Mavis的解法是把「秒回用戶」和「執行任務」拆開：主AI收到消息先快速應一聲「收到，5件事我去拆，完成后回來找你」，然后把任務派到后臺并行跑，關鍵節點主動匯報。整個體驗更接近一個能秒回微信、同時后臺還在幫你干活的同事。

第四個癥狀最容易被忽視，是角色分工這件事其實沒真正發生。

舉我自己的例子。我有幾十個公眾號寫作相關的skill：選題、調研、初稿、審校、配圖?？雌饋矸止ね?。但它們全部跑在同一個Claude里，用同一套記憶，看同一組文件。本質上還是一個AI在輪班。每「換」一次角色，前面那個角色的影子都還在。

官方公眾號里有句話點得很準：「角色扮演不等于角色分工」。真正的分工得讓每個AI從一開始就只做一件事，連工具集都不一樣。會計用Excel，設計師用Figma，他們的工具不重疊，能力邊界清晰，長期跑下來才有復利。

這四個癥狀加起來導致的結果就是：單AI干長任務越長越不靠譜。倒不是AI不夠聰明，是結構上就出了問題。

姚順宇還說過一句話挺到位：「Coding是AI使用工具和環境交互的一個很好的抽象。它的回饋信號清晰（運行成功或失?。祿浞??！狗催^來讀這句話我就明白了，寫代碼這種事最容易讓「互相挑刺」機制跑通。因為有外部的、確定性的對錯信號：代碼能不能跑、測試過沒過，機器說了算。在寫作、研究、辦公文檔這些靠主觀判斷的場景里，光靠AI自己說「我檢查過了」根本不算數。

得有個外部的東西來兜底。MiniMax選的兜底方式，就是讓另一個AI來挑毛病。

Mavis較真的兩件事

MiniMax在公眾號文章里把Mavis和OpenAI、Google、Claude Code的同類方案做了對比。Mavis的整體架構是Owner拆任務、Worker干活、Verifier挑刺三角，但他們覺得做得最不一樣的，落在兩件事上。

第一件：讓兩個AI心思相反

Mavis架構里，Worker的目標是把活兒趕緊干完；Verifier的目標是把活兒挑回去重做。兩個AI都以「結束」為目標，但一方結束會觸發另一方啟動。Worker覺得自己干完了，Verifier立刻開始挑刺。Verifier挑出問題，Worker被自動叫回來修。修完Verifier再檢查，過了才算真的完成。

我自己寫過一個叫darwin-skill的工具，就是干Verifier的活。它會讀一個SKILL.md文件，從結構和效果兩個維度8個指標打分，挑問題、給優化建議。但我把它做成了一個事后跑的獨立工具，跟skill的生產過程是脫離的。darwin能告訴我「這個skill哪里寫得糙」，但寫skill的過程本身沒有挑刺嵌在里面。Mavis的Verifier是嵌在生產狀態機里的，每一步產出立刻挑，挑不過就自動叫回來。這一步差距很關鍵。

官方原話里有一句我蠻認同：「很多框架里的驗證環節是可選的附加步驟，在我們這里它是架構的核心。」

這話是Mavis的設計宣言。對比一下，Anthropic在Multi-Agent Research System博客里講的方案，是Lead Agent給Subagent分發任務并基于outcome評分，質量主要靠Lead的判斷；OpenAI Agents SDK的Handoff是接力式的，A把任務交給B，B再交給C，每一棒都不回頭。Mavis選了一條不一樣的路：不要單中心評審，讓Worker和Verifier直接對掐。

第二件：調度靠程序，不靠AI拍板

想象一個工廠流水線。工人在工位上做完一件活，按一下綠燈，活就傳到檢驗員那里。檢驗員要么貼「通過」標簽放行，要么貼「打回」標簽讓工人重做。整個流水線是機器在調度。傳送帶的速度、檢驗的時機、什么時候停下叫主管來，都不靠工人自己判斷。

Mavis就是這種流水線。每個「工人」是一個AI，每個「檢驗員」是另一個AI，但兩個AI之間不直接說話，全程靠一個叫Team Engine的程序在中間調度。這個程序不是AI，是確定性的代碼。這件事很關鍵：它意味著系統的可靠性不依賴某個AI那一刻清醒不清醒，而是寫死在程序里。

我讀這張架構圖的時候，覺得最關鍵的不是流程圖本身，是幾個被低估的細節：

• 任務被切成一批一批跑。同一批里的活兒真的并行，各干各的，互不打擾。下一批要不要啟動，看上一批是不是全部通過驗證。

• 兩個AI之間不直接通訊，全程靠程序中轉。Worker完成產出，程序自動把產出推給Verifier；Verifier說有問題，程序自動叫Worker重做，而且讓它從上次失敗的狀態繼續，不用從頭來。這點我蠻有共鳴。我做橙皮書pipeline時這件事是手動的：哪一章審校沒過，我得自己把反饋貼回去跟寫章節的agent講「之前哪里有問題、應該怎么改」。每本書十幾章，手動銜接的次數不少。MiniMax把這步做成了Engine自動完成的事。

• 有重試上限。兩個AI萬一陷入「改改改改不完」的死循環，程序會自動把決策升級，必要時叫人類來拍板。我的darwin-skill里也做過同樣的事：自動優化迭代有上限，連續幾輪分數不漲就主動停下，不會讓agent無限消耗token。區別是darwin的上限是給skill事后優化兜底的，Mavis把上限內建到了生產任務的運行時調度里。 ## 對照著看，我自己的skill漏在哪

寫到這里我想到了不少我之前做skill設計時一些零碎思考的影子。Mavis文章里點到的幾個組件，我自己各做了一兩個，但沒有一個像他們那樣把全套打通。

第一個是開頭講的寫作三審三校。寫作AI寫完，我自動起兩個獨立審校AI看產出文件，加一個編輯AI合稿。Worker-Verifier的雛形，但是流程紀律，每次手動觸發，不是runtime。

第二個是huashu-book-pdf，前面講過的橙皮書電子書skill，已經出版7本。每本書都跑了多Agent并行寫章節加三審三校的流程，再構建EPUB/PDF上架微信讀書。多Agent并行加挑刺這兩件事我都做了，但調度是手動的，不是Engine在跑。

第三個是darwin-skill。前面講過它干的就是Verifier的活，區別是跟生產過程脫離。它額外做了一件事，是hill-climbing（山丘攀登）式的優化：改一版、跑測試，分數漲了就保留，跌了就回滾。這是「挑刺加自動迭代」的閉環，但它的對象是skill本身，不是任務產出。

第四個是huashu-data-pro，我做數據分析的skill。收到數據先做一遍理解，然后選3到5個不同領域的專家角色并行分析，結果匯總后生成報告。我自己用的時候挺爽。但看完Mavis我意識到它有結構性缺口：我只做了拆任務和分頭干，沒有挑刺。多個專家各自的結論誰來核對？我設計的時候默認是用戶。這意味著我把質量門禁丟給了人，沒丟給系統。

把這四個放一起看，Mavis做的事就清晰了。我手里有審校的紀律、有橙皮書的并行加挑刺pipeline、有專門給skill挑刺的darwin、有多專家分頭干的data-pro。每個都做對了一兩件事，但全是單點。Mavis把這些擰成了同一套底座：挑刺嵌進生產過程、調度靠程序、每個AI有持續身份。

而且Mavis把每個AI做成有持續身份的「同事」。下次再開這個AI，它能記得上次干到哪里、犯過什么錯。這跟我那些零散skill的差別本質上是「同事」和「工具箱」的差別。

這種「我設計漏了一環、看別人補上了」的體感，比任何架構對比都更讓我信服多AI協作的核心從來不是「開幾個進程」，是結構。

Agent協作的下半場，是從工具到同事

讀完技術報告我自己有個判斷：AI協作的下一個階段，是把AI從「工具」變成「同事」。

工具是單次的，用完即棄，下次重新交代一遍背景。我那些零散skill大多是工具，能辦事，但每次都得手動起來、手動收尾、手動銜接。

同事是有持續身份的：它知道你之前讓它干過什么、犯過什么錯，下一次任務能記著上次的反饋接著干。這才是Mavis做「每個AI自帶身份、筆記本、記憶、交付物」這件事的本質，把AI拉進一個有歷史、有積累的關系里。

跟「同事」配套的不只是記憶，還得有驗收標準、可調度的流水線、可復盤的操作日志。這就是Mavis那一整套Worker-Verifier-Engine的存在意義。給AI協作搭底座比寫Prompt重得多，但只有這條路才能讓AI真正進入長期同事的形態。一個有記憶、有技能、有驗收標準、能在長任務里復用經驗的AI團隊，比一個無所不能的超級指令更有用。

MiniMax官方在文末也補了一句：「Team不是默認選項，是策略選項。任務越短、越低風險、越確定，單Agent甚至腳本就夠了。」

MiniMax這次順帶把訂閱做了合并：TokenPlan和Agent Plan合一份，CLI、API、Agent都打通，M2.7模型、音樂、視頻、語音都包含在內。Credits額度在Agent和API之間可以共享，之前同時訂閱了兩個Plan的用戶額外送一個月會員。背后邏輯和Mavis的整體設計一致：一份用戶記憶、一組技能、一套額度，在不同入口都能用。

回到開頭那個觀察。四家AI實驗室都在朝同一個方向走，但每家路徑不一樣。沒有誰的方案是定論，但都在補同一塊基礎設施。

我猜接下來一年，會看到更多人發現自己手里那些零散的「AI協作小竅門」，被一個個寫進產品。

這件事我挺樂意看到。

MiniMax Mavis桌面端下載：agent.minimaxi.com/download

參考資料：

• MiniMax官方tech blog《MiniMax Agent Team - 為長程任務，持續進化而生》：https://zhuanlan.zhihu.com/p/2037877345634276836

• MiniMax官方公眾號文章《一個 AI 還是不夠》（Agent Team自己采訪自己的Q&A版）：https://mp.weixin.qq.com/s/TIL7o92f71DsPPLWT4_37A

• Anthropic《How we built our multi-agent research system》：https://www.anthropic.com/engineering/multi-agent-research-system

• Anthropic《Managed Agents》（原話「session is not Claude's context window」）：https://www.anthropic.com/engineering/managed-agents

• Anthropic《Claude Code on Team and Enterprise》（含Claude Code Teams機制）：https://www.anthropic.com/news/claude-code-on-team-and-enterprise

• Google Agent Development Kit (ADK)官方文檔：https://google.github.io/adk-docs/

• Google A2A協議規范：https://a2a-protocol.org/latest/specification/

• 張小珺訪談姚順宇《對姚順宇的4小時訪談：請允許我小瘋一下！》（B站）：https://www.bilibili.com/video/BV1YR5E6EE9o/