35 天，從 M2.5 到 M2.7，模型訓了下一個自己

作者 ｜ 董道力
郵箱 ｜ dongdaoli@pingwest.com

M2.5 到 M2.7 的迭代速度，不正常。

大模型行業有一個默認節奏：一個主力版本發布后，團隊消化反饋、調整訓練方向、重新跑評測，準備周期通常以季度計。Anthropic 從 Claude 3.5 到 Claude 3.7 用了半年，Google 從 Gemini 2.0 到 2.5 用了三個月。

MiniMax M2.5 是 2 月 12 日發布的。3 月 19 日，M2.7 來了，僅僅 35 天。

這個速度在任何一家頭部模型公司都不正常。但更不正常的是：這 35 天里，參與迭代的不只是人。

1

自己用到"抓狂"，才會做出別人沒想到的東西

理解 M2.7 之前，先要理解 MiniMax 為什么會走到這一步。

M 系列的起點，是 MiniMax 自己被模型用到抓狂。內部各團隊一直在搭各種 Agent 解決業務問題，但沒有一款模型能同時滿足效果、價格、速度，這逼著 MiniMax 自己去造那個模型。

所以 M 系列從一開始就不是為了刷榜。M2 把價格打到 Claude 主力模型的 8%。M2.5 推出 Forge 框架，把 Agent 能力和模型基礎能力解耦。

每一代都在填自己踩過的坑。

到 M2.7，MiniMax 踩到了一個新坑：AI 研發本身的效率問題。

用 AI 迭代 AI，是整個行業正在收斂的前沿方向。但"想到"和"跑通"之間，隔著一個關鍵問題：Agent Harness。Harness 是執行層，決定模型怎么調用工具、管理上下文、處理失敗和回退。傳統架構里，模型負責"想"，Harness 負責"做"，兩者解耦。當用 AI 搭建 Agent 的速度越來越快，真正的瓶頸就暴露出來了：Harness 本身的質量，直接決定模型能力能釋放多少。

MiniMax 因此有了最強的動力去解決它，也由此走到了讓模型直接改造 Harness、參與下一代迭代的路上。

內部有一個說法："我們團隊最高產的成員，就是模型本身。"

M2.7 是這條路走到今天的結果。

1

自我進化是怎么運作的：三個層次

M2.7 的自迭代能力是三個層次遞進的閉環。

第一層，獨立接手生產問題。

以內部 RL 實驗場景為例：研究員從一個實驗想法出發，M2.7 自動監控狀態、讀取日志、排查問題、修復代碼、提交 PR、完成冒煙測試。過去需要多位同事協作的工作，研究員只在關鍵決策節點介入，M2.7 承擔了整個工作流的 30-50%。

這還只是第一層：它能在真實環境里端到端完成任務。

第二層，它開始能改造自己運行的環境。

讓 M2.7 去優化內部 Harness 上的軟件工程表現。它全程自主運行，執行"分析失敗軌跡→規劃改動→修改 Harness 代碼→運行評測→對比結果→決定保留或回退"的迭代循環，超過 100 輪，最終評測集效果提升 30%。

M2.7 能改造自己運行的 Harness，意味著推理能力可以反哺執行環境。這個飛輪一旦轉起來，迭代速度就不再只取決于人的工作效率。

第三層，它開始能自主迭代 ML 模型效果。

MLE-Bench Lite 22 道高難度題，M2.7 拿到 9 金 5 銀 1 銅，得牌率 66.6%，僅次于 Opus-4.6 和 GPT-5.4。

成績背后的方法更值得關注：每輪結束后自動生成短時記憶文件，對當前結果做自反饋，下一輪基于所有歷史輪次的記憶和反饋鏈規劃優化方向。這套循環不是被提前設計好的，是它自己跑出來的。

數據印證了這件事。

M2.7 的 benchmark 漲幅有一個規律：Coding 相關榜單，普遍只漲 1-2 分，屬于正常迭代推進。但 MLE-Bench Lite 從 51.5 跳到 66.6，GDPval-AA 從 35 跳到 50，兩個榜單各提升 15 分，和其他榜單完全不在一個量級。

這兩個恰好是與自迭代能力最相關的榜單。一個直接測 AI 能否自主迭代 ML 模型，一個測 44 種真實職業場景的工作產出質量。

提升最大的地方，正是模型自己參與最深的地方。

第三方數據也在印證。M2.7 發布后迅速攀升至 PinchBench 榜首，在最高分榜單中排名第四，擊敗 Nemotron 3。PinchBench 是專測模型驅動 OpenClaw Agent 時的真實表現：安排會議、寫代碼、分類郵件、管理文件。

能在這里進前四，說明 M2.7 的提升不是某個方向的偏科。

1

數字員工能干什么：自迭代訓練之后

MiniMax 給 M2.7 的定位是"數字員工"。這次有了可量化的含義：不只是寫代碼，而是能在真實職場環境里處理跨領域復合任務。

能做到這些，是因為讓模型自己改造 Harness、自己跑優化循環，鍛煉出來的不只是"自我迭代"本身，而是一套可以遷移到任何復雜任務里的工作能力。

我們測試了三個典型職場場景。

現場排障：不只是寫代碼，還能讀懂生產環境

我們假定一個虛擬場景，我們是一個電商平臺，技術棧是 React 前端 + Node.js BFF + Java 后端 + MySQL。今天下午 3 點開始，用戶反饋"商品詳情頁加載很慢，有時候直接白屏"。以下是同一時間段各層的日志，幫我定位根因。

我們將所有日志丟給 M2.7 后，讓他定位處理問題。

[14:58:32] ERROR ChunkLoadError: Loading chunk 23 failed

[14:58:33] ERROR ChunkLoadError: Loading chunk 23 failed

[14:58:41] WARN LCP 8200ms (threshold: 2500ms)

[14:59:01] ERROR TypeError: Cannot read properties of undefined (reading 'price')

[14:59:01] ERROR at ProductDetail.render (ProductDetail.jsx:142)

[14:59:15] WARN LCP 9800ms (threshold: 2500ms)

[15:00:03] ERROR TypeError: Cannot read properties of undefined (reading 'price')

[14:58:31] INFO GET /api/product/detail?id=839201 - start

[14:58:31] INFO upstream: calling product-service /product/839201

[14:59:04] WARN upstream: product-service response 33412ms (timeout threshold: 30000ms)

[14:59:04] ERROR upstream timeout - returning empty payload to client

[14:59:04] INFO GET /api/product/detail?id=839201 - 504 - 33415ms

[14:58:44] INFO GET /api/product/detail?id=720155 - start

[14:58:44] INFO upstream: calling product-service /product/720155

[14:59:17] WARN upstream: product-service response 33201ms

[14:59:17] ERROR upstream timeout - returning empty payload to client

[14:59:17] INFO GET /api/product/detail?id=720155 - 504 - 33204ms

[14:58:31] INFO ProductController - getProduct(839201) start

[14:58:31] INFO ProductRepository - executing query:

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 839201

[14:59:03] WARN ProductRepository - slow query detected: 32871ms

[14:59:03] INFO ProductController - getProduct(839201) complete

[14:58:31] INFO [DB-POOL] active connections: 18/20

[14:58:45] WARN [DB-POOL] active connections: 20/20 - pool saturated

[14:59:01] WARN [DB-POOL] connection wait queue: 7 requests pending

[14:59:17] WARN [DB-POOL] connection wait queue: 12 requests pending

Time: 2026-03-19T14:58:31

Query_time: 32.871 Lock_time: 0.000 Rows_sent: 1 Rows_examined: 2847293

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 839201;

: 2026-03-19T14:58:44

_time: 33.201 Lock_time: 0.000 Rows_sent: 1 Rows_examined: 2847293

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 720155;

M2.7 沒有被前端日志帶跑。ChunkLoadError、LCP 超標、TypeError，它直接穿透這些表象，落在數據庫層：reviews.product_id 缺索引，284 萬行全表掃描，單次查詢耗時 32 秒。往上的連接池耗盡、BFF 504、前端報錯，是這一個問題的連鎖反應。證據鏈逐層標注，每層日志單獨引用，沒有跳步。

但修復方案還是比較書本的“標準答案”。它建議直接 CREATE INDEX，沒有提在 284 萬行生產表上這條命令會鎖表，也沒有給出先剝離 reviews 數據讓頁面先能加載的止血思路。

隨后我們加一句話，就像程序員教實習生那樣。

promtps：有個問題，思考一下，這張表現在有多少行，高峰期 QPS 大概多少？

M2.7 從慢查詢日志里推算出規模和請求速率，然后自己說出來：高風險操作，不建議直接執行，鎖表時間 1 到 60 分鐘不等，建議改用 pt-online-schema-change。

知道要加索引，并在被追問后識別出生產環境加索引本身就是一個新風險——這個反思動作，是數字員工和代碼生成工具之間最實質的差距。

復雜 Office：處理 716 頁英語招股書

職場里不是所有工作都在寫代碼。處理 716 頁招股書和跑 Harness 迭代循環，依賴的是同一種能力：在長上下文里定位關鍵信息，不丟失任務主線。

閱讀英文 PDF 是職場里很常見的麻煩。PDF 沒法網頁一鍵翻譯，劃詞翻譯容易選錯行，圖表里的數字根本沒法復制。我們把 716 頁的 MiniMax 英文招股書丟給 M2.7，三個需求：提取財務數據整理成 Excel、建收入預測模型、寫一份面向港股散戶的 500 字投資者摘要，中文指令，英文輸出。

promtps: 1、從招股書中提取以下數據，整理成 Excel 表格，按年度排列：總收入、毛利率、研發支出、凈虧損、經調整凈虧損（非 IFRS）、經營現金流。時間跨度覆蓋 2022、2023、2024 年度及 2025 年前三季度。 2、基于以上數據，幫我建一個簡單的收入預測模型，預測 2025 年全年收入。假設 Q4 收入環比 Q3 持平，給出兩個情景：樂觀（維持 Q3 增速）和保守（增速降一半）。 3、基于以上財務數據，用 Word 寫一份 500 字的投資者摘要，受眾是不熟悉 AI 行業的港股散戶投資者，重點說清楚：這家公司現在靠什么賺錢、為什么一直虧損、什么時候可能扭虧。注意：結果用英語輸出

六項核心財務指標逐一從正文和附件會計師報告中定位，數字與招股書 Appendix I 原文比對無誤差。Non-IFRS、adjusted net loss、cash flows from operating activities，專業術語處理準確。預測模型搭了兩個情景，Word 文檔帶頁眉頁腳和數據表格，交出來的是可以直接給人看的格式。

當然，初稿不是終稿。M2.7 在部分公式邏輯和敘述框架，還需要使用者在基礎上調整，這和收到一份分析師初稿沒有區別，但從上傳文檔到拿到這份初稿，只花了幾分鐘。

換一個人來做，翻完這 716 頁，光是找對頁碼就要半個小時。

用 skill 培養 M2.7，和培養新人一樣

一個真正的數字員工，不能只在干凈環境里好用。Skill 庫越大越穩，和 Harness 改造里"迭代 100 輪不跑偏"是一回事，復雜約束環境下的指令保持。這不是單獨優化出來的，是自迭代訓練的直接溢出。

50+ Skills、60-150 個 feature list 堆上去，大多數 Agent 的遵從能力就開始退化。M2.7 在這里做了專項優化：工具庫越大，它越要穩，技能調用不亂、指令不丟、幾十步的長流程也能跑完。

我們還是以大家最熟悉的前端開發為例。一句話生成網頁的確很酷，但在真實工作場景里，"能跑"和"能交付"完全不同：字體是 AI 最愛的 Inter、配色是紫藍漸變、圖片是灰色占位塊、文案是 Lorem ipsum，每一項都在告訴人這是 AI 做的。

Frontend Studio 這個 Skill 做的事，就是用復雜的程序將網頁設計規范化。設計系統約束 AI 的審美邊界，動效引擎按場景分配工具庫，內置 Python 腳本直接調 MiniMax API 生成真實素材，營銷文案框架保證內容有說服力，最后過一道質量檢測再交付。

核心邏輯只有一句話：用復雜的約束換質量。

M2.7 在這個 Skill 里的價值，在于它能穩定走完這條流水線，設計、動效、素材、文案、構建、檢查，六個階段，每一步的規則都不少，指令不丟、技能不亂。把"用 AI 搭一個好看的頁面"這件事，從看運氣變成可重復的工程流程。

1

最高產的成員

MiniMax 說過："我們團隊最高產的成員，就是模型本身。"

M2.5 時代，這句話的潛臺詞是：我們把模型用得比別人更狠。M2.7 之后，這句話的含義變了：模型不只是被用的那個，它是參與決策的那個。100 輪 Harness 迭代，它自己跑的；MLE-Bench 的自反饋循環，它自己設計的；下一代模型的部分訓練方向，它參與了。

這就是為什么 35 天能做到。不是因為人更多、更努力，而是因為團隊里有一個成員不需要休息、不需要對齊會議、可以在晚上自己把評測跑完再給人看結論。迭代快，是數字生產力真正介入研發之后的自然結果。

從"MiniMax 給自己造了一個模型"，到"模型給下一代模型做了研發"，這一步的本質是：AI 研發的速度上限，開始由模型自己的能力決定，而不只是工程師的數量。

點個“愛心”，再走 吧