MOSiB 是什麼？讓 AI 代理分工進化，數學準確率從 46% 升到 62%

同一個 AI，解題能力還能因為工作流程不同而明顯改變。MOSiB 研究讓兩條流程各自累積經驗，再由另一個機制挑選適合的解題路線。在論文的奧林匹亞數學測試中，使用 Gemini 3 Flash 的準確率由比較方法的 46% 提升到 62%。這個結果在 X 引起討論，也把「除了換模型，還能改進什麼」變成一個具體問題。

MOSiB 的完整名稱是 Mixture of Self-Improving Branches，可以理解為「混合多條會自行改善的分支」。研究改動的是模型周圍的工作規則，包含解題步驟、檢查方式與工具安排。它沒有把 Gemini 的模型參數重新訓練一遍，因此比較適合被理解為 AI 代理流程最佳化研究，而不是另一個新聊天模型。

對正在使用 AI 寫程式、分析文件或解數學的人，這篇論文提供一個有用方向：一套通用提示詞未必適合所有任務。本文會先拆解它如何運作，再看實驗的改善幅度，最後用客服與報表的情境說明，什麼時候值得做分工，什麼時候增加流程反而可能拖慢工作。

AI 代理為什麼需要一套工作流程？

AI 代理是能按照任務使用工具、執行多個步驟並回報結果的系統。模型負責理解與推理，外圍程式則決定它可以讀哪些文件、何時搜尋、何時執行程式，以及出錯後怎麼處理。研究常把這一層稱為 harness，本文以「代理工作流程」指稱這些規則與程式。

可以把它想成同一位分析師的兩種工作安排。第一種先快速寫出答案，再安排核對。第二種先列出假設，逐步推導，完成後才整理答案。分析師的知識相同，處理不同題目時卻可能得到不同結果。AI 代理也會受到步驟順序、驗證次數與工具使用條件影響。

一個常見改善方式，是讓 AI 反覆修改流程，再以固定題目評分，保留得分最高的版本。這容易理解，也便於自動化。但如果所有修改都追求同一個平均分數，某種擅長驗證的流程可能逐漸被另一種擅長長篇推導的流程取代。最後留下的版本比較全面，卻未必保留每一種題型需要的專長。

MOSiB 關心的正是這個問題。它讓搜尋改善方法的路徑保持分歧，允許不同分支服務不同難題，再把分工成果組合起來。這個概念與「多叫幾個 AI 投票」有相似的多樣性精神，但執行方式有差別：研究重點是先養出不同流程，再為每個輸入決定使用哪一條。

MOSiB 的三個關鍵：分支、經驗與路由器

依照研究論文，各個分支不只保留不同版本的程式，也會形成不同的開發題目與改善筆記。某個分支如果在一類題目表現更好，就能繼續圍繞那類題目改進。這讓流程差異有機會累積，而不是每一輪都朝同一份練習題收斂。

開發題目相當於用來調整方法的練習材料，與最終測試題的角色不同。改善筆記則記錄哪些做法有用、哪些嘗試失敗，避免下一輪從頭猜起。把題目與經驗都留在分支內，有助於形成真正不同的策略。只是把相同提示詞複製兩份，通常不會自然產生這種專長。

論文中的數學案例提供了直觀說明。一條分支逐漸偏向驗證答案，另一條偏向建立完整推導。前者可能較適合已有候選答案、需要查錯的題目。後者則有助於需要展開關係與連續推理的題目。這是研究觀察到的策略差異，不能直接推出任何日常數學題都能由相同兩類策略解決。

最後需要一個路由器，也就是替輸入選擇處理路線的機制。它根據開發階段得到的資訊，判斷新的任務較適合哪個分支，再交給該流程處理。路由器不是看過測試題的正確答案才挑贏家。如果實際使用時沒有答案，就必須靠輸入特徵與過往經驗做選擇。

這一點決定了整個系統是否實用。假如分支各自很強，路由器卻常把題目分錯，整體得分仍可能下降。閱讀類似研究時，應分清楚「每題事後挑最佳答案」與「事前選擇執行流程」。前者能估計潛力，後者才接近使用者真正會遇到的情況。

46% 到 62% 是多大的進步？

數字容易吸引目光，也容易被讀成不相同的意思。從 46% 到 62%，提升的是 16 個百分點。若以原本的 46% 當分母，相對增幅約為 34.8%。它不是準確率提高到原來的兩倍，也不代表每一個模型或每一種任務都能多答對十六題。

下表整理論文中的部分比較。基準是研究採用的 Meta-Harness，比較雙方使用的模型與測試情境一致。這些結果說明流程分工在指定測試裡有效，不能直接拿來預測公司的正式服務表現。

Terminal-Bench 評估代理在終端環境完成任務的能力。SWE-bench Lite 則是一組軟體問題修復測試。兩者與數學題需要的工具、時間及錯誤處理不同，因此最好分開閱讀。把四個情境都壓縮成「AI 整體變強三成」，會抹掉最值得理解的差異。

還有一個現實問題是成本。多條分支需要開發、測試與維護，路由器也需要決策。單次任務只執行一條分支，有機會避免所有分支都跑一遍的開銷，但開發成本不會憑空消失。是否值得投入，要看增加的成功率能不能抵銷資料整理、運算與日後維護的支出。

用客服與報表理解：分工何時有價值？

假設一間公司用 AI 處理客服信件，其中一類問題是查訂單狀態，另一類是需要閱讀政策、判斷退貨條件。前者更重視快速找到正確紀錄，後者更重視規則依據與例外情況。這是本文的示意情境，並非論文已完成的客服實驗。

如果兩類問題共用一套很長的流程，簡單查詢可能被不必要的分析拖慢。如果都走最短路線，複雜退貨又可能漏掉條件。分支式設計讓兩類流程各自練習，再由路由器判斷該走哪一條。公司需要測的除了答案，還包括錯誤分流是否把敏感案件交給過度簡化的流程。

報表分析也有類似情況。整理已知欄位與追查異常數字需要不同工作方式：整理流程可以先確認表格結構，異常追查流程則可能需要比對多個期間並重新計算。保留這兩種路線，有機會讓 AI 少做無效工作。但如果原始資料根本有錯，分工不會自動讓錯誤數字變正確。

因此，最有價值的起點不是先開十個分支，而是找出穩定、可描述的任務差異。分類太細，開發題目不足，每條路線都可能只記住少量例子。分類太粗，專長又不容易形成。研究採用的分支數量與資料安排，是實驗設計的一部分，企業可以借鏡思路，仍需依自己的任務重新決定。

導入前，先把測試資料與權限整理好

第一步是建立固定的評分標準。若客服答案只要語氣友善就得高分，系統可能學會漂亮地回答錯誤資訊。若程式任務只看是否產生檔案，代理可能忽略檔案內容是否正確。分支最佳化會放大你設定的目標，因此驗證方式要能反映真正的工作成果。

第二步是把開發資料與測試資料分開。用來產生筆記、調整流程與訓練路由器的案例，不能全部再拿來當最終證明。比較穩妥的做法，是保留一批未參與調整的任務，並記錄題型、成功率、處理時間與工具費用。這樣才能看出改善是否延伸到新的輸入。

第三步是記錄每條分支的權限。若其中一條能發送郵件，另一條只能讀文件，路由器的選擇就不只是效能問題，也會影響外部行動。對具備寫入能力的代理，應把可讀資料、可改欄位與必要的人工確認放在外圍控制，不能讓流程自行修改後就擴大操作範圍。

第四步是保留失敗案例，而不只保存最佳得分。某條分支平均分數提高，卻在少數高風險任務退步，對正式服務可能很重要。把錯誤分成工具使用、資料理解、推理與輸出格式等類型，能幫助團隊判斷究竟該改善流程、修正資料，還是換用不同模型。

實際上線時也應保留退路。新路由器可以先對一部分任務提出分流建議，由原流程繼續執行，對照兩者差異。等評分與延遲足夠穩定，再逐步擴大。這是一般工程評估建議，並非 MOSiB 已驗證的部署流程，目的在於讓研究方法轉成可追蹤的工作改動。

MOSiB 與多代理協作，有什麼差別？

多代理協作通常讓多個角色同時或依序參與一項任務，例如研究者找資料、寫作者組織內容、審稿者檢查論證。MOSiB 更聚焦於保留多種可改善的流程，再選擇適合的分支。兩種方法可以討論相似的分工原則，但不要因為都含有多個角色，就把它們當成同一種產品。

對大多數使用者來說，這份研究最容易借用的部分，是把任務拆出不同需求，再為需求安排不同檢查方式。若原本只有一句模糊的「幫我完成」，先把資料來源、成果格式與驗收條件寫清楚，往往比立即採用複雜的分支系統更容易看到效果。

常見問題：一般人可以直接下載 MOSiB 嗎？

MOSiB 是一個新的聊天 AI 嗎？

它是改善 AI 代理工作流程的研究方法。文章引用的成績來自論文設定的模型與測試，不等於有一個叫 MOSiB 的一般消費聊天服務。想要重現結果，需要理解研究的流程、資料安排與評分方式，不能只把名稱放進提示詞就得到相同提升。

分支越多，效果就一定越好嗎？

不一定。分支增加會帶來資料、測試與維護需求，也可能讓路由更難判斷。有效的專長差異比數量重要。如果多個分支做法近似，增加數量可能只是重複工作。是否新增路線，應以未參與調整的測試表現與總成本決定。

這會讓 AI 完全不出錯嗎？

不會。即使數學準確率提升到 62%，仍有相當比例未答對。工作流程能改善某些失誤，卻無法保證模型理解所有情境。需要外部查證、計算或人工判斷的任務，仍要把這些步驟放進驗收方式，尤其不能讓一個漂亮的平均分數取代實際檢查。

結語：下一輪 AI 競爭，也發生在模型周圍

MOSiB 的價值，是把「同一個模型能否因為安排不同而更可靠」變成可測量的研究問題。它保留多條專長路線，用各自的經驗推動改進，再透過分流組合成果。數學測試的 46% 到 62% 很醒目，其他任務較小的提升則提醒我們：流程改善的收益會隨模型與任務而變。

如果你正在建立 AI 工作流程，可以先從一件事開始：找出最常出錯的兩類任務，分別訂出完成條件與檢查步驟，再比較共同流程和專門流程的表現。當分工確實解決不同問題，才值得投入更自動化的最佳化系統。這樣閱讀研究，能把熱門數字轉成更實際的工作判斷。

官方資料來源

• MOSiB 研究論文：Mixture of Self-Improving Branches For Agent Harness Optimization
• X 討論線索與論文摘要