MiniMax M2.1：由平價易用，走向多語言編程與複雜 AI Agent 工作流

MiniMax M2.1 是中國 AI 公司 MiniMax 於 2025 年 12 月 23 日推出的開放權重模型，主要面向編程及 AI Agent 工作。相較上一代較強調成本和普及度的 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 的「平價、易接觸」推向更可靠地處理複雜、接近生產環境的任務，尤其集中在跨語言編程、應用程式建構，以及日常辦公室和 Agent 情境。 4

主要改進包括：

• **支援更廣泛的程式語言：**Rust、Java、Go、C++、Kotlin、Objective-C、TypeScript、JavaScript，以及 Python 等。 37
• **由零開始建立全棧應用程式：**目標唔再只係輸出互不相干的程式碼片段，而係建立可以運作的完整應用程式。 34
• **加強原生手機開發：**MiniMax 特別提到 Android 和 iOS，並將原生手機開發視為 AI 系統一直較弱的範疇。 4
• **更適合 Agent 執行任務：**模型定位於需要同時處理工具、專案檔案、指示、記憶和多個步驟的工作流。 4
• **處理文件及辦公室工作：**MiniMax 聲稱在結構化寫作、技術文件、數據相關工作和持續運行的 Agent 流程方面有所提升。 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 寫成的網頁和手機介面的生產環境專案。

M2.1 同 Claude 模型比較如何？

MiniMax 聲稱，M2.1 在多語言軟件工程情境中勝過 Claude Sonnet 4.5，並接近 Claude Opus 4.5；公司公布的 SWE-bench Multilingual 得分為 72.5%。 316

但呢組數字需要小心解讀。現有資料未能證明這是一個中立、由外部獨立重現的排行榜；比較結果亦可能受提示語、Agent 框架、模型版本和評測流程影響。較後期的第三方分析則指出，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（後端）

評測重點包括已部署的應用程式，以及互動和視覺驗證。換句話講，它關心的不只係程式碼有冇成功產生，亦包括應用程式實際使用時能否正常運作、互動邏輯是否正確，以及介面是否符合視覺要求。 4

M2.1 公布的 VIBE 成績

MiniMax 公布 M2.1 的 VIBE 總分為 88.6，其中 VIBE-Web 為 91.5，VIBE-Android 為 89.7。 48

呢啲成績值得留意，因為評測範圍已由修正程式錯誤或程式碼補全，延伸至真正交付應用程式。不過，VIBE 是 MiniMax 自行建立的評測，而跨模型比較亦採用 MiniMax 的評測設定。因此，相關分數應理解為公司用來證明模型主打能力的數據，而非已獲獨立確認的業界排名。 48

對手機、網頁和 App 開發有咩幫助？

MiniMax 將 M2.1 定位為更適合原生 Android 和 iOS 開發的模型，而唔只係用來製作瀏覽器應用程式。公司亦表示，模型加強了對視覺設計和美感、複雜互動、3D 科學模擬及高質素視覺化的理解。 4

這種組合支援更進取版本的「vibe coding」：使用者用自然語言描述想要的應用程式，再由 Agent 組合出可以運作的產品。MiniMax 的目標並非只係砌出一個吸睛示範，而係產生較容易維護、可以交付、面向生產用途的應用程式。 4

但實際效果仍然要放入真實程式庫測試。手機建置系統、依賴衝突、平台慣例、無障礙設計、安全審查，以及長期維護，依然係基準測試分數取代唔到的實務檢查。

「Interleaved Thinking」點樣處理複雜工作？

MiniMax 將 Interleaved Thinking 描述為模型在執行任務期間進行系統化解難的方法。它的作用，是協助模型同時保留多項限制，包括系統指示、用戶要求、記憶、工具 Schema，以及專案內的指示檔案。 4

對 AI Agent 工作而言，結果成功唔係淨係睇程式碼能否運行。Agent 可能仲要：

1. 檢查現有專案。
2. 遵守程式庫內的專屬規則。
3. 選擇及使用正確工具。
4. 協調修改多個檔案。
5. 產生文件或結構化輸出。
6. 確認結果符合最初要求。

MiniMax 將呢種能力連繫到技術文件、結構化寫作、數據處理，以及持續運行的辦公室自動化。呢啲仍然屬於模型定位和公司聲稱，唔代表每一個多步驟工作流都一定可以穩定完成；但它解釋了點解 M2.1 被包裝成「編程加 Agent」模型，而唔係單純的程式碼生成器。 4

開發者可以點樣使用和部署 M2.1？

主要有兩條路：

• **API 使用：**透過 MiniMax 提供的託管 API 呼叫 M2.1。 46
• **自行管理部署：**從 Hugging Face 下載公開模型權重，再自行管理推理伺服器和相關基礎設施。 46

MiniMax 的部署指引推薦使用 SGLang，而 vLLM 亦得到相關部署生態支援。 141 對企業來講，自行部署可以比只使用 API 更直接控制基礎設施、資料處理、模型服務、系統整合和擴展方式。

不過，「可以自建」唔等於總成本一定更低。自建服務需要合適的 GPU 容量、工程人手、監控、維護和營運支援。最終經濟效益取決於使用量和基礎設施選擇，而唔只係模型每個 token 啟用幾多參數。 12

實際結論：M2.1 值唔值得試？

M2.1 相比 M2 最重要的變化，在於產品焦點。新版本不再主要以平價和易用作為故事核心，而係瞄準多語言、全棧和 Agent 驅動的實際工作。它公布的 SWE-bench Multilingual 72.5% 和 VIBE 88.6 分，配合 Web 和 Android 的分項成績，反映 MiniMax 正嘗試量度完整應用程式建構，而唔只係傳統編程能力。 348

對開發者而言，較有吸引力的地方包括更廣泛的語言支援、開放權重、API 存取，以及透過 SGLang 或 vLLM 自行部署的彈性。對企業而言，重點則係能否以更大的基礎設施和資料控制權，運行較複雜的編程和自動化流程。

但最重要的保留條件亦要講清楚：最強的模型比較和全新的 VIBE 結果，主要都是 MiniMax 自行公布。團隊如果考慮在生產環境採用 M2.1，應先用自己的程式庫、手機建置、文件要求、安全控制和自動化任務進行測試，唔好只靠基準分數就判定模型已經適合正式上線。