5人2周肝出5.1k星！小米 MiMo Code开源但bug不断，开发者炸锅

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，因此仍需评估是否值得长期使用。 5.1k stars 和 229个 issues 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 出一个产品，然后放到真实用户中不断改进，直至产品逐渐成熟并商业化。但这需要团队后续很强的工程能力不断弥补，还有未来更强模型的加持，此外也要承担小米在国内开发者中的口碑流失风险。不过，这些问题并非小米自己的，任何要走这条路线的公司都会面对。 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 本身并