MiMo Code 的多 Agent 编排，其核心逻辑非常直观——它并非依赖预设的固定流水线来推进任务，而是由主 Agent 根据当前任务需求动态生成协作方案。简单来说，就是将“人工调度 AI”转变为“AI自主组队协同”。要深入理解其价值，必须首先掌握三种核心工作模式、子 Agent 的协同机制，以及并行启动的必备条件。单纯增加 Agent 数量效果有限，关键在于实现精准分工。
接下来，我们从最基础的部分谈起——模式选择。
用对模式：build / plan / compose 三档分工
通过按 Tab 键即可切换模式，每种模式对应不同的控制层级，选对模式可大幅提升效率。
- build 模式：此为默认的全权限模式，主 Agent 可读写文件、执行 Shell 命令、调试并运行程序。适用于需要实际落地的开发任务，例如模块重构、新增功能——总之，凡是需要动手执行的工作场景均可使用。
- plan 模式：该模式仅允许分析操作，不可修改代码。适用于技术方案评审、安全扫描、依赖影响评估等“先探查再决策”的任务。其输出结果可直接作为后续 build 阶段的输入，衔接流畅且高效。
- compose 模式：这是一种端到端的交付模式，涵盖从规范解析、目录初始化、前后端代码生成，到依赖安装、本地运行验证的完整流程。甚至可以通过语音指令“帮我搭个记账应用”自动触发该路径的执行。
子 Agent 并行不是自动发生的，要满足三个条件
即便开启了 compose 或 build 模式，MiMo Code 也不会贸然派遣大量子 Agent。它采用一套严谨的判断逻辑，专门避免操作冲突与上下文漂移。那么，究竟在何种情况下才能实现并行？简而言之，三个条件缺一不可：
- 任务之间无依赖关系：例如，“编写测试”和“修改业务逻辑”可以同时启动，但“生成接口定义”必须在“编写路由实现”之前完成。这一点很好理解，串行依赖任务无法并行。
- 操作对象互不重叠：两个子 Agent 不能同时对同一份 config.json 进行修改，否则会相互覆盖导致混乱。但只要一个 Agent 处理 src/api/ 目录，另一个处理 src/utils/ 目录，则完全没有问题。
- 上下文隔离且完整：每个子 Agent 在启动时会继承当前项目结构、已识别的框架版本以及用户最新的指令片段——并非依赖模糊记忆推进，而是获取一整套完整的环境快照。
这三项条件确保了并行操作不会演变为混乱冲突，每个 Agent 都清晰知晓自身的边界与输入。
Dynamic Workflow：用 JS 脚本接管复杂编排
当任务涉及数十个文件，或者需要多轮对抗验证（例如全仓库安全审计）时，单纯依靠 prompt 已难以胜任。此时，MiMo Code 的 Dynamic Workflow 功能便能发挥作用——主 Agent 会自行生成一段 JS 编排脚本，在沙箱中确定性执行。其运作方式类似于导演调度演员：
- 通过 agent() 派遣子 Agent，并为每个子 Agent 分配明确角色（如 reviewer / tester / migrator）；
- 利用 barrier() 设置同步点，确保所有子任务完成后才进入下一步流程；
- 循环不会提前终止，barrier 不会遗漏任何子 Agent。模型只需专注于代码理解与生成，流程控制完全交由脚本处理。
这种方式显著提升了复杂编排的可控性。
实战建议：从语音指令开始，逐步升级编排粒度
新手不必一开始就编写 JS 脚本，建议分三步逐步建立操作手感：
- 首先，通过语音触发 compose 模式，观察它如何自动拆解“搭记账应用”这一需求——包括初始化、前端组件生成、图表逻辑、后端接口、依赖安装、本地启动，一气呵成；
- 遇到大模块重构时，手动切换到 build 模式，下达“重构 user 模块，包含单元测试+类型校验+PR 描述生成”的指令，观察系统如何派遣三个子 Agent 并行工作；
- 当面临真正的跨百文件迁移或竞态复现场景时，再启用 Dynamic Workflow，让主 Agent 输出编排脚本，你只需确认关键节点（如 barrier 位置、失败重试策略）即可。
归根结底，它并非追求“Agent 越多速度越快”，而是通过精准判断与可控编排，将长程任务的耗时压缩至最慢子任务的级别。真正的效率提升来源于减少等待，而非单纯增加并发数量。