mimo code 的多 agent 架构通过 planner、coder、runner、verifier、writer 五类分工明确的子 agent 协同完成复杂开发任务，以 goal 驱动和 cycle 记忆同步实现可追溯、可验证、可重放的长程开发流程。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的多 Agent 架构不是把一个大模型拆成多个小模型，而是让不同角色的智能体各司其职、协同推进任务。它解决的核心问题是：单个 Agent 在长程、多文件、跨工具的开发任务中容易“跑偏”或“断片”，而分工明确的子 Agent 能把复杂工作稳住节奏、守住边界。
任务自动拆解：从一句话指令到可执行动作树
用户输入一句自然语言指令（比如“用 Vue3 和 Express 搭建记账应用，支持图表可视化和本地 JSON 存储”），MiMo Code 不是直接生成代码，而是先启动 Planner 子 Agent 做结构化拆解：
- 识别技术栈边界：前端（Vue3 + Element Plus + ECharts）、后端（Node.js + Express）、数据层（JSON 文件读写）
- 划分阶段目标：初始化目录 → 创建前后端骨架 → 实现核心功能模块 → 集成测试 → 启动验证
- 生成带依赖关系的动作树（DAG），每个节点标注所需工具（如 npm init、mkdir、curl、git add）和校验条件（如 package.json 是否存在、server.js 是否可运行）
这个过程不依赖人工提示工程，而是由 Planner 内置的领域知识图谱驱动，确保每一步都落在真实开发路径上。
角色分工明确：五个关键子 Agent 各管一段
MiMo Code 默认启用五类子 Agent，它们共享同一会话上下文，但权限与职责严格隔离：
- Planner：只负责任务分解与路径规划，不碰代码也不执行命令
- Coder：专注写/改代码，只能访问当前文件和已声明的 API 接口，不能擅自删库或改 config
- Runner：只执行 Shell 命令、启动服务、运行测试，无权修改源码
- Verifier：独立验收结果，调用 Jest、Cypress 或自定义脚本验证 Goal 是否达成，不参与实现过程
- Writer：专管记忆，定时 checkpoint、提取结构化字段（意图/错误/设计决策等），主 Agent 对其输出只有读权限
这种分工避免了“既当裁判又当运动员”的逻辑冲突，也防止某个环节出错污染全局状态。
动态协同机制：Goal 驱动 + Cycle 记忆同步
多 Agent 协作不是靠轮询或硬编码调度，而是靠两个底层机制咬合运转：
- Goal 独立验证：用户设定自然语言停止条件（如“能显示近7天收支折线图”），主流程走到某步时主动暂停，交由 Verifier 检查实际输出是否满足——不满足就回退重试，不靠主 Agent 自我判断
- Cycle 记忆同步：当对话窗口使用率达 20%、45%、70% 时，Writer 自动触发 checkpoint，把当前任务树、已执行动作、报错日志等 11 类结构化信息落盘；窗口将满前，系统用这些快照重建轻量上下文，保持长程任务状态连贯
这意味着一个持续 300 步的开发任务，不会因为中间插入一次调试就丢失初始需求，也不会因模型注意力衰减而遗忘关键约束。
实战建议：怎么用好这套架构
对开发者来说，多 Agent 的价值不在炫技，而在降低失控风险：
- 首次使用建议开启 Max Mode（并行 5 路采样选优），尤其在写核心逻辑或重构关键模块时，能明显减少返工
- 遇到任务卡住，别急着重试，先看 notes.md 和 checkpoint 日志，Writer 已帮你记录下所有失败点和设计取舍
- 想接入自有 CI/CD 或 Git 流程？只需为 Runner 和 Verifier 注册新 tool function，无需改动 Planner 或 Coder 的逻辑
- 团队协作时，可导出完整的 cycle 日志包（含动作树+变更 diff+验证截图），作为自动化 PR 描述的原始依据
它不追求一步到位，而是让每一步都可追溯、可验证、可重放。
