MiniMax M2.7 把 agent 做成能交付

MiniMax M2.7 是一個偏實戰的 agent 模型，適合拿來做 coding、文件修改和多步驟任務，重點是能直接抄 API 玩法。

我用一堆 agent 模型用到現在，最煩的不是它不會講，而是它很會講。第一輪看起來都像樣，第二輪開始就飄：改 code 改到一半忘記規格，修文件修到格式整個炸掉，叫它做多步驟任務就像在跟一個會點頭的同事合作。你問它能不能做，它永遠說可以；你真的把 repo、log、文件丟給它，它就開始把事情做成聊天紀錄。

MiniMax M2.7 讓我停下來看的原因，就是它沒有一直裝成萬能聊天機器。它在 官方頁面 的說法很直白：這不是只會回話的模型，而是拿來做複雜 agent、軟體工程、Office 編修、環境互動的工作馬。這種定位我比較買單，因為我真的不缺回答問題的模型，我缺的是能把事情做完的模型。

我這篇不是在幫它背書。我是把它的產品頁、API 範例、benchmark 叙事拆開來看，看看哪些東西是真能拿去實作，哪些只是 launch 文案。原始來源就是 MiniMax 的 M2.7 頁面：minimax.io/models/text/m27。我只拿它自己公開講的內容來拆，不靠外面亂傳的數字。

它賣的不是聊天，是把任務跑完

Build a Complex Agent Harness Independently to Accomplish Highly Complex Productivity Tasks.

翻譯一下就是：MiniMax 不想讓你只把 M2.7 當成 prompt 回答器，而是把它當成一個可以撐住長流程的執行核心。這句話很重要，因為很多模型都卡在「第一輪很聰明，第二輪就失憶」這個老問題。你如果只是問它一題，它會很會；你如果要它跨檔案、跨步驟、跨工具，很多模型就開始演戲。

我之前做內部文件工作流時就很有感。模型可以先產出一份看起來不錯的摘要，但只要我要求它再根據最新限制改一版，它就會忘記前面講過的格式、語氣、欄位順序。這不是小 bug，這是 agent 的根本問題：它到底是在完成任務，還是在陪你聊天。

所以我看 M2.7 的第一個重點，不是它會不會答得漂亮，而是它有沒有把「任務完成」放在核心。只要你要做的是長流程、要保留狀態、要在多次修正後還能交差，這個定位就比那些只會秀單輪效果的模型實際很多。

實操上，我會這樣測：不要丟一個單點問題，直接給它三段式任務。先讀 repo 或文件，再提出修改方案，最後真的要求它產出 patch、更新說明，或整理成可交付格式。只要中間有一步掉鏈子，就代表它還不是你要的 agent 核心。

• 測多步驟，不測單輪聰明。
• 看它能不能守住前面限制。
• 看完成率，不要只看答題漂亮程度。

它的 coding 訴求，重點是交付不是炫技

MiniMax 在頁面上講得很明白：M2.7 在真實軟體工程、端到端專案交付、log 分析、code security、machine learning 任務上有不錯表現。它還提到 SWE-Pro benchmark 上是 56.22%，VIBE-Pro 是 55.6%，Terminal Bench 2 是 57.0%。我不會把這種數字當聖旨，但我會把它當成產品定位的線索。

翻譯一下就是：它不是只想證明自己會寫一段漂亮函式，而是想證明自己能在一個真的 codebase 裡活下來。這差很多。因為真實開發的難點從來不是語法本身，而是 conventions、tests、舊 code、奇怪依賴、log 噪音，還有一堆你不想碰但又不能不碰的歷史包袱。

我看過太多模型在 toy task 上像神，進到真實 repo 就直接變笨。尤其是要它同時看 log、修 bug、補測試、回頭改 README 的時候，很多模型會開始亂猜，或是只會給你一個很像樣但不能落地的建議。M2.7 這種把 end-to-end delivery 擺在前面的說法，至少是對準了我真正會拿來驗證的場景。

實操寫法很簡單：你自己做一個小型內部測試集。第一題是有 tests 的 bug fix，第二題是 log triage，第三題是要同時改 code 和文件的 feature request。評分不要看文筆，要看它有沒有真的完成、修改有沒有守住原本規格、最後能不能被人接手。

• 要求 patch、說明、測試計畫一起交。
• 用你自己的 repo，不要拿乾淨 demo。
• 加一個髒一點的 edge case。

Office 編修這塊，比很多人想的還實用

MiniMax 說 M2.7 在 Excel、PPT、Word 的複雜編輯能力有明顯提升，特別是多輪修改和高保真編修。它還提到 GDPval-AA 上的 ELO 是 1495，並說這是 open-source models 裡最高。這種數字我會先保留態度，但它想傳達的方向很清楚：這模型不只想進工程團隊，也想進辦公文件流程。

白話一點講，這很重要，因為很多 agent 產品死在文件工作。它可以幫你寫一段摘要，但不能保留表格；它可以幫你改簡報，但改完故事線就散掉；它可以整理 Excel，但第二輪修改就把公式或欄位結構弄壞。真正麻煩的不是生成，而是修改，而且是反覆修改。

我以前看過模型把一份季度報告改得更「順」，結果把所有表格都洗成純文字。語言上看起來更漂亮，實際上完全不能交。這就是我會特別在意「multi-turn modifications」和「high-fidelity edits」的原因。文件工作不是創作比賽，是保留結構、維持格式、讓人能接著用。

實操寫法：拿一份有標題層級、表格、重點條列的 Word 文件去測它。先叫它改寫，再叫它做兩次局部修正，最後要求保留格式與結構。Excel 和 PPT 也一樣，重點不是它能不能產出，而是它能不能在第二輪、第三輪還不把東西改爛。

如果你想對照相近產品，可以看 OpenAI 的 GPT-4o、Anthropic Claude 4，以及 MiniMax M2.5。我不是要幫它拉踩，我只是說這些是比較合理的參照物。

環境互動才是 agent 真假分水嶺

MiniMax 說 M2.7 有能力跟複雜環境互動，在 40 個複雜技能案例、超過 2000 tokens 的情境下，skill adherence rate 還能維持 97%。它也提到在 OpenClaw 的使用上，M2.7 比 M2.5 好，並且接近最新的 Sonnet 4.6 在 MMClaw 的表現。

這段我看得很認真，因為 agent 真正會翻車的地方，通常不是第一步，而是長流程裡的漂移。模型一開始很乖，工具一接、上下文一長、檔案一多，它就開始忘記自己在幹嘛。那種不是大爆炸，是慢慢歪掉，最難救。97% 的 adherence 如果測試方法站得住腳，代表 MiniMax 至少有在正面處理這個問題。

我碰過太多 agent 在工具輸出、檔案狀態、使用者臨時改需求之間直接迷路。最煩的是它不會當場承認自己迷路，它會繼續講得很完整，然後做錯。這種 drift 比明顯失敗更討厭，因為你還得花時間找出它到底在哪一步偏掉。

實操寫法：自己做一個簡單 harness，裡面放目錄、log、checklist，讓模型先檢查、再修改、最後回報。中間故意插入一個額外限制，觀察它有沒有延續前面的約束。若你做 browser agent 或 desktop agent，再加 retry 和 interruption，才看得出它會不會回到正軌。

身份與情緒不是裝飾，是產品穩定性

MiniMax 也說 M2.7 在 identity preservation 和 emotional intelligence 上表現不錯，還提到除了 productivity use cases，也能延伸到 interactive entertainment。這句話如果放在別家我大概會翻白眼，但放在 agent 模型上，我反而覺得合理，因為有些產品本來就不是拿來寫報告，而是拿來維持一種一致的互動感。

白話一點講，如果你做的是陪伴、角色扮演、遊戲 NPC、長對話互動產品，模型會不會突然失去人格，真的是 bug，不是風格差異。使用者不一定會說得出來，但他們會明顯感覺到：剛剛那個角色不見了。這種斷裂感一出現，體驗就直接掉下去。

我也看過模型在同一段對話裡忽然從沉穩變成過度熱情，或是從角色語氣跳回教科書口吻，整個產品感立刻死掉。所以這裡的重點不是「情緒智商」這種漂亮詞，而是它能不能在多輪互動裡維持一致的身份與語氣。

實操寫法：如果你的產品不是純 productivity，就一定要測 persona。先給一個角色設定，再丟進打斷、糾正、情緒變化，看看它會不會保留身份。對娛樂或陪伴型產品來說，這不是加分項，這是基本盤。

我最在意的是 API 夠不夠好接

MiniMax 在頁面上直接放了 API 範例，還分成 M2.7 與 M2.7-highspeed 兩個版本，說結果相同但 highspeed 更快。它也說 cache support 是自動的，不用另外設定。API endpoint 是 api.minimax.io/v1/text/chatcompletion_v2，整體看起來就是標準 chat completion 風格，不需要你先跟奇怪 SDK 打架。

這才是我會真正停下來看的地方。很多 model launch 最大的問題不是模型不行，是接入太煩。你要先研究一堆奇怪參數，再處理 cache、再處理版本差異，最後還沒開始測，時間就先燒掉一半。MiniMax 至少在這裡看起來有在想實際用法，而不是只想讓你為了 demo 興奮一下。

我也喜歡它把 access 分成標準 API、AI coding tools、MiniMax Agent integration。這表示它知道不同團隊的入口不一樣。有些人要原始 API，有些人想直接接 coding 工具，有些人是要整套 agent 平台。這種產品切法比較正常，不會逼大家都走同一條死路。

實操寫法：先用標準 API 起跑，再拿 highspeed 去跑你自己的 workload。不要預設快的就一定適合，實測 latency、輸出穩定性、token 成本才是重點。如果你在做 agent 產品，cache 行為要早點測，因為它會直接影響成本結構。

你可以先從 M2.7 頁面、API endpoint、還有 MiniMax 官網 這三個地方看起來，先確認它的產品面是不是對得上你的需求。

可抄的模板

# MiniMax M2.7 agent starter template

用在你想把模型當成任務執行器，而不是聊天機器人的時候。

## System prompt
You are an execution-focused agent.

Rules:
- Finish the task, do not just discuss it.
- Preserve constraints from earlier turns.
- If the task involves files, logs, code, docs, or spreadsheets, inspect them before proposing changes.
- When you modify something, explain exactly what changed and why.
- If you are unsure, ask one focused question instead of guessing.
- Prefer small, reversible steps.
- Keep formatting intact unless the user explicitly asks for a redesign.

## User prompt template
Task: {describe the task}

Context:
{paste relevant files, logs, requirements, or constraints}

Expected output:
1. Short plan
2. Execution steps
3. Final result
4. Risks or follow-ups

## API request example
import requests

url = "https://api.minimax.io/v1/text/chatcompletion_v2"
payload = {
  "model": "MiniMax-M2.7",
  "messages": [
    {
      "role": "system",
      "content": "You are an execution-focused agent. Finish the task, do not just discuss it."
    },
    {
      "role": "user",
      "content": "Task: inspect this repo, find the failing test, propose a fix, and summarize the patch."
    }
  ]
}
headers = {
  "Authorization": "Bearer YOUR_API_KEY",
  "Content-Type": "application/json"
}

response = requests.post(url, json=payload, headers=headers, timeout=60)
print(response.text)

## Evaluation checklist
- Did the model keep state across steps?
- Did it complete the task end-to-end?
- Did it preserve code, doc, or spreadsheet structure?
- Did it handle long context without drifting?
- Did it give a usable final artifact, not just commentary?

## Good test tasks
- Fix a failing test in a real repo
- Rewrite a Word doc while preserving headings
- Update a slide outline based on new requirements
- Analyze logs and identify the likely root cause
- Edit a spreadsheet summary without breaking formulas

## What to watch for
- Over-explaining instead of acting
- Forgetting earlier constraints
- Breaking formatting on multi-turn edits
- Losing thread in long tool chains
- Refusing to commit to a concrete next step

這段就是我會直接複製進專案的版本。不是那些漂亮卻空的 launch 文案，而是 prompt 結構、API 呼叫、評估清單。你要把 agent 做成能交付的東西，關鍵就是 system prompt 要獎勵執行、user prompt 要帶真實上下文、evaluation checklist 要懲罰漂移。少一個都很容易變成「看起來很忙，其實沒交貨」的假自動化。

我自己的判斷很簡單：如果模型撐不住有狀態、有 artifacts、還要反覆修正的任務，我就不會把它放到使用者前面。M2.7 至少看起來是朝這個門檻設計的，所以我才覺得它比一般模型發布文案更值得拆。

原始來源是 https://www.minimax.io/models/text/m27。這篇是我根據 MiniMax 自己公開的內容做的開發者拆解，模板段落則是我把它整理成可直接複製的版本。