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，因此仍需评估是否值得长期使用。
MiMo 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_ANALYSIS=false 关闭，但“默认开启且命名为 analysis”的设计并不理想。也有用户指出，即使关闭遥测，工具仍会自动检查更新并获取 MiMo 模型列表，不过这些行为也可以禁用。
或许，MiMo Code 想要效仿 Claude Code 快速 vibe 出一个产品，然后放到真实用户中不断改进，直至产品逐渐成熟并商业化。但这需要团队后续很强的工程能力不断弥补，还有未来更强模型的加持，此外也要承担小米在国内开发者中的口碑流失风险。不过，这些问题并非小米自己的，任何要走这条路线的公司都会面对。
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 等闭源工具的一次挑战。
从技术路线看，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 循环，真正的工程复杂度存在于围绕它构建的外围系统之中。
Claude Code 架构图
VILA 实验表示，Claude Code 的每一项设计选择都可以追溯到人的决策权、安全性、可靠性、能力放大和适应性。系统有 7 层安全机制，但它们都受到性能约束影响。此外，跨层交织的 Harness 难以重新实现，其中循环很容易复制，但 hooks、分类器、压缩机制和隔离机制并不容易复制。
相比之下，根据小米的博文，MiMo Code 更聚焦长程编程任务，围绕“计算、记忆、进化”三条主线，强化决策质量、多轮状态连续性和跨 session 的经验沉淀。
小米 MiMo 团队认为，在短任务中，完整对话历史通常可以作为工作记忆。但当任务进入几十轮甚至上百轮后，上下文窗口、指令遵循率和任务状态管理都会成为瓶颈。随着工具输出、代码片段和报错日志不断累积，上下文窗口终会被填满，简单摘要压缩会强化近处信息、衰减远处信息，无法按需回溯；即使窗口足够大，模型也会因为输入过长而难以提取当前真正应该执行的约束与意图。
为此，MiMo Code 将长程编程 Agent 的瓶颈拆分为三个时间尺度：同一 session 内的单轮决策质量主要受限于计算量、同一 session 内的多轮任务连续性主要受限于状态管理，以及跨 session 的任务改进主要受限于经验提炼机制。对应到产品设计上，就是“计算、记忆、进化”三条主线。
MiMo Code Harness 主循环状态机
在计算层面，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 文档。
参考链接：
https://arxiv.org/abs/2604.14228?utm_source=chatgpt.com
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。