作者 | 褚杏娟

6 月 11 日凌晨，小米 MiMo 團隊發布了自己的終端編程 Agent 產品 MiMo Code，并采用 MIT 協議開源。

開源地址：https://github.com/XiaomiMiMo/MiMo-Code

據介紹，該產品基于 OpenCode 構建，定位于面向長程自動化編程任務的終端編程 Agent，核心目標是解決 AI 編程 Agent 在幾十步甚至上百步持續執行中的決策質量、狀態連續性和跨任務經驗積累問題。 MiMo Auto 目前限時免費，基于 MiMo-V2.5，支持 100 萬 token 上下文。

羅福莉在 x 上寫道，“14 天、5 個人、一場 vibe coding 之旅。于是，MiMo Code 誕生了。”之后，她還透露有盲盒驚喜：Auto 模式下的新用戶可能會被隨機分配到 UltraSpeed 模式——MiMo-V2.5-Pro 將以 1000 tokens/s 的速度飛快輸出。

作為 AI 編程工具的翹楚，Claude Code 自然會成為重要參照物。

小米披露，MiMo Code + MiMo-V2.5-Pro 在三項離線 benchmark 中均優于 Claude Code + Claude Sonnet 4.6。不過團隊也指出，這些 benchmark 主要衡量單個倉庫級問題的一次性解決能力，而 MiMo Code 的多輪記憶、后臺狀態維護、完成度驗證和跨 session 進化等設計，主要價值仍需在持續幾十輪的真實開發場景中體現。

小米表示，在同一目標模型下對比 MiMo Code 與 Claude Code 的端到端真實開發體驗時，MiMo Code 的優勢會隨任務復雜度增加而放大。當執行步數在 200 步以內時，兩者勝率接近 50%；當步數超過 200 步，并包含多輪用戶交互后，MiMo Code 勝率升至 65% 以上。

有體驗過的用戶表示 MiMo Code 使用起來比較順手，UI 體驗不錯，響應速度似乎快于 Claude Code，并且可能向會話中注入更少冗余內容。也有用戶提到，自己獲得了 MiMo-V2.5-Pro UltraSpeed 模型訪問，認為其速度非常快，但成本高于 DeepSeek，因此仍需評估是否值得長期使用。

1 5.1k stars 和 229 個 issues

MiMo Code 自然引發了開發者們的關注。截至目前，該項目已經獲得了 5.1k star。

有用戶看到是基于 OpenCode 構建后表示，“啊，算了，它只是 OpenCode 的一個分支。”但也有人表示，如果之前是用 OpenCode 開發，那 MiMo Code 就是 OpenCode 的加強版。

有開發者擔憂現在開源生態里的 PR 太多問題。“OpenCode 可能是目前開源 Agent 中最成熟的那一個，只是官方看起來也是太忙了協調不過來 5000 多個 PR 沒人審核，不知道小米那邊會怎么搞，迅速涌入大量的 PR 來不及審核可能是 AI 時代的必然結果。”

事實上，確實如此。小米 MiMo Code 開源后，開發者的反饋正在迅速集中到 GitHub Issues 區，目前已經有超 200 條 Issues。

從當前公開 Issues 看，MiMo Code 暴露出了一批早期產品問題：包括使用非常卡、MiMo Auto 免費通道登錄后憑證未持久化、從 Claude Code 導入 API Key 失敗、升級后仍顯示 OpenCode 字樣、Termux 環境日志暴漲、WSL 安裝后運行異常、語音與粘貼功能不可用，以及更受關注的 Agent 未經確認自動刪除用戶全局 npm 包等。

尤其，有用戶反饋，MiMo Code 的 Agent 在執行任務時，自動檢測到用戶全局 npm 目錄下存在 OpenCode 相關包，包括opencode-ai、opencode-windows-x64、oh-my-opencode、oh-my-opencode-windows-x64等，并自行判斷這些包是遷移殘留，隨后未經用戶確認執行npm uninstall，導致用戶正在使用的 OpenCode 開發環境被破壞。

該用戶認為，Agent 不應在未經明確確認的情況下執行任何刪除操作，尤其是影響范圍較大的全局 npm 包操作。即使系統判斷某些包可能是殘留，也應該先詢問用戶確認。該用戶建議，對于npm uninstall、rm等刪除操作，必須增加確認機制，并考慮提供 dry-run 模式，先展示將執行的操作，再由用戶確認。

還有用戶反饋疑似存在內存泄露：“使用 pnpm 安裝打開后從未輸入任何內容，再回來發現內存占用過高。”

還有用戶反饋 MiMo Code 思考陷入重復螺旋：

除此之外，還有各種各樣的 bug，像是 Agent 執行過程執行了 2 個 dart 腳本，卡死 2 次等。

其他平臺上也有用戶指出了一些問題。比如，MiMo Code 默認開啟 telemetry，會向 tracking.miui.com 發送指標信息，包括正在使用的模型；雖然可以通過環境變量 MIMOCODE_ENABLE_ANALYSIS=false 關閉，但“默認開啟且命名為 analysis”的設計并不理想。也有用戶指出，即使關閉遙測，工具仍會自動檢查更新并獲取 MiMo 模型列表，不過這些行為也可以禁用。

或許，MiMo Code 想要效仿 Claude Code 快速 vibe 出一個產品，然后放到真實用戶中不斷改進，直至產品逐漸成熟并商業化。但這需要團隊后續很強的工程能力不斷彌補，還有未來更強模型的加持，此外也要承擔小米在國內開發者中的口碑流失風險。不過，這些問題并非小米自己的，任何要走這條路線的公司都會面對。

2 Coding harness 開源，會威脅 Claude Code 們嗎？

Claude Code、Codex 等工具正在成為開發者日常工作流的一部分，但這些工具是否鎖平臺，以及是否會在上下文、工具調用和遙測層面形成新的“黑箱”等也成為開發者們關注的問題。

有開發者評價 MiMo Code 的開源，“很好，coding harness 就應該開源，而大模型應該被視為商品化能力。這樣可以最大限度降低用戶的切換成本，也能讓人們更清楚地理解自己是如何與上下文以及大模型輸出進行交互的。現在整個行業的方向走偏了：Claude Code 一直保持閉源，盡管它已經多次泄露過源代碼；而開源的 Gemini CLI 也被逐步棄用，轉而讓位于閉源的 Antigravity CLI。”

對于上開發者的觀點，也有網友提出質疑：企業為什么要主動開源這些工具、降低用戶遷移成本？“這類似于要求云服務商把平臺全部開源、取消出口費用，讓客戶隨時離開。”在其看來，開源并不天然等于商業模式，企業沒有義務把有價值的產品層變成公共品。

這里的 coding harness 可以理解為把大模型接入真實編程工作流的一整套“運行框架”，大家自然地將模型和 coding harness 區分成了兩個不同的部分。MiMo Code 的開源也引發了大家對“coding harness 是否有護城河”的激烈討論。

一派認為，真正完成代碼任務的是底層模型，coding harness 本身并沒有太多神秘之處，更多只是用戶體驗層能力；另一派則指出，不同 harness 的配置、工具設計、人類審批機制、diff 展示、上下文注入方式，都會顯著影響最終效果。換言之，即便模型是核心發動機，運行時和工具層依然會決定 Agent 能不能穩定進入真實工程流。

“Claude Code 根本就沒什么特別之處。我們不需要他們的商業模式，他們才需要。”有開發者說道。

有人分析表示，Anthropic 通過 Claude Code 把大量訂閱額度與編程使用場景綁定，不只是賺取 token 收入，更是在獲得高價值軟件開發數據，并推動開發者圍繞其 harness 概念形成使用習慣。

Anthropic 原本只是通過 API token 獲得中等規模的收入，但當他們開始把大量使用額度打包進 Claude Max 的 20/100/200 美元訂閱套餐后，一切都變了。相對于 API token 的價格，這些訂閱套餐給出的使用額度非常夸張，但前提是你必須使用他們的 coding harness。而至少在 Claude Code 剛開始這么做的時候，它作為一個 coding harness，其實還不如很多開源工具。

嚴格來說，Claude Code 是一個免費產品，因為你可以用它接入任何模型。它對“一個 coding harness 應該如何工作”并沒有太多流行的、強主張式設計，但它卻是目前最受歡迎的同類產品，甚至在 OpenAI、Meta、Google 這些競爭對手的大模型工廠里也被廣泛使用。為什么？如果只是因為 Anthropic 的模型好 5%，大多數工作場所應該會優先按 token 效率，也就是成本效率來優化。

Anthropic 之所以能贏下自家 harness、自家 token 的使用量，同時還能獲得可觀收入，是因為他們大幅補貼了 token 消耗。

這給他們帶來了很多東西：

第一，關于軟件開發如何使用大模型的一手高價值數據。軟件開發既是大模型應用中最先受益的行業之一，也是最有錢、最愿意為此花錢的行業之一。

第二，把整個行業引導到圍繞他們的 harness 概念形成事實標準。某種意義上，他們正在把自己變成大模型交互接口領域的 W3C，只不過這是一個私營組織。

第三，所有這些數據。

這種判斷背后，是 AI 編程產品商業模式的變化。過去，模型公司主要依靠 API token 計費；而如今，編程 Agent 正在成為模型消費的高頻入口。因此，MiMo Code 的開源也被部分用戶視為對 Claude Code 等閉源工具的一次挑戰。

3 與 Claude Code 工程重點分化

從技術路線看，Claude Code 和 MiMo Code 都屬于“模型 + 運行時 + 工具調用循環”的終端編程 Agent。模型負責推理和決策，運行時負責管理工具、組裝上下文、執行命令、持久化狀態，并把工具結果反饋給模型進入下一輪。

但二者的工程側重點出現明顯分化。

通過對 Claude Code 的全面源碼級架構分析（覆蓋 Claude Code v2.1.88 版本，約 1900 個 TypeScript 文件、約 51.2 萬行代碼），同時結合精選社區分析、面向 Agent 構建者的設計空間指南，以及跨系統對比研究，VILA 實驗室得出結論：

Claude Code 代碼庫中，只有 1.6% 屬于 AI 決策邏輯，其余 98.4% 都是確定性的基礎設施，包括權限管理、上下文管理、工具路由和恢復邏輯。Agent 循環本身只是一個簡單的 while 循環，真正的工程復雜度存在于圍繞它構建的外圍系統之中。

Claude Code 架構圖

VILA 實驗表示，Claude Code 的每一項設計選擇都可以追溯到人的決策權、安全性、可靠性、能力放大和適應性。系統有 7 層安全機制，但它們都受到性能約束影響。此外，跨層交織的 Harness 難以重新實現，其中循環很容易復制，但 hooks、分類器、壓縮機制和隔離機制并不容易復制。

相比之下，根據小米的博文，MiMo Code 更聚焦長程編程任務，圍繞“計算、記憶、進化”三條主線，強化決策質量、多輪狀態連續性和跨 session 的經驗沉淀。

小米 MiMo 團隊認為，在短任務中，完整對話歷史通常可以作為工作記憶。但當任務進入幾十輪甚至上百輪后，上下文窗口、指令遵循率和任務狀態管理都會成為瓶頸。隨著工具輸出、代碼片段和報錯日志不斷累積，上下文窗口終會被填滿，簡單摘要壓縮會強化近處信息、衰減遠處信息，無法按需回溯；即使窗口足夠大，模型也會因為輸入過長而難以提取當前真正應該執行的約束與意圖。

為此，MiMo Code 將長程編程 Agent 的瓶頸拆分為三個時間尺度：同一 session 內的單輪決策質量主要受限于計算量、同一 session 內的多輪任務連續性主要受限于狀態管理，以及跨 session 的任務改進主要受限于經驗提煉機制。對應到產品設計上，就是“計算、記憶、進化”三條主線。

MiMo Code Harness 主循環狀態機

在計算層面，MiMo Code 引入 Max Mode 和 Goal。Max Mode 是并行采樣選優：每一輪并行生成多個候選方案，默認數量為 5，候選方案只做推理和工具調用規劃，不實際執行，隨后由同一個模型作為 judge，對比候選方案的推理過程和行動計劃，選出最優方案執行。它的目標是降低長任務中單步錯誤率被累積放大的風險。

小米 MiMo 團隊稱，在 SWE-Bench Pro 上，Max Mode 相比單次采樣提升 10% 至 20%，代價是約 4-5 倍 token 消耗。目前該功能仍處于實驗階段，需要手動配置開啟。

如果說 Max Mode 解決的是“做對”，Goal 機制則主要解決“做完”。在長任務中，Agent 容易在看到已有進展后過早宣稱任務完成，尤其在無人值守的自動化運行中，這類提前終止會放大失敗風險。Goal 允許用戶用自然語言設定停止條件，例如“所有測試通過且代碼已提交”。每當 Agent 嘗試終止時，系統會自動發起一次獨立模型調用，對完整對話歷史進行審查，判斷停止條件是否真正滿足；如果未滿足，則將具體差距反饋給 Agent 并要求其繼續。

這與 Claude Code 的停止機制不同。Claude Code 主要由主 Agent 自己判斷是否不再需要工具調用，外加 max turns、context overflow、hooks、abort 等系統條件；MiMo Code 則顯式引入獨立 verifier，把“做事的 Agent”和“驗收的 Agent”分開。

MiMo Code 還嘗試優化工具調用語法。團隊認為，模型通過何種格式發出工具調用，會直接影響準確率和 token 效率。部分模型在輸出結構化 JSON 時格式錯誤率較高，XML 相比 JSON 略好，而受限命令行語法在表達相同調用意圖時 token 更少、格式錯誤率更低。

編排：從自然語言流程到代碼化 workflow

兩者的差異體現在任務編排上。

Claude Code 的編排方式更偏模型逐步決策。模型看到上下文后決定下一步工具調用，工具結果返回后再決定下一步。它可以通過 AgentTool 委派子 Agent，也可以通過 MCP、skills、hooks 等機制擴展能力，但核心仍然是模型在循環中動態選擇動作。

MiMo Code 則提出 Dynamic Workflow，把復雜流程編排從 prompt 遷移到代碼。

小米認為，當任務規模擴大到整個項目遷移等場景，需要同時協調幾十甚至上百個并行工作單元時，傳統“把流程寫進自然語言 prompt 或 SKILL.md”的方式會系統性失效。因為自然語言流程容易被上下文壓縮吞掉，模型也可能跳過步驟，分支和重試邏輯依賴模型判斷而非代碼保證，導致同一流程多次執行路徑不一致。

Dynamic Workflow 的核心變化是將編排邏輯從 prompt 轉為代碼。主 Agent 會生成 JavaScript 腳本，在隔離沙箱中確定性執行，并通過 agent() 派出子 Agent，通過 parallel() 和 pipeline() 控制并發。小米表示，這樣可以讓模型的判斷力集中用于理解代碼和生成代碼，而不是承擔流程控制本身。

MiMo Code 的實現兼容 Anthropic Dynamic Workflow 的核心語義，并擴展了 workflow() 原語、日志恢復和沙箱內文件讀寫等能力。

記憶機制：從上下文壓縮到 rebuild

Claude Code 的記憶體系主要包括 CLAUDE.md、auto memory、JSONL session transcript 和子 Agent sidechain transcript。CLAUDE.md 用于存放項目級規則、編碼約定、構建方式、測試方式等可版本化信息；auto memory 存放對話過程中沉淀的自動記憶；session transcript 以 JSONL 形式記錄會話；子 Agent 的完整軌跡則寫入獨立 sidechain，父 Agent 只接收摘要，避免子任務過程污染主上下文。

這套設計強調透明、可審計、可恢復，但本質上仍是在有限上下文窗口內做“壓縮與管理”。

MiMo Code 的目標則是讓一個邏輯會話可以無限延伸，而每個上下文窗口仍保持有界，其基本機制是 Cycle：當會話接近窗口上限前，運行時會在固定位置觸發 checkpoint，并派出獨立的 writer subagent 讀取已有對話，將結構化狀態寫入磁盤；主 Agent 繼續工作，writer 并發執行。當窗口接近真正上限時，運行時執行 rebuild，切斷當前窗口并開啟新窗口，用已經持久化的文件作為種子重建上下文。

小米強調，checkpoint 不應等到窗口快滿時才觸發。原因在于模型在高上下文利用率下能力會衰減，長輸入中段材料更容易被忽略，也就是常說的“lost in the middle”；同時，提取和壓縮本身也需要上下文空間。MiMo Code 因此選擇在相對早期觸發 checkpoint，大致位于已配置預算的 20%、45%、70% 處，每次進行增量更新，避免最后一次倉促壓縮。

MiMo Code 沒有讓主 Agent 自己維護記憶，而是將記憶提取交給獨立 writer subagent，它不與主 Agent 共享注意力或 token 預算。

小米認為，要求一個正在調試復雜問題的模型同時維護結構化日志，往往會讓兩件事都做不好。因此，會讓 writer 寫入一份固定結構的 checkpoint 文件，包括當前意圖、下一步動作、工作約束、任務樹等 11 個字段。為了避免并發寫入導致狀態不一致，每個結構化文件只允許一個 actor 寫入。

在長期記憶體系上，MiMo Code 設計了四層記憶：Session 記憶用于當前邏輯會話，Project 記憶用于保存項目級持久知識，Global 記憶用于跨項目生效的用戶偏好，History 則以 SQLite 形式保存每個會話的完整軌跡，包括每條消息和每次工具調用原文。當結構化記憶無法找到細節時，Agent 可以通過 history 工具回溯原始記錄。

進化：從項目記憶到流程資產

在進化層面，MiMo Code 試圖讓 Agent 從跨 session 的經驗中持續改進。其項目級記憶文件采用 Markdown 格式，保存項目背景、用戶明確要求的規則、架構決定及其理由、反復驗證過的技術事實。

小米 MiMo 團隊選擇文件而非純向量數據庫，主要原因是可審查性：當記憶會影響 Agent 后續行為時，用戶需要能夠看到系統記住了什么，并刪除錯誤條目或修改過時知識。

為了維護項目記憶質量，MiMo Code 還設計了 Dream 與 Distill 兩類整理機制。Dream 每 7 天自動觸發，由獨立 Agent 讀取歷史 session 對話和現有記憶文件，執行合并、去重、路徑有效性驗證和壓縮，并更新全局記憶；Distill 每 30 天自動觸發，重點不是整理知識，而是識別反復出現的工作模式，并將其固化為可復用的 skill、CLI 命令、自定義 Agent 或 SOP 文檔。

https://arxiv.org/abs/2604.14228?utm_source=chatgpt.com

https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon

https://github.com/XiaomiMiMo/MiMo-Code/issues

聲明：本文為 InfoQ 原創，不代表平臺觀點，未經許可禁止轉載。

會議推薦

AICon 上海站 Keynote 嘉賓已集齊！來自復旦、清華、螞蟻、阿里云等高校知名教授與頂尖專家集結！從多模態、大模型落地與 Token 服務維度，拆解大模型從 “會回答” 到 “能執行” 的技術拐點。9 折倒計時最后一周，現在報名立減 580。