MiMo Code 的子 Agent 协作，依托结构化信息流驱动任务闭环。核心不在于哪个 Agent 的工作量更大，而在于信息如何高效传递、持久存储与精准验证。下面逐一拆解关键机制。

第一个关键要点：采用标准任务单统一输入规范。每个子 Agent 不再接收模糊指令或自由格式文本，只识别一种结构化对象——Task。该对象包含 task_id、agent_name、instruction 和 context 字典。举例说明，让测试 Agent 执行单元测试时，指令不能是“跑一下 test_auth.py”，而应明确指定：

• instruction：“执行 auth 模块的全部单元测试，覆盖 login、logout、token_refresh 三个函数”
• context：附带当前代码 diff、上一环节生成的 mock 数据路径、CI 环境变量配置

如此一来，主 Agent 无需记忆每个子 Agent 的参数习惯，所有调度逻辑统一收束到 Orchestrator 层。增减子 Agent 时也无需修改调用方式，保持架构简洁高效。

通过独立Writer子Agent持久化关键信息

主 Agent 自身不记录笔记，所有记忆由专用 Writer 子 Agent 负责。它在对话进度达到 20%、45%、70% 时自动触发 checkpoint，提取 11 个固定字段（如意图、错误、设计决策），写入磁盘。这意味着：

• 当编码子 Agent 修改了 login.js，Writer 同步记录“修改原因：修复 JWT 过期校验逻辑”
• 当审查子 Agent 发现一处潜在 SQL 注入，Writer 将其归入“安全风险”字段，而非混在聊天流中
• 后续会话重启时，系统直接加载这些结构化快照，而不是让模型从长文本里“回忆”

以Goal机制锚定交付终点

避免子 Agent 提前宣布“已完成”。MiMo Code 引入 Goal 机制——任务完成与否不由 Agent 自报，而由独立验证模块对照预设目标判断。例如：

• Goal 定义为：“生成可运行的登录页，含表单提交、错误提示、成功跳转，且通过 ESLint + Prettier 校验”
• 前端子 Agent 输出 HTML 后，验证模块自动执行 lint、启动本地服务、截图比对 DOM 结构
• 只有全部达标，才标记任务闭环；否则返回具体失败项（如“缺少 loading 状态反馈”），触发重试流程

用spec-manager补齐工程上下文

单纯子 Agent 协作容易陷入“技术执行正确，但偏离需求本质”的困境。spec-manager 将协作拉回工程轨道：先生成 L1PRD（用户价值）、L2Design（技术边界）、L3Impl（实现细节），再分发给对应子 Agent。例如：

• L3Impl 冻结后，编码子 Agent 才开始写代码，且每步修改需关联到该规格 ID
• 测试子 Agent 的用例必须覆盖 L3 中列出的所有验收点，缺失则报 warning
• 所有子 Agent 的输出日志自动打上 spec_id 标签，方便后期按需求追溯全链路行为

这些机制并不复杂，但常被忽视——许多协作问题的根源，恰恰在于信息流未能理顺。