解析华为 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 memory	`MEMORY.md`	项目级长期知识、规则、架构决策
Session checkpoint	`checkpoint.md`	当前会话结构化快照
Scratch notes	`notes.md`	临时笔记
Task progress	`tasks/<id>/progress.md`	每个任务/子任务的进度记录
FTS search	`memory/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 工具支持：

run
spawn
status
wait
cancel
send

可以配合 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_files`	ArkTS 静态语法检查
`arkts_knowledge_search`	HarmonyOS / 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 verify
plan：禁止 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 也是一个省时省力的选择。