首先给出几个核心判断：MiMo Code 的子 Agent 并非传统意义上的功能插件，而是一支能够动态组建、各司其职的智能开发团队。它将“让 AI 干活”升级为“让 AI 分工协作”——核心在于角色明确、权限隔离、上下文共享但职责不重叠。这套模式中，设有三位基础角色：build（开发）、plan（分析）、compose（编排）。它们各自守护着自己的领域，权限相互隔离，上下文可以共享，但绝不会越俎代庖。
默认情况下，主 Agent 处于 build 模式，拥有完整开发权限——读写文件、执行命令、提交 Git 都不在话下。但如果你需要它换个视角，只需按一下 Tab 键，它就会自动切换到 plan 模式，瞬间降权为只读分析者，专注于代码审查、架构推演与方案设计，一行代码也不会动手。而当需要统筹全局时，compose 模式便会登场——它是编排中枢，负责从需求规格（spec）出发，拆解任务树、分配子 Agent、协调执行节奏，最后将结果汇合。模式切换无需重启，无需重新加载上下文，工具调用白名单也会自动跟着变化：plan 模式下，write_file 和 run_command 这类“动手”工具会被自动禁用。最关键的是，compose 模式会主动触发 spec-manager 流程，强制先输出 L1PRD/L2Design 再进入实现——这才是开发流程的秩序所在。
三种基础角色：build、plan、compose 各守其位
- Tab 键即可实时切换模式，无需重启或重新加载上下文
- 不同模式下，Agent 对工具的调用白名单自动变化——plan 模式禁用 write_file 和 run_command
- compose 模式会主动触发 spec-manager 流程，强制先输出 L1PRD/L2Design 再进入实现
子 Agent 动态生成：按需派工，互不干扰
当主 Agent 判断任务复杂度超出单点处理能力时，它会自主生成子 Agent。每个子 Agent 继承当前会话的完整上下文快照，但运行在独立沙箱中——彼此之间不共享内存，不直接通信。所有协同都通过主 Agent 中转或共享磁盘记忆文件完成。举个例子：重构一个服务模块时，主 Agent 可以同时派出三个子 Agent——一个跑单元测试生成覆盖率报告，一个执行 AST 级代码改写，一个做静态扫描查安全漏洞。子 Agent 支持后台异步执行，可随时取消，状态通过 /status 命令实时查看。每个子 Agent 的生命周期严格绑定任务，完成后自动销毁，不留残留上下文。这种设计就像一支特种小队，任务结束后，装备归位，不留痕迹。
- 例如重构一个服务模块：主 Agent 派出三个子 Agent——一个跑单元测试生成覆盖率报告，一个执行 AST 级代码改写，一个做静态扫描查安全漏洞
- 子 Agent 支持后台异步执行，可随时 cancel，状态通过 /status 命令实时查看
- 每个子 Agent 的生命周期严格绑定任务，完成后自动销毁，不留残留上下文
Writer 子 Agent：专责记忆，不参与执行
Writer 是唯一被赋予持久化写入权限的子 Agent，但它从不参与代码生成或逻辑判断。它的唯一职责是在 Cycle 机制触发的三个关键窗口点（20%、45%、70%）提取结构化信息，写入 11 个固定字段的记忆文件。字段包括：意图、动作、任务树、错误日志、设计决策、依赖变更等——全部可被机器解析。主 Agent 对这些文件只有读权限，只能读取用于上下文重建，不能修改。只有 notes.md 是个例外——它是唯一允许主 Agent 直接编辑的会话级便签，用于临时记录非结构化想法。这种机制，就像团队里有一个专职的秘书，负责记录会议纪要，但绝不参与决策。
- 字段包括：意图、动作、任务树、错误日志、设计决策、依赖变更等，全部机器可解析
- 主 Agent 对这些文件只有读权限，只能读取用于上下文重建，不能修改
- notes.md 是唯一允许主 Agent 直接编辑的会话级便签，用于临时记录非结构化想法
语音 + spec-manager：让团队协作有人类语言接口
语音输入不是锦上添花的功能，而是降低协作门槛的关键入口。一句“帮我加个登录失败三次锁定功能”，系统会自动启动 compose 模式，并联动 spec-manager 创建 L1PRD；后续所有子 Agent 的工作，都围绕该规格展开——每一步决策和产出都可追溯。语音指令会被自动转录、结构化，并作为 L1PRD 的原始需求存档。spec-manager 生成的规格文档，成为子 Agent 间事实一致性的锚点。最终交付物不仅包含代码 diff，还附带完整的 spec chain 和验证证据链——这才是真正意义上的“人类语言驱动开发”。
- 语音指令会被自动转录、结构化，并作为 L1PRD 的原始需求存档
- spec-manager 生成的规格文档，成为子 Agent 间事实一致性的锚点
- 最终交付物不仅包含代码 diff，还附带完整的 spec chain 和验证证据链