Mimo Code 爆火：我們挖開源代碼，找到小米 AI 的真創新

雷峰網訊 6 月 11 日凌晨，小米 MiMo 團隊公開了一個叫 MiMo Code 的項目，定位是終端編程 Agent，MIT 協議開源。官方宣傳重點有三處，14 天 5 人團隊投入的“vibe coding”開發敘事、Claude Code 之上的 SWE-Bench Pro 跑分。以及“無限上下文”的記憶架構。關注紛至沓來，短短幾天，倉庫就收到了 9000+ stars、800+ forks、近 700 個 open issues / PR。然而輿論也很快出現分化，一波是對 Mimo Code 中 checkpoint-writer + 四層記憶這套工程設計的肯定，另一波則在追問，大廠為什麼 fork 別人的項目，為什麼 Mimo Code 有大量 issue 但合併率極低？事實層面，Mimo Code 是一次基於 anomalyco/opencode 的 fork 不假，但挖開源碼，仍然能夠看到不少具有工程深度的真創新。可發佈後的運營節奏，又確實讓人很難判斷，它到底是一款“實驗 demo”還是“正式產品”。這種定位上的模糊，或許是一個讓我們靜下來思考 Harness 以及開源這件事本身的契機，關於小米為什麼要做 Harness，以及今天 Harness 的方向、流派、分歧與共識。01小米為什麼要做 Harness？這個問題本質上在聊，當一個 AI 公司選擇去深耕 Harness 時，它到底在選擇什麼？目前整個行業有這麼幾個方向：做模型：攻堅底層模型能力（GPT、Claude、DeepSeek、MiMo）做 harness / agent 架構：把模型接入真實工作流的運行框架（Claude Code、Codex、OpenCode、OpenClaw）做應用：面向終端用戶的 AI 產品（ChatGPT、Claude.ai、小愛同學、豆包）其次還有做基礎設施 / Infra（vLLM、LangChain）、訓練數據和評測以及做芯片/算力的選擇。但對於綜合實力較強的消費電子和互聯網基因的公司，最相關的還是前三塊，成熟的 AI 公司也都在努力地湊齊這三塊拼圖。對 OpenAI 來說，也就是 GPT 系列模型、扮演 Harness 的 Codex 和作為應用層的 ChatGPT。Anthropic 也是如此，Claude 系列模型、Claude Code 加 Cowork、APP 端等應用三者的組合拳。原因很簡單，如果沒有自己的 Harness，模型就只能寄生在別人的 Harness 裡，也許自己到頭來只會是一個運營商。所以如果稍有餘力，去探索 Harness 本身利人利己，不管怎麼看都是一個相當明智的決定。但重新做一套 Harness 架構可能需要數月的時間，直接在開源項目上做顯然是更聰明的辦法。而 Mimo Code 遇到的最尖銳的質疑也來自這裡，一個 OpenCode 的分支。這種批評有沒有道理？一半一半。不成立之處在於，歷史上幾乎所有重要的開源項目，都是 fork 或站在前人肩膀上的。開源的本意就是促進行業繁榮與進步，這一整套機制的設計，都是為了讓後來者不用從零開始寫代碼，嘲諷 fork 行為就是在嘲諷開源本身。但另一方面，技術從來是很難孤立出來被單獨看待的。Mimo Code 不是一個創業小團隊或個人開發者做出來的項目，卻吃盡了一個大集團的宣發紅利。如果不是小米平臺的公開渠道，它不可能在 5 天內做到 8800 stars（截至 2026-06-15）。流量、聲量、媒體報道的討論，全是平臺帶來的。所以用大公司的渠道公開時，事情就不只是小團隊的事了。公眾面對的是小米，不是小米里的某幾個人。這時候對方掏出一個基於 OpenCode 的 fork，難免會讓以個人開發者為最大群體的開源社區感到一些憤憤不平。到這裡，需要先聊聊罰站了半天的男二，OpenCode。OpenCode 是由 Anomaly Innovations 團隊（前身為 SST 團隊）開發的開源 AI 編碼 Agent，採用 MIT 協議開源，截至 2026 年累計獲得約 17.5 萬 GitHub Stars。它定位為一個終端原生的 AI 編碼助手，以單個 Go 二進制形式運行，能夠直接讀取和修改代碼、執行測試、調用 LSP 獲取語義信息，並完成 Git 相關操作。OpenCode 最大的特點在於完全開源且模型無關，用戶既可以接入 Claude、GPT、Gemini、DeepSeek 等主流大模型，也可以使用本地 Ollama 等模型，而不會被特定廠商綁定。值得一提的是，OpenCode 的創始團隊曾經歷過一次分裂。創始人 Kujtim Hoxha 與後期核心貢獻者 Dax Raad、Adam Elmore 在項目歸屬和商業化方向上產生分歧。隨後項目發生分叉，Dax 和 Adam 在 SST/Anomaly 名下繼續開發新的 OpenCode，而原項目則由終端 UI 框架公司 Charm 團隊接管並最終更名為 Crush。期間社區還曾出現關於 Git 歷史重寫、貢獻記錄處理等爭議討論。目前社區中實際上存在兩個“OpenCode”項目，分別是已經歸檔的 opencode-ai/opencode，以及當前仍在活躍維護的 anomalyco/opencode。那麼它和大家熟知的 Openclaw、Hermes Agent 有什麼區別呢？簡單來說：Claude Code：Anthropic 官方旗艦，閉源、和自家模型緊密耦合OpenAI Codex CLI：OpenAI 官方 CLI，半開源（殼子 Apache-2.0、模型閉源）OpenCode：上面兩家的開源替代品，開發者需要的是一個不被一家鎖死的工具而回到我們的主角，Mimo Code 則有著 OpenCode 的骨架和 Hermes 的靈魂。他們選擇了 OpenCode 終端編碼 Agent 的形態，並加上了 Hermes 風格的進化機制，比如 dream/distill 提煉記憶和技能，本質上是在兩個開源思路上做集成與落地。我相信 Mimo 團隊一定有過很深刻的思考和改進，因為源碼看完後確實能發現很多創新。02計算、記憶與進化，MiMo Code 的驚喜這種創新基本上圍繞三條主線展開。首先是計算。Max Code 的設計確保 Mimo Code 能夠把事情做對。這套機制在每一輪決策時並行生成 N 個候選方案（默認 5），由同一個模型作為 judge 選最優執行。用 4-5 倍 token 消耗的代價，換來 SWE-Bench Pro 上提升 10-20% 的回報。這是個實驗性的功能，需用戶手動開啟（experimental.maxMode: true）。本質上的判斷是用算力換可靠性。此外，長程複雜任務交付質量，有相當一部分取決於 Agent 對於何時應當結束進程的判斷。Mimo Code 支持用戶用自然語言設置停止條件（如"所有測試通過且代碼已提交"）。主 Agent 每次想終止時由獨立 judge 模型審查任務“是不是真做完了”。Claude Code 也有類似的設計。不過它把這項任務交給主 Agent 自主判斷，Mimo Code 則顯式分離做事的 Agent和驗收的 Agent。第二個主線是自我進化，這也是 Mimo Code 創新點最多的地方。基於 Harness 的自我進化能力，無外是對任務歷史進行復盤和整合，輸出可複用的 skill 或 SOP 等產物，Mimo Code 也是根據這一思路上嘗試落地。其自我進化能力主要來自兩個方面：Dream：每 7 天自動跑，整理記憶（合併去重、路徑驗證、壓縮）Distill：每 30 天自動跑，識別重複工作模式，固化成可複用的 skill / CLI 命令 / 自定義 Agent / SOP這對於我們的測評有點尷尬。Dream 是 7 天週期、Distill 是 30 天週期，都不是一週以內的短期測評可以跨越的，因此只能看機制設計，沒發看實際效果。當然這也不算 MiMo Code 故意挖坑，長週期自進化的設計天然就有這種可驗證性問題。但效果延後這件事也意味著，如果團隊半年內停止維護，這部分功能就成了從未真正運行過的代碼。除了源碼，Mimo Code 還有一個技術亮點值得關注。README 沒提到的是，Mimo Code 中的 checkpoint-writer 是 fork agent。它在 spawn 時從父 agent 凍結了完整的 LLM request prefix（系統 prompt + 工具定義 + 已有消息），存為 ForkContext。同時它會共享父的 KV cache，也就是說 checkpoint 寫入時不需要重新計算已有上下文，這導致其 token 開銷遠比想象的低，這是真正的工程創新。簡單來說，傳統做法裡，派一個子 Agent 寫 checkpoint 時，子 Agent 是獨立的，要把已有的 100 輪對話從頭再讀一遍才能寫總結。但其實主 Agent 早就讀過這 100 輪，讀完之後還留下了一份昂貴的中間計算結果，叫 KV cache。MiMo Code 的做法是，checkpoint-writer 這個子 Agent 在派出來的那一刻，直接繼承主 agent 的 KV cache、系統 prompt、工具定義、所有消息（這個完整快照在源碼裡叫 ForkContext）。它不需要重讀歷史，醒來就站在主 Agent 此刻的“理解”上寫總結。這件事的意義不僅在於省了多少 token，而在於它讓 checkpoint 從一個昂貴、少打的事件變成廉價、可以頻繁打的常態。也正因為它便宜，MiMo Code 才能在 20%、45%、70% 這三個早期點位主動打 checkpoint，而不是等到 90% 上下文快爆時再倉促壓縮，那時候模型已經在長上下文中段 lost in the middle 了。普通的 subagent 架構，做不到這一點。最後一點則是記憶。Mimo Code 的記憶系統被劃分為四個層級：值得一提的是 cycle 機制。當上下文窗口快滿時，Mimo Code 會派 writer subagent 把狀態寫入磁盤，窗口接近上限時執行 rebuild，切斷當前窗口、用持久化文件做種子重建。一個“checkpoint 打點 + rebuild 收尾”的輪次序列叫一個 cycle，cycle 數沒有上限。checkpoint 觸發位置設計也很有講究，分別被設置在了配置預算的 20%、45%、70% 處。之所以不等到窗口快滿才觸發，時因為考慮到了高利用率下模型能力衰減的問題。這一套機制，共同保障了 Agent 在超長上下文任務中的連貫性。不過關於無限上下文，一個必須澄清的事實是，技術上任何 Harness 框架都無法突破底層 LLM 的物理 context window。Claude 200K、DeepSeek 128K、Kimi 200K，這一點由模型架構決定。MiMo Code 接哪個模型，物理上下文就是哪個模型的上限。框架不生產上下文，只搬運上下文，這是工程師層面的常識，也是宣傳話語最容易模糊的地方。工程上，MiMo Code 確實做到了有效的創新，比如此前我們介紹過的 checkpoint-writer，在 spawn 時凍結父 Agent 的完整 LLM request prefix、共享父的 KV cache，讓“寫 checkpoint”這件事的 token 開銷遠低於常規子 Agent。當物理窗口快滿時，Agent 把當前狀態壓進 11 個結構化字段（意圖、約束、任務樹等），新窗口用這些字段做 rebuild 繼續工作。這套機制實現的是邏輯會話無限延伸，一個目標可以跨越任意多次物理窗口，對用戶視角接近無感。體驗上，這還是有損壓縮，只是可能不影響使用。主線意圖、關鍵決定、當前任務樹這些被 checkpoint 直接覆蓋的內容跨窗口大概率保得住，具體的實現細節、試錯過的方案、對話語氣這些不在 11 個字段裡的信息，按 checkpoint 寫得好不好浮動，簡單線性任務接近真無限，複雜分支任務必然有信息流失。任何壓縮都是有損的，沒有例外。這不是 MiMo Code 一家的問題，是所有 Harness 共有的工程邊界。說到底，“上下文”到底是一個可以自定義的詞彙，還是行業的宣傳用語，業內到底有多少自定義空間？老實說，這個詞彙確實有精確的定義，但是越往上走越模糊。在 Transformer 論文層的定義是最精確的。sequence length（Transformer 原論文裡的物理量 n）和 context window（GPT-3 論文裡的超參數 n_ctx = 2048）都有嚴格數學定義，即一次 forward pass 裡 self-attention 能看到的 token 總數。這是物理量，能用數字寫在論文裡。在 LLM 工程層，定義仍然清晰。很多模型的 API 文檔裡寫的“context limit: 200K tokens”也是精確的，對應模型架構決定的硬上限。但到了 Agent 框架層，上下文的定義就開始模糊。一旦涉及 multi-turn、external memory、retrieval、checkpoint，“context”這個詞就不再是單一物理量。它可能指“模型本次能看到的”，也可能指“Agent 整個會話累積感知的”，也可能指“用戶體驗上感覺記得住的”。直到在營銷層，甚至出現故意模糊上下文含義地做法。“infinite context”、“unlimited memory”、“total recall”這些詞都是利用了上面那種模糊性，把工程層的“邏輯延續”和 transformer 層的“context length”故意混淆。所以「上下文」這個詞在底層是被嚴格定義過的，但當它從 transformer 論文到營銷文案時，每走一層，就會更模糊一些。行業裡其實有更精確的替代術語，persistent memory、session continuity、context compaction、retrieval-augmented context。每一個都是可被工程師審查的，問題只是不夠性感，滿足不了今天模型廠商的傳播需求了。03Harness 的方向在哪裡都聊到這裡了，我們跳出 MiMo Code 單點，俯瞰一下主流 Harness 的流派和分歧。說到底，所有人做 Harness 都在解決一件事，Agent 在長任務裡會失效。基於這個問題，大家分成了五大流派：捲上下文長度。Claude 1M、Gemini 2M、DeepSeek V4 1M 的選擇是把窗口做大。這是既然記不住就擴容的邏輯，但代價是計算成本指數級上漲，模型在長輸入中段會“lost in the middle”，給 100 萬 token，只看清頭和尾。卷壓縮。智能摘要、上下文管理是 Claude Code 的主要打法，有限窗口內做“壓縮與管理”，自動 compact 把舊消息變摘要。既然不能擴容，就把“垃圾”都掃走，此時摘要質量會決定一切，一旦摘錯就丟關鍵信息。卷計算，用更多算力換可靠性。MiMo Code 的 Max Mode 就在走這條路，Best-of-N 採樣、judge 模型、多 Agent 投票都是這套“單次答錯，就跑多次取最好”的邏輯。代價也顯而易見，token 消耗會呈幾倍的增長。卷自進化。讓 Agent 從歷史裡學經驗，把重複模式固化成可複用資產。這條路上 Hermes 是代表，MiMo Code 的 Dream/Distill 走的也是這個路徑。如此 Agent 不必在每次接到一個任務的時候都從頭再來，但抽象化能力完全依賴 judge 模型時，提煉出現錯誤也會汙染未來的表現。卷工程基礎設施。權限、安全、恢復、工具路由……這也是 Claude Code 重點關注的地方。此前社區對 Anthropic 2026 年 3 月意外洩漏的 Claude Code 源碼（約 51.2 萬行 TypeScript / 1906 個文件）的逆向分析顯示，真正屬於“AI 決策邏輯”的代碼只佔 1.6%，剩下 98.4% 都是確定性基礎設施，包括權限管理、上下文管理、工具路由、恢復邏輯、7 層安全機制。Agent 循環本身只是簡單 while。對於 Harness 來說，這是一個格外有意義的洞察，即模型可以替換，但圍繞模型的工程系統不能。當然，從前面的代碼比例也能看出來，這是一個爆炸級的工程複雜度，難以復刻。所有 Harness 的存在都基於一個共同的判斷，僅模型自己變強是不夠的。如果模型性能每年攀升一倍，根本沒人需要這麼複雜的 Harness。所有 Harness 的存在都是在賭，“未來很長一段時間，模型還不夠好，所以圍繞模型的工程會決定上限”。這是 Anthropic 和 OpenAI 在做的事，也是小米想做的事。這樣押注合不合理另說，但它解釋了為什麼 Harness 這條賽道突然擠進來這麼多公司。如果說大模型是腦子，那 Harness 架構就是性格。當智力水平無法左右，我們仍然可以在成長過程中打磨性格。良好的性格，經常能彌補腦子不夠用帶來的缺陷，這怎麼不是一種肉體超頻呢？也許大模型和 Agent 架構也是這個關係。OpenCode 之所以火爆，與其說是“好的架構能榨乾模型”，不如說是它在 Claude Code 閉源、Cursor 收費的窗口期精準踩中了“完全開源 + model-agnostic + 終端原生 + 部署簡單”這個市場空白。開發者要的不是更卷工程的 Harness，是一個不被一家鎖死的工具。OpenCode 本身沒有特別“卷壓縮”或“卷計算”的設計，它的優勢是“通用/靈活/開源”，不是工程上的精妙。那問題就來了，Mimo Code 做的這些創新，為什麼 OpenCode 自己不做呢？在持久記憶的優化方面，社區其實已經呼籲了半年，但 OpenCode 團隊基本都拒絕了。這構成了 MiMo Code 介入的真實空白。也許 Mimo Code 真的是苦天下久矣。但要補充的一個的事實是，OpenCode 整體倉庫其實非常活躍，每天有 release、有完整的 fix 體系、多人 maintainer 在 review PR。只是在持久記憶/跨 session 狀態這幾個特定方向上，團隊明確決定不做（issue #8043 持久記憶層被官方 closed as not planned，#16077 跨 session 記憶 open 著但官方零參與）。社區被迫自己動手開發了一些第三方插件：kuitos/opencode-claude-memory：給 OpenCode 加 Claude Code 兼容的記憶系統ApplauseLab/opencode-plugin-simple-memory：持久記憶插件各種 MCP server 形式的"外掛記憶"（Vestige 等）所以可以這麼說，MiMo Code 是基於社區呼籲了半年、OpenCode 官方明確不計劃做、用戶只能靠第三方插件湊合的真實需求。04fork it till you make it前面我們提到，為什麼大家會對 fork 這件再正常