导读：2026 年 6 月，小米开源 MiMo Code 引发了对编程 Agent 架构的激烈讨论。一篇来自 VILA 实验室的源码级分析揭示了一个事实：Claude Code 51.2 万行代码中，只有 1.6% 属于 AI 决策逻辑。两个工具在记忆体系、任务编排、长期进化三个维度上走向了截然相反的方向------不是因为谁的技术更强，而是因为它们根本不在解决同一个问题。本文基于一手技术资料，拆解这场"路线分化"背后的架构逻辑。
2026 年 6 月 11 日，小米 MiMo 团队开源了终端编程 Agent 产品 MiMo Code。5 个人，14 天，MIT 协议。罗福莉在 X 上管这叫"一场 vibe coding 之旅"。
不到 48 小时，GitHub 上涌进超过 5000 个 Star。也是不到 48 小时，超过 200 个 Issues 拍在脸上------Agent 未经确认删掉了用户全局 npm 包（看到这个 issue 的时候我真的愣了一下）、内存泄露、思考陷入螺旋重复。这种开局方式本身就是一个信号：写代码的 Agent，正在从"工具"变成"工地"。
但吸引我的不是 Star 数和 bug 数（好吧，bug 数也吸引了我一会儿）。是一组更安静的数字。
VILA 实验室对 Claude Code v2.1.88 做了一次源码级的解剖（原论文 arxiv 2604.14228，InfoQ 做了详细转述）。结果很有意思：大约 1900 个 TypeScript 文件、51.2 万行代码中，只有 1.6% 属于 AI 决策逻辑。剩下 98.4% 都是确定性基础设施------权限管理、上下文管理、工具路由、恢复逻辑。Agent 循环本身呢？只是一个简单的 while 循环。
同一时间，小米的官方技术博客发了一篇长文，讲 MiMo Code 的核心设计。架构主线有且只有三条：计算、记忆、进化。每条主线都在解决一个明确的问题：单轮决策不可靠怎么办、多轮状态丢失怎么办、跨任务经验浪费怎么办。
两篇文章放在一起看，你会发现一个挺反直觉的事实：这两个东西，根本不是在同一条赛道上优化同一个问题。
它们到底在解决什么
先从 Claude Code 那边说起。
Anthropic 这家公司的基因是安全。Constitutional AI、Responsible Scaling Policy、RLHF 的安全对齐------这些是写在组织 DNA 里的东西，不是产品发布会上的 PPT 词汇。
所以 Claude Code 的问题定义非常具体：怎么让 AI 在人类可控的框架里可靠工作？ 这个问题天然指向一个结论------Agent 循环本身不值得投入太多智能，真正需要工程资源的是防护层。你放手让模型写代码的前提，是你在绝大多数时候能拦住它做不该做的事、恢复它搞砸的东西。
这就是为什么 Claude Code 的代码仓看起来像一座堡垒。7 层安全机制（已知包括 hooks、分类器、压缩、隔离等），每一层都在回答同一个问题："如果模型出错了，谁来兜底？" 答案从来不是"模型自己能兜住"（至少 Anthropic 是这么相信的）------而是人。
再看看 MiMo Code。
小米团队在技术博客里写了一段话，我觉得是理解整个架构的钥匙：
对于短任务（10 轮以内），这个结构工作良好：将完整对话历史传给模型即可，历史本身就是足够好的工作记忆。但随着任务轮次增加......上下文窗口终会耗尽。
MiMo Code 出问题的场景不是"模型会不会做危险操作"，而是"任务跑到第 200 步时，Agent 是不是还在做第 1 步定下的目标"。
Claude Code 的设计假设天然避开了这个问题域。你把一个长任务拆成几次短会话，每次人类确认一下进度，就自然绕过了长程记忆衰减。所以 Claude Code 不需要四层记忆------它需要的是一套让人类舒服地插手的机制。
但 MiMo Code 的野心更大：如果人类不插手呢？如果 Agent 自己跑 200 步、一天、一周呢？
两种哲学，两条路。
记忆：压缩 vs 重建
怎么让 AI 持续记得自己做过什么、接下来该做什么？
Claude Code 的答案是压缩。给模型一个有限的上下文窗口，然后在窗口快满的时候做摘要。具体手段包括 CLAUDE.md（项目级规则，手写维护）、auto memory（对话中自动沉淀的笔记）、JSONL 格式的 session transcript（完整会话日志）、以及子 Agent 的 sidechain（子任务的摘要喂给父 Agent，不污染主上下文）。
这套体系的设计原则是"可审计"。你可以打开 CLAUDE.md 看它记住了什么项目规则，翻 JSONL 日志复现整个会话。一切在文件系统里，一切可回溯。代价是什么？压缩就是丢失。不管用哪种压缩方式，被丢弃的细节不会自己回来。
MiMo Code 走了完全不同的路。
它把这个问题拆成两个角色：主 Agent 负责干活，writer subagent 负责记笔记。主 Agent 不维护自己的记忆------因为"要求一个正在调棘手 bug 的模型同时维护结构化日志，往往会在两件事上各做差一件"。writer 是一个独立 Agent，不与主 Agent 共享注意力或 token 预算。每次 checkpoint 触发时，writer 读取完整的对话历史，把状态写入一个固定结构的文件------11 个字段：当前意图、下一步动作、任务树、涉及文件、跨任务发现、错误与修复、设计决策......然后主 Agent 继续工作，完全不知道这件事发生过。
这个 checkpoint 不是在窗口快满的时候才触发的。小米团队发现反直觉的一点：越接近窗口上限，模型的提取能力越差。 论文里叫"lost in the middle"------随着输入变长，模型对中段内容的注意力衰减，压缩的质量也随之下降。所以 MiMo Code 在已经配置预算的 20%、45%、70% 处各触发一次 checkpoint，每次都是增量更新。没有一次是孤注一掷的压缩。
当窗口接近真正的上限，运行时执行一次 rebuild。切断当前窗口，开启新窗口，把之前持久化的文件按固定顺序注入：任务清单 → session checkpoint → 最近用户消息的逐字切片（防止 writer 改写偏离原意）→ 项目记忆 → 全局记忆 → tail reminder。总共控制在约 65K token 以内。Agent 在新窗口醒来，看到摆好的状态，继续干活。从模型视角看，对话从未中断。
这就是 Cycle。每一段以 checkpoint 打点、以 rebuild 收尾的 turn 序列就是一个 cycle。逻辑会话是 cycle 的链------那条链没有长度限制。
在记忆的持久化层面，MiMo Code 还搞了四层体系：Session 记忆（当前会话内）、Project 记忆（项目级，存储架构决定和验证过的技术事实）、Global 记忆（跨项目的用户偏好）、History（每个会话的完整 SQLite 轨迹，不做索引，做兜底查询）。四层之间，writer 负责把信息从下层往上层提炼------越来越精炼、越来越持久、越来越小。
为什么 Claude Code 不做这套东西？
不是因为做不到。在工程上，给 Claude Code 加一套 Cycle/Rebuild 机制完全可行。问题在于 Anthropic 认为这不应该是"系统"的职责。记忆越多，审计越难。当一个 Agent 自动把跨 session 的经验提炼成项目记忆时，作为人类你很难回答一个基本问题：它为什么相信这个？这个知识的来源是哪次对话？如果它记错了，哪个行为受到了影响？
Claude Code 的选择是：只有人类写入的记忆才进入项目级系统。CLAUDE.md 是手写的，auto memory 是可以审查的，JSONL 是只读存证的。系统不帮你提炼，不帮你归纳，不帮你做跨 session 的推断------那些是人的事。
这是一道分水岭 不是技术上的，是哲学上的：记忆应该被管理，还是被提炼？
决策：信任模型 vs 用代码保证
两个工具在任务编排上的分歧，是对上一个问题的延续。
Claude Code 的编排模式是模型在循环中动态决策。每一轮，模型看到当前上下文，决定下一步调用什么工具。工具结果返回，模型再做下一轮决策。可以通过 AgentTool 委派子 Agent，可以通过 MCP、skills、hooks 扩展能力，但核心循环没有变过。
这套模式对人类友好的地方在于：每一步都是透明的，每一步都可以介入。 hooks 机制允许你在模型执行特定操作前插入一个审批节点，分类器可以在模型产生输出后做合规检查，压缩机制保证上下文不会无限膨胀。整个系统的工程复杂度都在防护层，决策本身保持简单------你可以看到一个清晰的决策链，知道模型在每一步为什么做了这个选择。
问题在哪？在长任务里，这个模式会撑不住------不是因为模型不够聪明，而是因为自然语言不是可靠的流程控制语言。
小米团队在技术博客里说了一段很实在的话：
把流程写进 SKILL.md，用自然语言告诉模型"先做 A，再做 B，如果 C 就做 D"。这在简单场景下能用，但在复杂流程中会系统性失效：上下文压缩可能吞掉步骤、模型可能跳过某些环节、分支和重试逻辑靠模型判断而非代码保证、同一流程两次执行路径不同。
MiMo Code 的回应是 Dynamic Workflow------把编排逻辑从 prompt 迁移到代码。
主 Agent 不再用自然语言描述"你先做这个再做那个"。它生成一段 JavaScript 脚本，在隔离沙箱中确定性执行。脚本通过 agent() 派出子 Agent，通过 parallel() 和 pipeline() 控制并发。这里的关键差别是：if 语句不会在上下文被压缩时消失，for 循环不会跑到一半就停了，barrier 不会漏掉子 Agent。模型的判断力只用在该用的地方------理解代码、生成代码------而不是浪费在流程控制这种应该用确定性逻辑保证的事情上。
这套实现兼容 Anthropic 官方的 Dynamic Workflow 核心语义，但做了几项扩展：workflow() 原语让脚本可以调用脚本（编排逻辑变成可复用的积木）、子 Agent 的结果同步落盘（进程中断后从日志恢复）、沙箱内可以直接读写文件。
除了流程控制，MiMo Code 还在两个时间尺度上做了决策增强。
同一步内：Max Mode。 每一轮并行生成 5 个候选方案，temperature 设到 1，所以 5 次采样几乎不会重复。每个候选独立完成推理和工具调用规划但不实际执行，然后同一个模型作为 judge 选出最优的一个。这本质上是"与其赌一次对，不如比完再选"------在 SWE-Bench Pro 上提升 10-20%，代价是约 4-5 倍的 token 消耗。目前还是实验性功能，需要手动开启。
同一个任务内：Goal 机制。 长任务中 Agent 有个让人头疼的习惯：看到已有的进展就倾向于提前宣称"完成了"。这在无人值守运行时特别要命。Goal 的做法是，用户用自然语言设定一个停止条件（比如"所有测试通过且代码已提交"），每次 Agent 尝试终止时，系统发起一次独立的模型调用来审查完整对话历史，判断条件是否真的满足了。如果没满足，把具体差距反馈给 Agent 让它继续。这个验证者不参与实际工作，所以不会对 Agent 已完成的部分产生认同偏差。小米团队说整体死循环概率不到 0.5%。
留心一下 Claude Code 和 MiMo Code 在"停止判断"上的差异：Claude Code 是主 Agent 自己决定什么时候停止（加上系统级的 max turns、context overflow 等硬约束），MiMo Code 是把"做事的"和"验收的"拆成了两个 Agent。
更深层的选择 你信任一个经过安全约束的模型自己判断"我做好了"，还是信任两套独立的判断系统交叉验证？
前者的风险是模型过早乐观退出的"假完成"，后者的风险是验证者误拦------小米也承认，条件已满足但验证者认为没满足的情况比漏放更常见。
进化：人驱动的 vs 系统自主的
如果只在一个 session 里工作，上面的差异已经够大了。但真正的分水岭出现在跨 session 的维度上。
Claude Code 的经验积累方式是"人在闭环中"。CLAUDE.md 需要你手动维护------加了新依赖要更新构建命令、发现了一个坑要写成规则、确定了编码风格要记下来。这个过程慢，但每一条进去的内容都是人确认过的。
MiMo Code 不一样。它有两套自动机制。
Dream：每 7 天自动触发。 一个独立 Agent 读取过去一周的 session 对话和现有的项目记忆文件，做合并、去重、验证文件路径是否仍然有效、压缩冗余。把分散在多轮对话里的发现收敛成一份紧凑的当前状态，同时更新全局记忆。
Distill：每 30 天自动触发。 同样由独立 Agent 读取历史 session，但关注的是流程而不是知识------识别你反复做的工作模式，然后固化成可复用的 skill、CLI 命令、自定义 Agent 或 SOP 文档。
这个设计背后有一个很直白但很少有人公开讲的判断：模型生成的记忆文件会变脏。 过时的条目、重复的记录、失效的文件引用会随时间累积。如果不维护，信噪比会下降。而维护这件事------合并、去重、验证------模型可以自己做，不需要人每次手动清理。
MiMo Code 选择把记忆文件用 Markdown 格式而不是向量数据库存储。这个选择有意思------不是不知道向量检索更快，而是 "可审查性"优先级高于"检索效率"。当一个记忆会影响 Agent 的后续行为时，你需要能打开文件看到它记住了什么、删除记错的、修改过时的。文件可以被标准读写工具直接操作，不需要为每种维护操作开发专用接口。
回到那个问题：为什么 Claude Code 不做 Dream/Distill？
答案跟前面一样。Anthropic 的立场是：跨 session 的经验提炼应该是人的责任。自动归纳可能引入错误记忆，错误记忆在一个安全敏感的系统中是不可接受的。所以 Claude Code 的选择是"不做"------不是没能力做，而是选择不做。
小米的立场则是：与其让记忆腐烂，不如让系统维护。维护过程可能犯错，但可以审查、回退、修正。不维护则一定会腐烂。这是一个工程权衡，不是对错问题。
不是谁更好，是路线问题
回到开头那个判断：这两个工具不是在优化同一个问题。
Claude Code 是在做一个 AI 编程的"操作系统层"------稳定、安全、可审计，人类始终在决策链中。98.4% 的代码是确定性基础设施不是缺点，是产品定位的必然结果。它不需要四层记忆，因为它的使用模型假设人类会适时介入；它不需要自动进化，因为它的设计哲学认为跨 session 的经验提炼是人的职责。
MiMo Code 是在做一个"应用层实验场"------它可以激进试错。Max Mode 是实验性功能，Dream/Distill 是自动运行的，Cycle/Rebuild 机制在传统企业级产品中很难找到对标。它不在乎超过 200 个 Issues 涌进来，因为问题的涌现本身就是开源的预期代价。5 个人 14 天做出来的东西，不怕被看见不完美。
VILA 实验室对 Claude Code 的评价是："每一项设计选择都可追溯到人的决策权、安全性、可靠性、能力放大和适应性。" 这听起来像是在夸------确实是在夸------但换个角度想，这不是一个 Agent 该有的全部品质清单。如果一个 Agent 只在人类可控的前提下才可靠，那它到底是一个 Agent，还是一把更聪明的锤子？
MiMo Code 则在推另一个方向的边界：如果人类不插手，Agent 能不能自己持续工作？能不能自己记住、自己检查、自己改进？这条路天然带着更多风险------小米的开源 Issues 列表就是证据。但某种意义上，它在回答一个 Claude Code 选择绕开的问题：当任务尺度超出人类愿意等待的范围时，Agent 应该具备什么品质？
小米内部做了一次真人在环的双盲 AB 测试，576 名开发者在自己的真实项目里分别用 MiMo Code 和 Claude Code 完成同一个任务，独立打分。总共 1213 个有明确胜负判定的配对。结果是：200 步内，两者胜率接近 50%。200 步以上，MiMo Code 的胜率升到 65% 以上。
这个数据本身不等于"MiMo Code 更好"------Agent 评测体系还没有公认的标准，benchmark 主要衡量的是单仓库问题一次性解决能力，不是持续几十轮的真实开发体验。但这组数据至少说明一件事：当任务尺度拉长，架构的选择开始显现效果。 Cycle/Rebuild 不是营销概念，Goal verifier 不是花活，它们在长任务中实际产生了差异。
两个工具的最后一段路可能不是谁打败谁，而是场景分化。Claude Code 的擅长区间是短到中程的、需要人类紧密协作的任务------它的安全架构在这种场景里有压倒性优势。MiMo Code 的擅长区间是长程的、可以放手的任务------它的记忆和进化架构在这种场景里有不可替代的价值。
值得关注的信号 Dynamic Workflow 的意义不在于它比谁快多少，而在于它把一个问题摆到了台面上：很多我们现在用自然语言 prompt 定义的 skill 和流程，未来可能会变成代码形式的 workflow 脚本。 当流程的每一步都必须执行、分支条件必须精确、重试逻辑必须可靠的时候，代码比自然语言靠谱。
这个趋势如果成立，影响的就不只是这两个工具了。