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 的速度飞快输出。
作为 AI 编程工具的标杆，Claude Code 自然成了主要的参照对象。
小米披露，在 SWE-bench Verified、SWE-bench Pro、Terminal Bench 2 三项离线 benchmark 中，MiMo Code + MiMo-V2.5-Pro 的组合均优于 Claude Code + Claude Sonnet 4.6。
不过团队也指出，这些 benchmark 主要衡量的是单个仓库级问题的一次性解决能力。而 MiMo Code 在多轮记忆、后台状态维护、完成度验证及跨 session 进化等方面的设计，其核心价值仍需在持续几十轮的真实开发场景中才能充分体现。
小米表示，在锁定同一目标模型的前提下，对比 MiMo Code 与 Claude Code 的端到端真实开发体验时，MiMo Code 的优势会随任务复杂度的增加而放大。当执行步数在 200 步以内时，两者胜率接近五五开；当步数超过 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 可能是目前开源 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-ai、opencode-windows-x64、oh-my-opencode 及 oh-my-opencode-windows-x64 等与 OpenCode 相关的包，并自行判定这些是迁移残留，随后未征求用户意见便执行了 npm uninstall，导致用户正在使用的 OpenCode 开发环境被破坏。
这名用户认为，Agent 绝不应在未经明确确认的情况下执行任何删除操作，尤其像全局 npm 包这种影响范围巨大的操作。即便系统推测某些包可能是残留，也应先弹出询问。他建议，对于 npm uninstall、rm 这类危险指令，必须增加确认机制，甚至可考虑提供 dry-run 模式，让用户预先审查将要发生的操作。
此外，还有用户反馈疑似存在内存泄露：“使用 pnpm 安装打开后从未输入任何内容，回来发现内存占用过高。”
更有用户遭遇了 MiMo Code 陷入“思考死循环”的尴尬：
除此之外，各种小毛病层出不穷。例如有用户报告 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 本身并无太多神秘之处，更多是用户体验层的包装。另一派则指出，不同 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 的工程重点分化
从技术路线来看，Claude Code 和 MiMo Code 都属于“模型 + 运行时 + 工具调用循环”的终端编程 Agent。模型负责推理与决策，运行时则负责管理工具、组装上下文、执行命令、持久化状态，并将工具结果反馈给模型以进入下一轮循环。
但二者的工程侧重点已显现出明显分化。
VILA 实验室通过对 Claude Code 进行全面的源码级架构分析（覆盖 Claude Code v2.1.88 版本，约 1900 个 TypeScript 文件、约 51.2 万行代码），并结合社区分析与跨系统对比研究，得出结论：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 更少，格式错误率也更低。
编排：从自然语言流程到代码化 Workflow
两者的差异在任务编排上体现得尤为明显。
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() 原语、日志恢复及沙箱内文件读写等能力。
记忆机制：从上下文压缩到 Rebuild
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 文档。
参考链接：
声明：本文为 InfoQ 原创，不代表平台观点，未经许可禁止转载。
发表于 昨天 22:37
|
查看: 3|
回复: 0
