Mistral 把編碼代理搬上雲端

Mistral 把 Vibe 編碼代理搬到雲端沙箱，讓 Medium 3.5 接手非同步寫程式與產 PR。

說真的，這種改法很實際。以前 AI 寫程式像在你筆電旁邊盯著你。你得一直看著它，還怕 terminal 關掉。Mistral 在 2026 年 4 月 29 日丟出的這波更新，就是想把這個麻煩拿掉。

它把 Mistral 的 Vibe 編碼代理搬到雲端。核心模型是 Mistral Medium 3.5。你可以從 Mistral Vibe CLI 或 Le Chat 開工，然後等它自己跑完。

講白了，這不是把 AI 變更聰明。它是把工作流程改掉。從同步盯場，變成非同步執行。對重構、補測試、升套件、修 bug，這種模式更合理。

Vibe 這次到底改了什麼

先講舊模式。以前很多 coding agent 都卡在本機 terminal。你下指令，它開始跑。遇到分歧，你再進去接手。這對小改動還行。可是任務一長，問題就來了。

像是重構一整個 module，或是跑 20 分鐘的測試。你不可能一直守在那裡。更別說同時開 5 個任務。筆電一睡眠，整個 session 就容易亂掉。

Mistral 現在把執行層放進雲端 sandbox。每個 session 都是隔離的。依賴安裝、批次改檔、長時間任務，都不會互相干擾。它還加了 session teleporting。你本機開始的任務，可以接到遠端環境繼續跑。

• 任務可以非同步跑。
• 多個 session 可以平行執行。
• 做完會直接產出 GitHub pull request。
• 本機狀態可以轉到雲端。

這一點很有感。很多 agent demo 很會演。真的進工作流，問題就爆出來。像是 terminal 關掉、context 過期、或是人已經離開座位。Mistral 想做的是，把雲端變成預設執行地。

Medium 3.5 是這次的核心模型

Mistral Medium 3.5 是這次的主角。它現在扛聊天、推理、寫程式、agent 任務。這跟 Mistral 以前常把工作拆給不同模型的做法不太一樣。

以前你可能要在 Medium 3.1、Magistral、Devstral 2 之間切來切去。現在它想用一個 dense model 包下來。這對開發者很直白。少切工具，少切上下文，少一點心智負擔。

它支援可調整的 reasoning effort、原生 function calling、JSON 輸出，還有 24 種語言。這些功能都很務實。不是拿來唬人，是拿來接產品和 API 的。

“Mistral's release reflects vendors competing to own the cloud execution surface for coding agents. Async, parallel sessions in isolated sandboxes move agent runtime off the developer's laptop and into infrastructure that procurement, security, and platform teams now have to govern.” — Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group

我覺得 Ashley 講得很準。真正麻煩的，不是模型分數。是誰管這些 session。資料在哪裡跑。權限怎麼記。這些才是企業會先問的事。

如果 agent 要碰到 production-adjacent codebase，安全團隊就不會只看 benchmark。它們會先看隔離、審批、稽核紀錄。Mistral 這次就是在回答這些問題。

數字上看起來怎樣

Mistral 說 Medium 3.5 在 SWE-Bench Verified 拿到 77.6%。這個 benchmark 是拿真實 GitHub issue 來測。不是那種只會聊天的假題目。

價格也很直接。API 是每百萬 input token 1.5 美元，output token 7.5 美元。對要大量跑 agent 的團隊來說，這種數字會直接進預算表。不是看起來漂亮就好。

更重要的是自架門檻。Mistral 說最少 4 張 GPU 就能跑。對很多想做私有部署的團隊，這比動輒十幾張卡友善很多。模型權重也放在 Hugging Face。

• 77.6% 表示它在修 bug 類任務上有競爭力。
• 1.5 / 7.5 美元的定價，算是偏好控制成本。
• 4 張 GPU 讓私有部署比較可行。
• 24 種語言，對跨區團隊很實用。

還有一個細節不能忽略。它用的是 modified MIT license。這跟 Mistral 早期常見的 Apache 2.0 不一樣。高營收公司要特別看條款。這種地方最容易出事。

跟其他編碼代理比，差在哪

這次 Vibe 的定位，不是要取代 issue tracker、chat app，或 observability 工具。它是把 agent 接到既有工作流裡。像 GitHub、Linear、Jira、Sentry、Slack、Teams，它都想接。

這個方向很合理。因為工程團隊不想再多養一個孤島工具。你如果每天已經在看 PR、issue、告警和聊天紀錄，再多一個獨立介面，只會更煩。

Mistral 想解的，是那些最常見的重複工。像是 module refactor、test generation、dependency upgrade、CI investigation、bug fix。這些工作不性感，但很吃時間。讓 agent 在雲端慢慢跑，比你守著螢幕划算。

• OpenAI 也在推 coding help。
• Anthropic 也在往 agent 工作流走。
• Cursor 已經把 AI 寫程式做成日常工具。
• Mistral 的特色是 CLI、Le Chat、雲端 sandbox 三者綁得比較緊。

差別其實很簡單。別人多半還是在幫你寫。Mistral 是想幫你把整段任務做完，最後丟 PR 給你看。

這對工程團隊代表什麼

這波更新的重點，不是 AI 又更會寫 code。重點是執行位置換了。現在是雲端先跑，筆電只當控制台。這對團隊協作很有用。

如果你只拿 AI 來補幾行程式，那這套可能有點重。可是一旦你想讓 agent 接手一整段 routine work，像是改測試、修依賴、清 CI，雲端模式就合理很多。

我會這樣看。第一批吃到好處的，應該是 repo 整潔、review 規則清楚、而且能接受非同步流程的團隊。因為這種團隊最知道，真正省時間的不是 prompt，而是少掉反覆切換上下文。

但問題也很現實。長時間 session 的記憶怎麼處理。敏感 code 怎麼隔離。稽核怎麼留。這些都不是 demo 影片會講的。可是企業真的會問。

下一步我會看什麼

如果 Mistral 想讓 Vibe 真正進到團隊日常，它要證明一件事。不是模型分數，而是 session 真的穩。能跑幾小時。能不能接手中斷任務。能不能讓人放心把重複工作丟出去。

我自己的判斷是，這條路會越來越像基礎建設。未來比的不是誰會聊天。是誰能把 agent 安全地放進 repo、CI 和 PR 流程。

如果你在評估導入，先別問「它聰不聰明」。先問「它能不能在你們的權限和審批規則下穩定跑」。這題答得出來，才值得往下試。