解析華為 DevEco Code 和小米 MiMo Code，都基於 OpenCode，有什麼區別？
OpenCode 其實在圈內一直很受歡迎，但最近開始變得更出圈，主要是因為小米 MiMo Code 和華為 DevEco Code 都基於開源的 OpenCode 專案進行了二次開發/擴充，用來支撐自己的 AI 編程 Agent。
OpenCode 是一個開源的 AI 編程 Agent 實作，模型無關、生態支援不錯，確實適合被企業拿來做自己的 Agent 底座。
不過同樣是基於 OpenCode，這兩個專案的「二開」方向差異還是挺明顯：
- MiMo Code 屬於「通用終端 Agent 增強版」：重點放在長任務、持久記憶、checkpoint、subagent、Goal、workflow/compose 和 MiMo 模型接入
- DevEco Code 是定制 HarmonyOS 專項工具鏈場景：重點是 DevEco Studio、Hvigor、HDC、ArkTS 檢查、鴻蒙知識庫、裝置執行和 UI 驗證
如下圖瑣事，透過目前的專案結構變化可以看出來，雙方的修改和擴充方向差異還是很大的：
- MiMo-Code 裁剪了大量 opencode 的內建能力，核心是在執行時裡新增自己定制的 Agent 能力
- DevEco Code 基本保留上游基礎設施，然後疊加鴻蒙工具、文件、skills、spec 資源，刪減的幾個也都是類似 TUI、Stats 等領域的
從這個表也能看出核心差別：
- MiMo-Code 的核心是 Agent 執行時增強，比如：
memory、actor、task、workflow、history、inbox、team都服務於長程任務和多 Agent 協作 - DevEco Code 是垂直領域增強定制：
reference、security、spec、v2加上鴻蒙工具、skills、prompt，讓 Agent 更適合 HarmonyOS 工程開發
MiMo Code：通用 Agent 增強
MiMo-Code 的改動主要集中在讓 Agent 自主和「持久」上，對，為了「持久」，它還是定制了一套 Agent-Memory-Task-Workflow 體系。
MiMo Code 更多是把 OpenCode 改造成自己模型下的通用終端 Agent，最大改動的就是內建持久化記憶系統，支援「專案記憶、會話檢查點、任務進度」三重機制，主要是用來解決長會話「越用越偏」的場景。
思路就是讓主 agent 專心幹活，記錄完全外包，透過獨立 subagent 自動儲存狀態，視窗快滿時重建一份乾淨簡報，主 agent 接著幹。
同時 MiMo Code 定制的 Harness 配合 Compose 模式，可以實現 MiMo 模型深度協同，按 Tab 切換就能做到「自動完成設計-規劃-編碼-測試-審查」全流程。
還有一個
/dream指令，每 7 天自動觸發，透過獨立 Agent 讀取歷史會話和現有記憶檔案，執行合併、去重、驗證路徑有效性和壓縮，將分散的記憶收斂為一份緊湊的目前狀態，並更新全域記憶。
在實作上最核心的還是它的記憶系統，主要分成幾層：
記憶/狀態檔案或模組用途Project memoryMEMORY.md專案級長期知識、規則、架構決策Session checkpointcheckpoint.md目前會話結構化快照Scratch notesnotes.md臨時筆記Task progresstasks/<id>/progress.md每個任務/子任務的進度記錄FTS searchmemory/fts.sql.ts、memory/service.ts對記憶內容做檢索> 也就是把「會話狀態、專案記憶、任務進度」拆成不同層次，配合 checkpoint writer 自動維護。
另外 MiMo-Code 有樹狀任務結構，例如 T1、T1.1、T1.2 這種，它們會和 checkpoint/subagent 生命週期聯動，在 Agent 停止前會檢查未完成任務。
同時 MiMo-Code 把 OpenCode 的 task/subagent 思路擴充成更完整的 actor 系統，目前 actor 工具支援：
runspawnstatuswaitcancelsend
可以配合
TaskRegistry、ActorRegistry、ActorWaiter管理生命週期，等於是一套定制的多 Agent 執行模型。
而且 MiMo-Code 還增加了的 /goal 停止條件機制，這個 /goal 的核心實作是在 session/goal.ts ，也就是和會話相關，功能類似 Codex 的 /goal ：
使用者設定一個停止條件後，主 Agent 嘗試停止時，會由獨立 judge 模型根據完整對話判斷條件是否真的滿足，如果不滿足，就繼續推進任務。
最後就是 Compose 編排模式，模式支援 plan、execute、review、tdd、verify、merge、parallel、subagent 等內建 skill，也就是類似一套帶「需求 -> 計劃 -> 實作 -> 測試 -> 審查 -> 合併」的編排流程，也是 Mino Code 定制的特色支援。
所以 OpenCode 還是 OpenCode，但是小米把它改造成更適合自己需求的長程自治、跨會話記憶、多 Agent 協作和 MiMo 模型接入的通用編碼 Agent。
DevEco Code：鴻蒙開發專項增強
DevEco Code 是華為 HDC 2026 期間發布的，基於 OpenCode 定制開發，深度整合鴻蒙生態工具鏈，用來面向 HarmonyOS 應用開發的專用 AI Agent。
簡單來說，DevEco Code 更像是在 OpenCode 裡內建了一套 HarmonyOS 開發 Agent 工具鏈，有點類似之前我們聊過的 Android CLI，整個定制圍繞 HarmonyOS 工程做了一整套支援，包括：建立專案、修復編譯、執行到裝置、收集日誌、查鴻蒙知識庫、做 UI 驗證。
等於是增加了 DevEco Studio、Hvigor、HDC、ArkTS 檢查和裝置除錯相關整合。
例如：
工具說明build_project執行編譯建置並匯出建置產物start_app在模擬器或真機上執行應用hdc_log收集 / 清理裝置日誌 / 查看連接裝置verify_ui執行 UI 操作驗證功能是否正確check_ets_filesArkTS 靜態語法檢查arkts_knowledge_searchHarmonyOS / ArkTS / ArkUI 知識搜尋switch_cwd切換建置專案路徑
不過這裡需要稍微區分一下實作方式：
hdc_log、switch_cwd、arkts_knowledge_search是 DevEco Code 自己在packages/opencode/src/tool/下實作/註冊的本地工具build_project、start_app、check_ets_files、verify_ui等主要在packages/opencode/src/tool/lib/emulator_tools.json中宣告 schema，看起來是透過 DevEco/HarmonyOS 端的橋接能力暴露給 Agent，不是普通 shell 命令硬調- DevEco Code 還在
packages/opencode/src/tool/lib/env.ts裡做了DEVECO_HOME、DevEco Studio 版本、hvigorw.js、hdc路徑探測
比如遇到鴻蒙相關的編譯問題時，Agent 會優先走鴻蒙知識庫和專項工具來解決問題，官方的說法是可以大幅提高 AI 任務的成功率：
另外的鴻蒙知識庫搜尋 arkts_knowledge_search 會呼叫：
bash 代碼解讀複製代碼
https://cn.devecostudio.huawei.com/codeGenie/bigSearch
然後要求 deveco OAuth 登入，它的 tool 描述裡明確要求：
遇到
.ets、ArkUI decorator/lifecycle、HarmonyOS SDK API、DevEco/hvigor build error、@kit.*/@ohos.*API 等問題時，必須先查知識庫。
當然，DevEco Code 也不是完全只加了工具，也改了一些 Agent 編排，比如：
build：預設模式，允許 UI 驗證相關工具goal：更準確地說是 SDD Goal Agent，用於 spec 定義、規範驅動開發和功能驗證，這個倒不是 Mino Code 的 goal 那種spec-verify：隱藏 subagent，專門做 Harmony feature 的 build、deploy、UI verifyplan：禁止build_project、check_ets_files、start_app、hdc_log、switch_cwd、arkts_knowledge_search等執行類/依賴工具鏈操作
所以，回到 DevEco Code，同樣 OpenCode 還是 OpenCode，不過華為在它上面加了一套 HarmonyOS 領域工具鏈和領域知識庫，讓它在鴻蒙工程裡的編譯通過率、裝置除錯效率、ArkTS 問題定位等能力更強。
最後
所以，MiMo-Code 是把 OpenCode 改造成更強大、更有記憶、更適合長程任務的通用自主 Agent，而 DevEco Code 是把 OpenCode 改造成專為 HarmonyOS 開發者服務的垂直工程 Agent。
雖然都是基於 OpenCode，但技術路線幾乎不重疊，MiMo 強化的是「Agent 自治能力」，DevEco 強化的是「鴻蒙工程落地能力」。
至於為什麼它們不直接用 OpenCode 然後合併回上游？你看的定制化程度就知道不大可能回流，這些能力如果合併回上游，會直接破壞 OpenCode 的中立性立場，所以基於 OpenCode 也是一個省時省力的選擇。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
