時間節點選得很微妙。就在OpenAI、Google相繼推出各自的Deep Research產品、Manus
橫空出世引發廣泛討論的當口，這篇論文在GAIA、BrowseComp、HLE等多個權威基準測試上給出了讓人難以忽視的數據——MiroFlow以開源身份，在幾乎所有榜單上壓過了商業競品。FutureX榜單上，MiroFlow拿到42.5分，第二名ChatGPT-Agent只有21.9分，差距超過一倍。
這不是一個玩具級別的實驗室演示。
大模型的天花板，其實是"單打獨鬥"的天花板論文開篇點出了一個被很多人忽視的結構性問題：現在的大模型，幾乎都在"自給自足"地工作。它不調用外部工具，不與環境交互，所有能力全靠訓練時壓進參數裡的知識。這種方式在短問答任務上表現不錯，但面對真實世界的複雜需求——查最新數據、操作文件、多步推理、跨工具協作——就開始力不從心了。
作者用"performance has begun to plateau"來描述這種瓶頸。這不是模型不聰明，而是架構本身的天花板。就像一個再厲害的獨行俠，也比不過一個組織良好的團隊——不是智力問題，是協作結構的問題。
解法因此不是"把模型做得更大"，而是"把模型變成一個系統"。
三層架構：從"一個腦子"到"一套組織"MiroFlow的核心設計是一個三層架構，從下往上分別是基礎層、智能體層、控制層。
基礎層（Foundation Tier）提供所有智能體共用的底層能力：語言模型後端、工具集、輸入輸出處理器。支持的模型覆蓋了GPT系列、Claude、Qwen等主流選手，工具則通過MCP協議接入，包括網路搜索、代碼執行、圖像理解、影片分析、音頻轉寫等七類。
智能體層（Agent Tier）是整個系統的核心。每個智能體節點都是獨立的工作單元，擁有自己的上下文、提示詞、工具集和I/O處理器，節點之間通過結構化消息通信。這種設計讓智能體層與控制層徹底解耦——你可以像搭積木一樣增減、替換任意節點，而不需要動整個系統的骨架。
控制層（Control Tier）負責全局調度：根據用戶輸入和預定義的智能體圖配置，編排整個任務流程，同時維護日誌和檢查點，確保結果可復現。
論文用一個深度研究的例子說明這套流水線如何運轉：主智能體收到用戶問題後，先做查詢增強（理解意圖、補全約束），再制定執行計劃，然後把專項子任務（比如網頁瀏覽、代碼執行）分派給對應的子智能體，子智能體獨立完成後把結果匯總回主智能體，最後輸出格式化的答案。整個過程有條不紊，每一步都有明確的責任邊界。
智能體圖：比"鏈"和"樹"更自由的拓撲傳統的多智能體系統，要麼是線性的調用鏈，要麼是主從樹狀結構。MiroFlow引入了有向圖（Agent Graph）來描述智能體之間的協作關係。
用論文自己的說法，這叫"先聲明，再定義"——主智能體是入口節點，形成拓撲結構，負責發起任務並調用其他智能體和工具；每個智能體還可以定義自己的子智能體和工具，形成層級式的拓撲嵌套。
這套圖結構的好處是靈活性和可擴展性。節點之間的依賴關係可以精確定義：哪些任務必須串行，哪些可以並行。需要擴展功能時，只需加入新節點或調整圖結構，不必重新設計整個框架。
論文在附錄中給出了三個具體例子，展示了同一套框架如何分別用於短影片生成、複雜旅行規劃和求職材料製作——三個場景的圖結構完全不同，但底層調用的是同一套基礎設施。這種"配置即產品"的思路，讓MiroFlow不只是一個研究工具，更像是一個通用的Agent開發平台。
"重推理模式"：算力換精度的系統級實現單靠架構靈活還不夠，複雜任務需要更深的推理。MiroFlow引入了一個可選的重推理模式（Heavy-Reasoning Mode），本質上是通過擴展計算資源和推理時間來提高答案的可靠性。
這個模式有兩種策略。集成策略：同時啟動多個智能體並行處理同一子任務，最後用多數投票或加權投票合併輸出——可以是同質集成（多個GPT-5），也可以是異質集成（GPT-5加Claude 3.7），還可以用不同提示詞驅動同一模型產生多樣化輸出。驗證策略：讓生成器提出答案，驗證器給出反饋，形成疊代循環，滿足條件或達到輪數上限時停止。
實驗數據說明了效果：默認配置（單個GPT-5）在GAIA-Val上得71.9分；四個GPT-5集成後升至74.6；四個GPT-5搭配不同提示詞則達到75.0；10輪疊代驗證拿到73.0。提升幅度雖然不算驚人，但在這個精度區間裡，每一分都需要付出相當的工程代價。
重要的是，重推理模式只對被激活的子圖生效，其餘部分保持輕量運行。這避免了"全局加速"帶來的資源浪費，讓計算預算能精準投放到真正需要的地方。
穩定性才是真正的工程難題論文花了相當篇幅討論穩定性，這在AI研究論文裡並不常見，但恰恰是Agent系統最難啃的骨頭。
附錄里給出了大量失敗案例。智能體忽略了"房屋後方"這個空間約束，把方向搞反了；明明要求使用原始拼寫，智能體卻把"fresh basil"改成了"basil"；代碼執行時JSON解析出錯，智能體不去修復格式，反而認定是系統故障並直接編造了一個數字答案；搜索到的是28條引用的論文版本，而正確答案需要第29條引用，兩次搜索返回的是不同版本的文檔，導致結果完全不同。
這些失敗都指向同一個本質問題：智能體對錯誤的解讀能力太弱。它們把工具調用失敗誤判為數據不存在，把格式錯誤誤判為系統限制，然後用幻覺填補空缺。
MiroFlow的應對方案是三套機制的組合。消息規範化：在推理前把用戶任務改寫成清晰、無歧義的目標，補全缺失的約束（比如單位、範圍），輸出結果放入結構化欄位（最終答案、證據、警告），讓下游系統與穩定接口交互而不是原始文本。重試機制：對所有模型和工具調用採用"重試-降級-重放"策略，超時和限速都能平滑處理，重試失敗則自動切換到冗餘工具。故障隔離：三層架構本身就劃定了清晰的故障邊界，錯誤被捕獲後轉化為語義明確的失敗資訊傳遞給上層，而不是讓一個模糊的報錯消息迷惑整個系統。
消融實驗證明了這套機制的價值。去掉消息規範化後，GAIA-Val分數從71.9跌到68.5，標準差從1.21%上升到2.43%；去掉重試機制後，分數降到69.0，標準差升至1.70%。兩項改動都讓系統變得更差，也更不穩定。
"用多個專業智能體協作肯定比一個智能體更好"——這個直覺在實驗裡被部分推翻了。
在BrowseComp-200和HLE-200上，多智能體確實更好（68.3 vs 63.9，42.0 vs 40.6）。但在GAIA-Val上，單智能體反而勝出（74.8 vs 71.9）。
論文給出的解釋有說服力：GAIA的任務高度串行，每一步的結論都依賴前一步的完整上下文。多智能體拆分後，子智能體的上下文相互隔離，一旦某個子智能體出錯，錯誤資訊無法被後續的單智能體及時識別並修正，只能被動接收並繼續錯下去。附錄里有一個具體案例：詢問1949年某郵輪早餐菜單的水果，子智能體拿到的是低解析度圖片，提取出的菜單有誤，主智能體因無法直接訪問原圖而接受了這個錯誤結果；而單智能體在同一步驟發現圖片解析度不夠後，主動尋找了文字版菜單，最終給出了正確答案。
這個結論的實踐意義是：選擇單智能體還是多智能體，要看任務的拓撲結構。強串行依賴的任務，單智能體的全局上下文優勢更明顯；需要並行處理或專業化分工的任務，多智能體才真正發揮優勢。沒有放之四海而皆準的答案。
Q&A
Q1：MiroFlow憑什麼在開源框架里脫穎而出？
兩個關鍵詞：穩定性和通用性。很多開源框架在特定任務上能刷出高分，但換個場景就垮掉，或者換個人復現就失敗。MiroFlow的所有報告結果都是avg@3（三次運行取均值），且代碼完全開源。論文還專門驗證了OWL和AgentOrchestra的可復現性，結果這兩個框架的實際得分遠低於論文聲稱的數字——OWL相差15.8分，AgentOrchestra相差27.8分。MiroFlow把可復現性當成了硬指標而不是附註。
Q2：重推理模式會大幅增加成本嗎？
會，但有上限控制。重推理模式通過預算約束（生成智能體數量、驗證輪數、牆鍾時間）來限制資源消耗，且只對激活的子圖生效。論文給出的數據顯示，從單個GPT-5到四個GPT-5並行，GAIA-Val得分從71.9提升到74.6，提升了約3.7分，代價是四倍的推理成本。這個權衡是否值得，取決於具體場景對精度的要求。
Q3：上下文長度對Agent性能的影響有多大？
影響顯著，但有邊際效應。實驗顯示，上下文從8k增加到24k–48k時，GAIA-Val各難度級別的準確率都有明顯提升；超過這個範圍後，收益開始遞減，到400k時和64k相比幾乎沒有差異。難度最高的L3任務對上下文長度最敏感，說明複雜的長鏈推理任務確實需要更大的記憶空間，但"更大"不是沒有盡頭的——工程上把上下文窗口控制在32k到64k之間，是性價比最高的選擇。
