MiMo Code的递归式任务拆解通过主代理动态编排、角色隔离与上下文分层实现可控展开：主代理负责拆解与聚合，子代理专注执行；深度限3层且需语义可分离；上下文按Core/Boundary/Memory三层压缩传递；终止由深度阈值、final_answer字段校验或收敛信号硬约束。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
子 Agent 执行递归式任务拆解，核心不在“递归”本身，而在于主代理如何设计触发条件、边界控制与结果聚合机制。MiMo Code 的编排逻辑不依赖模型硬编码递归，而是通过角色隔离 + 动态编排 + 上下文分层三者协同实现可控的层层展开。
主代理负责“拆”与“收”，子代理只做“干”
主代理（Coordinator）不直接写代码或查文档，它的唯一职责是判断当前任务是否可进一步分解，并决定派哪个子代理、带什么上下文、设什么终止条件。比如用户说“优化登录模块性能”，主代理不会自己分析慢查询，而是生成结构化指令：
- 启动 Analyzer 子代理：限定只读 src/auth/ 目录 + 最近3次性能日志，输出瓶颈摘要
- 收到摘要后，若含数据库延迟，则启动 DB Optimizer 子代理：只给 schema 和慢 SQL，禁止访问其他模块
- 若优化方案涉及前端渲染，则再启动 Frontend Reviewer 子代理：仅传 diff 和 React Profiler 截图
递归不是无限嵌套，而是有深度阈值和语义断点
MiMo Code 默认限制子代理调用深度为3层，且每层必须满足语义可分离性：上层输出必须能被下层无歧义解析为独立任务。例如：
- 第1层输出：“发现 login.tsx 中 useAuth() 调用耗时占比62%” → 可触发第2层（聚焦该 Hook）
- 第2层输出：“useAuth() 内部 fetchUser() 未加缓存，重复请求3次” → 可触发第3层（设计缓存策略）
- 第3层输出：“建议添加 SWR 缓存，key 为 user-${id}” → 不再拆解，进入执行环节
一旦某层输出无法提炼出明确、窄口径的子任务（如出现“可能需要重构整个认证流程”这类模糊描述），编排器自动截断并返回主代理重新规划。
上下文不堆叠，而是按角色分层压缩传递
每个子代理启动时，接收的不是完整对话历史，而是三层上下文包：
- Context Core：当前任务目标 + 上层交付物（如 Analyzer 输出的瓶颈摘要）
- Context Boundary：文件白名单、API 权限、禁止操作项（如“不可修改 config.js”）
- Context Memory：SQLite FTS5 检索出的、与本子任务强相关的记忆片段（如历史类似优化案例）
这样避免了传统单Agent模式中上下文随轮次指数膨胀的问题，也防止子代理“越界思考”。执行完毕后，子代理只回传结构化结果（JSON Schema 固定），主代理统一注入 compact 机制压缩后再决定是否继续拆解。
终止条件由编排器硬约束，而非模型主观判断
递归式拆解的结束不由子代理说了算。MiMo Code 的调度器内置三类硬终止信号：
- 深度到达预设值（默认3）
- 子代理输出包含
"final_answer": true字段且内容满足 L3Impl 规格校验 - 连续两轮子代理返回空工具调用 + 无新信息增量（判定为收敛）
任一触发即停止派发，将所有子代理结果交由主代理做一致性校验与最终整合——这才是真正落地的“递归”，不是模型在幻觉里一层套一层。
