MiMo-V2.5-Pro 把 agent 工作變成一個 API

這篇直接拆 MiMo-V2.5-Pro 怎麼接進 agent 工作流，最後給你可複製的 OpenRouter 設定模板。

我玩 agent 模型玩到一個地步，看到規格頁就會先皺眉。很多頁面都在賣一種感覺：長上下文、強工具能力、能做長任務。聽起來很猛，實際上常常是另一回事。我用了一輪 MiMo-V2.5-Pro，在 OpenRouter 上看它的說法，第一個反應不是「哇」，而是「這次到底是模型真的能幹，還是又一個會講話的 demo」。

我最煩的是那種模型，平常回得很順，真丟進工具迴圈、髒 repo、或需要收斂而不是熱情的任務時，立刻散掉。這次我想看的很簡單：它值不值得放進 production-ish 的 agent stack，OpenRouter 的 routing 到底是幫忙還是多一層麻煩，還有價格是不是便宜到讓人想亂用。

這篇的觸發來源就是 MiMo-V2.5-Pro 的 OpenRouter 模型頁。我也一起對照了 OpenRouter 文件、quick start、routing modes。我只用頁面真的有寫的東西：ClawEval、GDPVal、SWE-bench Pro，還有 $0.435 / 百萬 input tokens、$0.87 / 百萬 output tokens 這組價格。

它不是聊天玩具，是 agent 預算表上的一列

MiMo-V2.5-Pro is Xiaomi’s flagship model, delivering strong performance in general agentic capabilities, complex software engineering, and long-horizon tasks, with top rankings on benchmarks such as ClawEval, GDPVal, and SWE-bench Pro. It can independently and autonomously complete professional tasks that would take human experts days or weeks, involving more than a thousand tool calls.

我把這句翻成白話：小米不是在賣你一個「更會聊天的模型」，它是在說「拿我去做一串決策、工具呼叫、重試、狀態維持的工作」。這是完全不同的定位。你如果只是要一個會回答的東西，市場上多得是；你如果要的是能扛住一千次 tool call 還不亂跑的 worker，這才是重點。

我之前踩過太多次這種坑。模型短答很漂亮，一進 repo 就開始亂加註解、提早下結論、忘記約束，或者每一輪都想重寫計畫。這種東西看起來像在思考，實際上是在耗損你的時間。long-horizon tasks 這幾個字我會特別盯著看，因為 agent 最常死的地方就是這裡。

實操上，我會把 MiMo-V2.5-Pro 當成 worker，不當 brainstorm partner。你要先定義任務邊界、工具政策、停止條件。若你的系統本來就有 planner / executor 分離，這種模型比較適合放 executor 那層。若只有單模型迴圈，那 system prompt 就要更硬，工具重試次數也要鎖死。

• 適合有明確狀態的工作：改 code、修檔案、ticket triage、結構化研究。
• 不適合開放式發散，除非你想收一坨很自信的垃圾。
• 成功條件最好能機器檢查，不要只靠人眼猜。

1M context 才是這頁最有料的地方

模型頁寫它的 context length 最多到 1M。這不是裝飾數字，這會直接改變我怎麼想 retrieval、memory 跟 chunking。上下文一百萬 token，代表你可以把超多資料塞進同一輪裡，少掉很多 retrieval hop，也少掉很多因為多次傳遞而丟失的資訊。

但我也不想把大 context 神化。window 再大，不代表模型就會自動注意你塞進去的每一段。大多數人拿到大上下文，第一反應就是「那我可以亂塞了」。不行，這只會讓你更容易把 prompt 弄成垃圾場。模型不是魔法師，它只是有更大的桌子給你亂放東西。

我比較在意的是：1M context 最適合用來減少 fragmentation，不是拿來偷懶。像大型 spec bundle、長 issue thread、多檔 refactor、或需要讓前面決策一直留在視野裡的 agent run，這種場景會很有感。你不用一直摘要、壓縮、再摘要，很多細節就不會在中途漏掉。

我之前做長任務鏈時，最容易炸掉的就是摘要步驟。每摘要一次，語氣、限制、例外條件就掉一點。上下文夠大，這個漏水點就小很多。這不是什麼浪漫的 AI 故事，這就是工程上少踩一個坑。

實作上，我會在 prompt 裡放一個很短的 task ledger，不要靠模型自己從長文推斷現在進度。把 goal、constraints、done、next、blocked 固定放在一個區塊，每輪刷新。

• 維持一個 running state：goal、constraints、done、next、blocked。
• 原始素材只保留跟當前決策直接相關的部分。
• 做 code 任務時，優先放檔名和 diff，不要整包 repo 硬灌。

OpenRouter 重要，因為 provider 亂流是真的會害死人

OpenRouter 說同一個 model 可能由不同公司代管，然後你可以選 routing mode：Balanced、Nitro、Exacto。這聽起來像底層 plumbing，但我很在意，因為這會決定你的 agent 是穩，還是今天能跑、明天像中邪。routing 文件這種東西常常被人跳過，結果出事時才發現問題不在模型，是在你沒控制好 provider。

白話一點講，OpenRouter 在這裡比較像 control plane，模型是 payload。你如果遇過某個 provider 半夜開始抖，然後 production agent 就一路 timeout，你就知道這層有多重要。OpenRouter 還說它會持續監控 provider，出錯時會 retry 到下一個可用 provider。這不性感，但這就是能不能活著上線的差別。

我自己吃過太多 API integration 的虧：測試時都正常，一到真實流量，hosting 層行為一變，整個 workflow 就開始變成 support ticket 製造機。routing mode 的價值就在這裡。你要的是便宜、快、還是可重現，這三個目標不能混著選。

實操上，我會先照任務挑模式，不是照心情挑。

• Balanced：想讓價格和速度自動折衷時用。
• Nitro：延遲比成本重要時用。
• Exacto：你要固定 provider、方便除錯時用。

如果你是在評估模型，我會建議先用 Exacto，先把 provider 變因鎖住。等模型行為穩了，再切 Balanced 看成本。這個順序比較不會把你自己搞暈。

價格低到會讓人亂開 loop，所以你更要管住 token

頁面上的價格是 input $0.435 / 百萬 tokens、output $0.87 / 百萬 tokens。這種價位很容易讓人開始幻想：那我是不是可以開超長 agent loop、塞超大 prompt、讓它一直想下去。可以想，但不要太快爽。因為便宜 output 很常變成昂貴 workflow，尤其當你的 agent 開始重試、重講、或產生一堆沒必要的中間文字。

我會把這句話講白一點：價格只在你的 control loop 夠乾淨時才有意義。這種模型真正吸引人的地方，是你可以把上下文成本攤在一個長任務上。如果你的 app 仍然在重複灌 prompt、tool chatter 也很肥，那你只是換個地方燒錢而已。

我見過團隊把模型成本壓低，結果總花費反而上升，因為他們只砍了模型單價，沒砍 orchestration 的肥肉。模型變便宜，流程沒變好，最後只是跑得更快、更大量地浪費。這很常見，也很煩。

實作上，我會先做 token economy，再談 scale。工具輸出要結構化，重複指令要刪，穩定上下文要快取。OpenRouter 文件也提到，重複 context 的有效價格可以便宜 60–80%，這種細節在會重用 task frame 的 loop 裡真的有差。

我的原則很簡單：如果某一步不會改變決策，就不要一直為它付 token。

這些 benchmark 是工作提示，不是拿來拜的

OpenRouter 列的 benchmark 是 ClawEval、GDPVal、SWE-bench Pro。至少它沒有只丟一堆模糊詞，我可以知道它想把你帶去哪裡：agent 執行、軟體工程、長任務流。這比那種只會說「表現優異」的頁面誠實一點。

白話講，我會把這些 benchmark 當成 workload hint，不會當成它在所有事情上都最強的證明。你如果要的是 coding assistant、repo navigation、multi-step task completion，這些 benchmark 有參考價值。你如果要的是文案、客服語氣、或品牌聲線，那它們就沒那麼有用。

我現在看模型頁都會問一個很直白的問題：這個 benchmark 像不像我真的會遇到的 failure mode？如果不像，我就不會被它牽著走。很多模型在 leaderboard 上看起來很漂亮，一進你自己的任務形狀就開始歪掉，這種事我看太多了。

實操上，我會把 benchmark 對應到內部任務，而不是對應到行銷文案。

• 軟體工程 benchmark → code review、refactor、test generation。
• agentic benchmark → ticket resolution、tool chaining、狀態式 workflow。
• long-horizon benchmark → research synthesis、多步驟 ops 任務。

如果 benchmark 跟你的工作不長得像，就別讓它主導決策。先當線索，再拿自己的資料測。

OpenAI-compatible API 很無聊，但我就是愛這種無聊

OpenRouter 說它的 API 跟 OpenAI 相容，大多數 SDK 只要換 base URL 就能接。很好，這種句子很無聊，但我喜歡。代表我不需要因為一個品牌包裝，去重寫半套 integration。對我來說，這種「無聊」就是省時間。

白話講，模型換了，client 形狀大致不變。這會大幅降低試驗成本。你可以把 MiMo-V2.5-Pro 塞進既有 agent stack，比對行為，其他 plumbing 繼續維持穩定。當你要橫跨多個 provider 做比較時，這件事尤其重要，因為你不想最後測到的是 adapter，不是模型。

我之前比較模型時最討厭的就是 API shape 不一致。你本來想學模型，結果變成在 debug 轉接層。OpenAI-compatible endpoint 不性感，但它讓評估比較誠實。至少你知道自己在看什麼。

實作上，我會保留一個很薄的 provider adapter，base URL 指向 OpenRouter，model selection 放 config，不要寫死在 code 裡。這樣你要換成 MiMo-V2.5-Pro 或別的模型，不用動整個 agent。

但我也要提醒一句：相容 API 只有在你的 prompt、tools、output parsing 夠乾淨時才真的有用。你如果本來就寫得亂，compatible 只會幫你更快把亂流擴大。

可抄的模板

## MiMo-V2.5-Pro agent setup via OpenRouter

### 什麼時候用
用 MiMo-V2.5-Pro 來做長任務、工具很多的工作：
- codebase refactor
- issue triage
- research synthesis
- multi-step agent workflows
- 需要共享大上下文的任務

### Provider 策略
- 測試期先用 `Exacto`，把 provider 行為固定住。
- 上 production 後，如果你在乎成本和速度的平衡，再切 `Balanced`。
- 只有在延遲比可重現性更重要時才用 `Nitro`。

### System prompt 範本
You are a task executor.

Goal:
{one-sentence goal}

Constraints:
- Do not change unrelated files
- Prefer minimal diffs
- Ask before destructive actions
- Keep outputs structured

State:
- Done: {completed steps}
- Next: {next step}
- Blocked: {open issues}

Tools:
- Use tools only when they reduce uncertainty
- Stop when the task is complete
- Report failures with exact error text

Output format:
1. Summary
2. Actions taken
3. Files changed
4. Remaining risks

### OpenRouter request example
{
  "model": "xiaomi/mimo-v2.5-pro",
  "messages": [
    {"role": "system", "content": "You are a task executor..."},
    {"role": "user", "content": "{task}"}
  ],
  "temperature": 0.2
}

### Guardrails
- 保留一個 running task ledger。
- 工具輸出要結構化。
- 只刷新有變動的 state。
- tool call 重試次數要封頂。
- 刪掉重複指令，別浪費 context。

### 評估清單
- 多次 tool call 後還有沒有跑題？
- 能不能跨 turn 保住 constraints？
- 有沒有不必要地反覆重做計畫？
- provider 切換時行為有沒有變？
- 長上下文下輸出還有沒有用？

### 起手式 config
provider: openrouter
model: xiaomi/mimo-v2.5-pro
routing_mode: exacto
temperature: 0.2
max_retries: 2
context_policy: keep_state_compact
output_style: structured

這段模板是我自己整理的，不是 OpenRouter 原封不動給你的。它是從 模型頁、routing 文件，再加上我自己被 agent workflow 搞到很煩之後整理出來的。你可以直接貼進自己的 stack，再慢慢改成你要的樣子。

如果你想自己對照原文，從 MiMo-V2.5-Pro 模型頁開始，再看 OpenRouter docs、quick start、routing。這篇不是官方說明書，我只是把它翻成比較像工程現場會用的版本。來源有標的我都標了；模板和判讀是我自己的整理。