小米开源终端编程 Agent 产品 MiMo Code与 Claude Code 对比优势显著且工程重点分化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 个 issuesMiMo 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_ANALYSISfalse 关闭但“默认开启且命名为 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 循环真正的工程复杂度存在于围绕它构建的外围系统之中。VILA 实验表示Claude Code 的每一项设计选择都可以追溯到人的决策权、安全性、可靠性、能力放大和适应性。系统有 7 层安全机制但它们都受到性能约束影响。此外跨层交织的 Harness 难以重新实现其中循环很容易复制但 hooks、分类器、压缩机制和隔离机制并不容易复制。相比之下根据小米的博文MiMo Code 更聚焦长程编程任务围绕“计算、记忆、进化”三条主线强化决策质量、多轮状态连续性和跨 session 的经验沉淀。小米 MiMo 团队认为在短任务中完整对话历史通常可以作为工作记忆。但当任务进入几十轮甚至上百轮后上下文窗口、指令遵循率和任务状态管理都会成为瓶颈。随着工具输出、代码片段和报错日志不断累积上下文窗口终会被填满简单摘要压缩会强化近处信息、衰减远处信息无法按需回溯即使窗口足够大模型也会因为输入过长而难以提取当前真正应该执行的约束与意图。为此MiMo Code 将长程编程 Agent 的瓶颈拆分为三个时间尺度同一 session 内的单轮决策质量主要受限于计算量、同一 session 内的多轮任务连续性主要受限于状态管理以及跨 session 的任务改进主要受限于经验提炼机制。对应到产品设计上就是“计算、记忆、进化”三条主线。计算层面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 更少、格式错误率更低。任务编排两者的差异体现在任务编排上。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() 原语、日志恢复和沙箱内文件读写等能力。记忆机制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 文档。
小米开源 MiMo Code，对比 Claude Code 优势显著且工程重点分化
小米开源终端编程 Agent 产品 MiMo Code与 Claude Code 对比优势显著且工程重点分化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 个 issuesMiMo 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_ANALYSISfalse 关闭但“默认开启且命名为 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 循环真正的工程复杂度存在于围绕它构建的外围系统之中。VILA 实验表示Claude Code 的每一项设计选择都可以追溯到人的决策权、安全性、可靠性、能力放大和适应性。系统有 7 层安全机制但它们都受到性能约束影响。此外跨层交织的 Harness 难以重新实现其中循环很容易复制但 hooks、分类器、压缩机制和隔离机制并不容易复制。相比之下根据小米的博文MiMo Code 更聚焦长程编程任务围绕“计算、记忆、进化”三条主线强化决策质量、多轮状态连续性和跨 session 的经验沉淀。小米 MiMo 团队认为在短任务中完整对话历史通常可以作为工作记忆。但当任务进入几十轮甚至上百轮后上下文窗口、指令遵循率和任务状态管理都会成为瓶颈。随着工具输出、代码片段和报错日志不断累积上下文窗口终会被填满简单摘要压缩会强化近处信息、衰减远处信息无法按需回溯即使窗口足够大模型也会因为输入过长而难以提取当前真正应该执行的约束与意图。为此MiMo Code 将长程编程 Agent 的瓶颈拆分为三个时间尺度同一 session 内的单轮决策质量主要受限于计算量、同一 session 内的多轮任务连续性主要受限于状态管理以及跨 session 的任务改进主要受限于经验提炼机制。对应到产品设计上就是“计算、记忆、进化”三条主线。计算层面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 更少、格式错误率更低。任务编排两者的差异体现在任务编排上。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() 原语、日志恢复和沙箱内文件读写等能力。记忆机制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 文档。
