mimo code 的多 agent 系统以任务拆解为设计起点，按理解、规划、实现、验证四阶段划分 understander、planner、coder、checker 四类 agent，通过指令-响应-断言协议、版本化工作区快照和结构化人机协同保障可控性与可验证性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的多 Agent 系统不是把一堆模型硬凑在一起，而是让每个 Agent 有明确边界、可验证职责和清晰输入输出，任务拆解是设计起点，不是后续优化环节。
按开发闭环切分核心 Agent 角色
一个完整编码任务天然包含理解、规划、实现、验证四个阶段，对应四个基础 Agent：
- Understander：接收自然语言需求 + 上下文（如已有代码、文档片段），输出结构化任务描述（含目标、约束、关键接口）、识别出的依赖项和潜在风险点；不生成代码，只做语义对齐。
- Planner：基于 Understander 输出，生成可执行的步骤序列（例如“1. 修改 service 层 UserValidator 类；2. 新增 email 格式校验逻辑；3. 更新对应单元测试”），标注每步所需工具（如 grep、git blame）和预期副作用范围。
- Coder：严格按 Planner 步骤执行，每次只改一个最小单元（如单个函数或配置项），生成带上下文锚点的 diff 片段，并附带修改理由（引用 Planner 中对应条目）。
- Checker：不跑完整测试，而是做轻量级一致性校验——检查 Coder 输出是否满足 Planner 的步骤约束、是否引入未声明的依赖、是否破坏 Understander 提出的关键接口契约。
用“指令-响应-断言”三元组定义 Agent 交互协议
避免自由对话式协作，每个 Agent 间通信必须可审计、可回溯：
- 指令（Instruction）：由上游 Agent 发出，格式固定（如 JSON Schema），含 version、task_id、input_ref（指向前序输出哈希）、action_type（如 “validate_interface”）；
- 响应（Response）：下游 Agent 返回结构化结果，必须包含 status（success/fail/skip）、output（纯数据，不含解释性文本）、trace_id（关联原始指令）；
- 断言（Assertion）：由调用方在收到响应后立即执行的校验逻辑，例如 Planner 收到 Understander 响应后，断言 “output.required_interfaces 非空且全部存在于当前 repo 的 API 文档中”。
状态管理不靠全局内存，靠版本化工作区快照
每个任务启动时创建独立工作区（workspace），Agent 每次操作都基于前序快照生成新快照，而非修改共享内存：
- 快照内容包括：文件树哈希、已执行步骤清单、各 Agent 输出摘要（非原始大文本）、本次操作元数据（时间、Agent 名、指令哈希）；
- 当 Checker 报错时，系统自动回退到上一有效快照，重试前先运行断言集确认环境一致性；
- 人工介入点明确绑定到快照 ID，开发者看到的是 “在 snapshot_abc789 下，Coder 第 2 步输出未通过 Checker 断言 #4”，而非模糊的“代码有问题”。
Human-in-the-loop 不是兜底开关，而是协议一部分
人在环中不是等出错才介入，而是在关键决策点被主动询价：
- Understander 识别出需求歧义（如“支持多语言”未指明覆盖范围）时，生成结构化澄清问题（选项式，非开放问答），推送到协作界面；
- Planner 判断某步骤可能引发跨服务影响时，自动触发影响分析报告（含调用链图谱+变更点标记），等待显式 approve；
- 所有人工操作（选、点、输）都作为新指令写入工作区快照，成为后续 Agent 可读取的确定性输入，不产生隐式状态。
