MiniMax M2.1：從多語言編程到 AI 代理，這次更新了什麼？

MiniMax M2.1 是中國 AI 公司 MiniMax 於 2025 年 12 月 23 日推出的開放權重模型更新，主要面向程式開發與 AI 代理工作。相較於前一代 M2 強調低成本和廣泛取得，M2.1 更聚焦於多語言軟體工程、全端應用、原生手機開發，以及需要多個步驟和工具協作的實際工作流程。34

不過，必須先釐清一點：目前最亮眼的效能數據多來自 MiniMax 自行公布的評測。這些結果可以反映模型的發展方向，但不應直接視為與閉源模型比較時的獨立、最終排名。

MiniMax M2.1 是什麼？

M2.1 採用混合專家（Mixture of Experts，MoE）架構，總參數量為 2,300 億，每個 token 約啟用 100 億參數。這種稀疏架構的設計，是希望在推論時不必像同等規模的密集模型一樣啟用全部參數，從而提升效率。1

MiniMax 的核心主張是：真正有用的程式模型，不應只會產生 Python 片段或單一函式。實際軟體專案往往同時涉及多種語言、既有程式碼庫、手機平台、視覺介面、專案規範、工具呼叫，以及一連串彼此依賴的任務。M2.1 正是圍繞這種較完整的開發流程設計。

M2.1 與 M2 有哪些不同？

MiniMax 將 M2.1 描述為一次重心轉移：從 M2 對成本與可取得性的強調，進一步走向複雜、接近生產環境的任務執行，尤其是跨語言程式開發、日常辦公與 AI 代理場景。4

官方列出的改進包括：

• **更廣泛的程式語言支援：**強化 Rust、Java、Go、C++、Kotlin、Objective-C、TypeScript、JavaScript 等語言，同時涵蓋 Python 及其他語言。37
• **全端應用開發：**目標不只是輸出零散程式碼，而是建立完整、可運作的應用程式。34
• **原生手機開發：**MiniMax 特別強調 Android 與 iOS 能力，並將這兩個領域視為 AI 系統長期較弱的環節。4
• **更複雜的代理執行：**模型定位於需要同時處理工具、專案檔案、指令、記憶與多個步驟的工作流程。4
• **辦公與文件任務：**MiniMax 表示模型在結構化寫作、技術文件、資料處理及持續運作的代理流程方面有所提升。4

換句話說，按照 MiniMax 的產品定位，M2.1 不只是更大或更便宜的程式模型，而是試圖處理包含需求、介面、工具呼叫和可交付軟體的完整任務，而不只是產生文字或程式碼。

M2.1 強化了哪些程式語言？

MiniMax 表示，M2.1 對 Rust、Java、Golang、C++、Kotlin、Objective-C、TypeScript、JavaScript 及其他語言進行了系統性強化。第三方報導也提到，模型專家涵蓋 Java、Go、Rust、C++、TypeScript、JavaScript、Kotlin 與 Python。37

這對維護混合技術堆疊的團隊尤其重要。只擅長 Python 的模型，在實際企業程式庫中可能不夠實用，因為同一個專案可能同時包含 Java 或 Go 後端服務、Rust 或 C++ 系統程式碼，以及以 TypeScript、JavaScript、Kotlin 或 Objective-C 撰寫的網頁和手機介面。

它與 Claude Sonnet 4.5、Claude Opus 4.5 相比如何？

MiniMax 表示，M2.1 在多語言軟體工程場景中勝過 Claude Sonnet 4.5，並接近 Claude Opus 4.5；公司公布的 SWE-bench Multilingual 得分為 72.5%。316

這些數據需要審慎解讀。現有引用資料並未建立一個中立且可由外部獨立重現的排行榜，而且比較結果可能受到提示詞、代理框架、模型版本及評測流程影響。較後期的第三方分析指出，M2.1 在 SWE-bench Verified 上比 M2 有所進步，但在該次比較中仍落後於數個強大的閉源系統。7

較穩妥的結論是：MiniMax 將多語言、程式庫層級的軟體工程視為 M2.1 的主要強項，而已公布結果也顯示它相較前代有明顯提升。但單憑這些數字，不能證明 M2.1 在所有軟體專案或工作流程中都會勝過 Claude。

VIBE 評測是什麼？

VIBE 是 Visual & Interactive Benchmark for Execution 的縮寫，中文可理解為「視覺與互動執行評測」。MiniMax 建立這套評測，是為了檢驗模型能否從零開始打造完整、可使用的應用程式，而不是只在文字視窗中產生看似合理的程式碼。34

VIBE 包含五個領域：

• Web
• Simulation（模擬）
• Android
• iOS
• Backend（後端）

它以已部署的應用程式，以及互動和視覺驗證為評測基礎。因此，VIBE 試圖捕捉傳統程式評測未必能完整反映的問題：應用程式實際操作時是否正常、互動邏輯是否正確，以及介面是否達到視覺要求。4

M2.1 公布的 VIBE 成績

MiniMax 公布的 VIBE 綜合分數為 88.6，其中 VIBE-Web 為 91.5、VIBE-Android 為 89.7。48

這些數據之所以受到關注，是因為它們把評測範圍從修復程式錯誤或程式碼補全，延伸至完整應用程式交付。不過，VIBE 是 MiniMax 建立的評測，跨模型比較也採用 MiniMax 的評估設定。因此，這些分數較適合視為公司用來證明模型強項的數據，而非已由業界獨立確認的排名。48

M2.1 能如何協助手機、網頁與應用程式開發？

MiniMax 將 M2.1 定位為更適合原生 Android 與 iOS 開發的模型，而不只是用於瀏覽器應用。公司也表示，模型對視覺設計與美感、複雜互動、3D 科學模擬及高品質視覺化的理解有所改善。4

這些能力組合，支援更進階版本的「氛圍編程」（vibe coding）：使用自然語言描述應用程式，再由 AI 代理組裝出可運作的產品。MiniMax 的目標不只是產生吸睛示範，而是建立可維護、可交付、面向生產環境的應用程式。4

但這個目標仍需要透過真實程式庫驗證。手機建置系統、依賴衝突、平台特有規範、無障礙設計、安全審查和長期維護，都是基準測試無法取代的實務檢查。

「交錯思考」如何支援複雜工作流程？

MiniMax 將 Interleaved Thinking（交錯思考）描述為一種在執行任務期間進行系統化解題的方法，目的是讓模型同時保留多項限制條件，包括系統指令、使用者需求、記憶、工具規格和專案指令檔案。4

這對 AI 代理工作很重要，因為成功與否不只是看程式碼能否執行。代理還可能需要：

1. 檢查現有專案。
2. 遵循程式庫或儲存庫的專屬規範。
3. 選擇並正確使用工具。
4. 協調修改多個檔案。
5. 產出文件或結構化結果。
6. 確認最終成果符合原始需求。

MiniMax 將這項能力與技術文件、結構化寫作、資料處理及持續辦公自動化連結起來。這些仍屬於產品定位與公司主張，並不代表每一種多步驟流程都能穩定完成；但它們也說明了為何 M2.1 被定位為「程式開發與代理模型」，而不只是程式碼生成器。4

如何存取與部署 MiniMax M2.1？

開發者主要有兩種使用方式：

• **API 存取：**透過 MiniMax 提供的託管 API 使用 M2.1。46
• **自行管理部署：**從 Hugging Face 取得公開模型權重，在自己的服務環境中部署。46

MiniMax 的部署指南建議使用 SGLang，而 vLLM 也獲周邊部署生態支援。141 對企業而言，自行部署可比單純使用 API 更直接地掌控基礎設施、資料處理、模型服務、系統整合與擴展方式。

但部署彈性不等於總成本一定更低。自建服務同樣需要足夠的 GPU 資源、工程人力、監控、維護及營運支援。最終經濟效益取決於使用量、硬體配置和營運方式，而不只是模型每個 token 啟用多少參數。12

實際評價：值得關注，但別只看排行榜

M2.1 相較 M2 最重要的變化，在於產品焦點。這次更新不再只把存取便利性和推論效率放在前面，而是主打多語言、全端及代理驅動的實際工作。MiniMax 公布的 SWE-bench Multilingual 72.5% 和 VIBE 88.6 分，正好支援這個定位；Android 與網頁項目成績，也顯示它試圖評估完整應用程式建構，而不只是傳統程式撰寫。348

對開發者而言，M2.1 的主要吸引力在於更廣泛的語言支援、開放權重、API 存取，以及透過 SGLang 或 vLLM 部署的彈性。對企業來說，則是有機會以更高的基礎設施與資料控制權，執行較複雜的程式開發和辦公自動化流程。

但同樣重要的限制是：最強的模型比較與全新的 VIBE 結果，主要仍由 MiniMax 自行公布。團隊若要評估 M2.1 是否適合生產環境，應先以自家程式庫、手機建置、文件需求、安全控管和自動化任務進行測試，再決定是否將基準數據視為實際部署證據。