MiMo Code 的多 Agent 协作模式，并非简单地将多个 AI 模型堆叠在一起凑数。其底层逻辑可以凝练为一句话：明确分工，各司其职。主 Agent 负责“调度与管理”，子 Agent 才是实际执行任务的“一线员工”。而且每个子 Agent 的能力边界被刻意严格限定，彼此之间无法越权操作。
主 Agent：只做两件事——拆解与整合
主 Agent 不编写任何代码，不检索任何资料，甚至连测试都不亲自执行。它的全部职责集中在以下两项：
- 精准拆解：将用户一句笼统的需求（例如“重构用户登录模块并补充单元测试”），分解为逻辑互斥、边界清晰的子任务。举例来说，它会拆解出“分析当前登录流程依赖关系”“识别潜在安全风险”“生成覆盖边界场景的测试用例”“重写 AuthService 类”“验证接口兼容性”等步骤，每一步由谁负责、做到什么程度，都一目了然。
- 统一整合：等待所有子 Agent 返回结果后，它执行三项操作——去重（避免多个子 Agent 重复报告同一个问题，比如“密码未加密”被多次提交）、补缺（发现测试覆盖率报告缺少异常流用例，则触发 TestAgent 补充一份）、串联（将零散的技术细节转化为开发者可直接阅读的 PR 描述或文档草稿）。
简而言之，主 Agent 就像一个不碰键盘的项目经理，清楚每一步该由谁执行、执行得是否正确、最终能否顺利交付。
子 Agent：一人一岗，工具与提示词深度绑定
每个子 Agent 在创建时就被赋予三项固定配置，且无法越界操作：
- 专属系统提示词：例如 SecurityAgent 的提示词中始终包含 OWASP Top 10 清单、常见密钥特征正则表达式，以及一条硬性约束——禁止建议修改业务逻辑。
- 限定工具集：StyleAgent 只能调用代码格式化工具和 AST 解析器，无法访问网络，也无法执行 shell 命令。
- 隔离上下文窗口：每个子 Agent 的输入仅包含主 Agent 下发的子任务指令和当前代码片段，看不到其他子 Agent 的中间过程。这一点至关重要——避免了信息污染：它不会因为刚看过测试报告，就在代码审查时突然讨论起覆盖率数字。
这种设计带来的直接好处，是子 Agent 的输出更加稳定、更可预测。
三种主 Agent 模式决定分工粒度
MiMo Code 预设了三种模式，针对不同复杂度的任务调度方式做了区分：
- plan 模式：只读分析型任务。主 Agent 拆解后，派遣子 Agent 查询依赖图、绘制时序图、比对 API 变更，但不生成任何代码。
- build 模式：轻量执行型任务。主 Agent 下发“修改这 3 个文件”的指令，子 Agent 直接编辑并保存，全程无需人工确认。
- compose 模式：全流程编排型任务。主 Agent 同时启动 plan 子 Agent 进行方案设计、build 子 Agent 编写代码、test 子 Agent 运行验证、doc 子 Agent 更新注释，最后自己整合交付成果。
切换模式只需按 Tab 键，无需重写任何配置。
子 Agent 的生命周期由主 Agent 全权管控
子 Agent 并非独立个体，而是主 Agent 的延伸执行单元：
- 它不能主动发起新的子 Agent，也不能跨任务与其他子 Agent 私下通信。
- 主 Agent 可以随时取消未完成的子 Agent——例如 PerformanceAgent 卡在某段死循环分析中，直接中断并重新启动。
- 所有子 Agent 的输出必须压缩为结构化 JSON，包含 status、output、suggestion 三个字段。这样主 Agent 才能自动解析并进入下一步流程。
这种强管控换来的是可追溯、可复现、可调试。哪块结果不对，直接重跑对应子 Agent，不会影响整体流程。