先讲一个核心观点：MiMo Code 的任务编排，绝非僵化的流水线作业。其真正的价值在于——它将 Planner-Executor、Manager-Worker、Blackboard、Debate 等协作机制，设计成可插拔的组件形态，让开发者能根据任务类型、团队工作方式或项目阶段，灵活组合、动态适配，而不是强制全程绑定某一种固定模式。

那么，实际操作中如何选择？很简单：依据任务复杂度来决定。

按照任务复杂度挑选协作模式

如果只是修复一个 Bug 或新增一个 API 接口，轻量级的 Pipeline 或 Router 模式即可胜任——快速路由到代码编辑 Agent，跳过冗余的规划流程，效率最高。对于中等复杂度的场景，比如重构一个模块，推荐使用 Planner-Executor：先产出包含测试用例的详细方案，再落地执行。至于跨文件、多角色评审的工业级交付，则必须上 Compose 模式，配合 Debate/Critic 子流程，让设计、编码、测试、审查四个子 Agent 依次介入、相互校验。

• 单文件修改 → Router + Worker 直接执行
• 新增功能模块 → Planner-Executor 先输出 PR 描述 + 单元测试骨架 + 实现代码
• 遗留系统迁移 → Manager-Worker 并行拆分子系统，Blackboard 同步状态，Monitor 实时评估兼容性风险

角色与权限支持运行时动态调整

静态分配的方式早已过时。MiMo Code 支持基于能力向量的动态角色切换。举例来说：某个 Worker Agent 正在编写代码，突然发现上下文里出现大量测试失败日志——它会自动触发「临时兼任 Evaluator」的逻辑，调用内置的断言分析工具进行根因定位，完全无需人工干预。而 Manager Agent 在发现某个子任务超时达到两倍阈值时，能即时启动 Auction 模式，将任务拍卖给空闲的 Worker，全程无需人工介入。

• 角色变更由 Monitor Agent 触发，依据 CPU/内存占用率、响应延迟、错误率三类实时指标
• 权限粒度细化到文件路径、Git 分支、CI 阶段（例如只允许在 feature/* 分支上执行 git commit）
• 所有变更均留痕，通过 /history 可查看角色调度日志

自定义编排可通过 YAML 或交互式 Tab 切换实现

若想自定义策略，有两种低门槛方式。一种是使用简洁的 YAML 定义任务拓扑，指定各节点 Agent 类型、输入输出契约以及失败重试策略。另一种更直观：在终端按 Tab 键进入 Compose 模式，用自然语言描述意图，比如“先看 README 和 src/main.py，再写个 CLI 命令支持 --dry-run”。系统会自动匹配最合适的协作链路，并允许你在中途插入人工确认点，或替换某个子 Agent。

• YAML 支持 condition 字段，例如 only_if: “git diff --name-only | grep ‘test/’” 让测试 Agent 仅在测试文件发生变更时激活
• Tab 进入 Compose 后，每轮生成都会显示当前采用的协作模式，如 “Planner → Worker → Critic → Worker（修正）”
• 所有自定义策略保存为 .mimo/compose.yaml，可版本化管理，并复用至 CI 流水线

这种高度灵活性并非功能堆砌的结果。恰恰相反，它将多 Agent 协作的抽象机制真正下沉为开发者在日常操作中可选的能力。任务越不确定，你越需要可解释、可干预、可回退的编排控制权——这才是其中的关键所在。