<mark id="oztn4"></mark>
0
關注紛至沓來，短短幾天，倉庫就收到了 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
這個問題本質上在聊，當一個 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
這種創新基本上圍繞三條主線展開。
首先是計算。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。每一個都是可被工程師審查的，問題只是不夠性感，滿足不了今天模型廠商的傳播需求了。
03
都聊到這里了，我們跳出 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 官方明確不計劃做、用戶只能靠第三方插件湊合的真實需求。
04
前面我們提到，為什么大家會對 fork 這件再正常不過的開源行為這么抵觸？這和 OpenCode 主動放棄的優化方向聯系在一起看待，會更有意思。
本質上，社區反感的從來不是 fork，而是用 fork 的工作量換原創的關注度。Mimo Code 的工程深度毋庸置疑，但引起爭議的，是勞動和回報的不對稱感。
OpenCode 明確表示不會在持久記憶層等方向上投入精力，但需要強調的是，OpenCode 項目依舊非常活躍，每天上千個 issue 仍在被持續處理。
雖然說 Mimo Code 獲得的 issue 和 PR，相比 OpenCode 是海量的，但如果從客觀的合并率來看，OpenCode 第一周里有 64% 的 PR 被 merge，多數是 fix 和 feat，MiMo Code 第一周里只有 0.7% 的 PR 被 merge，全是文檔和二維碼。流量差 19 倍可以解釋 issue 數量，但解釋不了合并率 91 倍的差距。
把視野再拉長。OpenCode 至今仍在每天發 release（4 個月發了 100+ 個版本，截至 6-17 是 v1.17.7），6-17 當天還在 push commit，過去 7 天合并 62 個 PR。反觀 MiMo Code，6 天里只發了 v0.1.0 和 v0.1.1 兩個 release，且 v0.1.1 的 release notes 正文只有一行字 “MiMoCode v0.1.1”。
橫向對比 OpenClaw、Hermes 這種小團隊 maintainer 的項目，社區運維都比 MiMo Code 體面：
OpenClaw 有 priority 標簽體系、有 changelog、定期 release notes
Hermes 有 contributor 引導、明確的 issue triage 流程
MiMo Code 的運維節奏，比這些獨立小團隊還差一截。
所以不得不問的一個問題是，Mimo Code 到底在開一場發布會，還是在做一個踏實的開源貢獻？
開源社區的長期契約是，我打算把這個東西做好、做長，歡迎你加入和我一起共創。持久記憶這種需求，即使社區呼喊半年，OpenCode 仍然明確表示 not planned。MiMo Code 接住了 OpenCode 沒接的需求，但看起來接住后，它自己也沒接住自己。
一個完整的回旋鏢出現了。出于看不下去原作者不維護的姿態，Mimo Code 接管了一段路，但自己接管之后，又變成了下一個原作者。而 MiMo Code 是基于 fork 的，如果一個 fork 項目連后續維護都做不好，那它的存在意義就只剩在某個時間點公開了一些有趣的工程想法。這是 demo，不是產品。
我相信內部肯定在努力迭代，但維護不等于開源維護。享受公開的收益和關注，但回避公開的成本，比如迭代只放在內部做，做好再發出來，那也不難理解開源社區的個人開發者略有不爽的原因，github 倉庫不應該是誰家的廣告牌。
截止目前最新的項目情況，合并的 PR 幾乎全部來自內部團隊，社區貢獻基本沒被接納。
也就是說，6 月17 號之后那波“功能性 PR 大量合并”的活躍，本質是內部團隊把自己的開發工作通過 PR 流程合進主干，不是在吸納外部貢獻。從作者名（帶 -xiaomi/-Mimo/MiMoHardFather）也能直接看出來。
更準確的定性是：這是一個“閉環的內部開發恰好放在公開倉庫里”，更接近 build in public，而不是 open collaboration。 開源社區那條“歡迎你加入和我一起共創”的契約，仍然沒兌現。內部團隊把社區當 bug 上報渠道和測試用戶，而不是協作者。
內部 PR 合了 28 條、社區 PR 只合了 1 條（還是發布當天的文檔 URL 修正）；社區送來的 Windows、暗色模式、Termux、競態修復等十幾個 PR 掛著沒合，團隊卻用自己的內部 PR 重新實現了其中一部分（如重復檢測）。
其實從哪個角度看，這件事都有更穩重的做法。比如先內部迭代、小范圍 alpha 邀請制、厚積薄發再公開，或者更簡單，把 checkpoint-writer 這個真正有工程深度的設計先寫成一篇 ArXiv paper 發出去，讓整個圈子討論 idea，團隊暫時不承擔產品維護責任。Anthropic 和 DeepMind 經常這么做，在社區贏得的尊重程度反而比發產品更高。
否則現在這個倉促上線的姿態會讓人很難判斷，團隊究竟在做什么。是想推動行業重視長任務記憶這件事，是想給團隊掙個行業影響力，還是只是又一次搶窗口期、搶首發的 KPI 動作？
三種解釋都站得住一半，但三種加起來又都站不住。
但話說回來，當你站在岸上批評游泳者的姿勢時，你看不見水里的真實阻力。MiMo Code 團隊看 OpenCode 時，他們看到的是原作者不做長期記憶，但他們沒看到的是 OpenCode 團隊也面對過同樣的激勵、同樣的公共品困境、同樣的資源約束。
他們以為自己會做得更好，是因為他們站在岸上。但當他們跳下水之后，現實撲面而來了。現實是發布有 ROI 而維護沒有，社區只想用不想做貢獻的搭便車困境仍然存在，團隊五個人，模型每兩個月更新一代的資源壓力無時不在。大家是一樣的人，只是處境不同。
在工程深度之外，Mimo Code 給所有產品團隊提的一個醒是，想明白你我到底在水里還是在岸上。
雷峰網特約稿件，未經授權禁止轉載。詳情見轉載須知。
