mimo code 的任务编排核心是明确人与ai的责任边界：ai执行可结构化、可验证步骤，人定义目标、判断价值、兜底异常；通过dynamic workflow将明确task转为含action/condition/fallback的动态执行链，严格按用户限定的文件范围、约束条件和退出阈值履约，不越界决策。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的任务编排不是把人替掉，而是把“谁该做什么”划清楚——AI 负责执行可结构化、可验证的步骤，人负责定义目标、判断价值、兜底异常。它的边界不在能力上限，而在责任归属。
任务编排：用 Dynamic Workflow 把意图转成可执行链
MiMo Code 不接受模糊指令，比如“让项目跑起来”。它要求你以 Task 形式输入明确目标，例如：“添加 JWT 登录接口，包含注册、登录、token 刷新逻辑，并通过 Jest 测试覆盖核心路径”。输入后，Agent 自动拆解为 Plan → Build → Test → Git Commit 的闭环流程。
- Dynamic Workflow 是代码化的任务图谱，每步含 action（如 edit-file）、condition（如 test-passed?）、fallback（如 revert-last-change）
- 用户可随时中断、跳过某步、或手动注入新 step（比如加一行日志后再继续）
- Workflow 不固化，每次运行都根据当前代码状态动态生成，避免硬编码带来的僵化
AI 程序员的职责止于“可验证动作”
它能改代码、跑测试、提 PR，但不决定“要不要加这个功能”“API 设计是否符合长期架构”。这些属于人的 domain judgment，MiMo Code 明确不越界：
- Goal 验证独立于主 Agent：它想停时，必须由 verifier 子 agent 检查是否真满足自然语言目标（如“所有测试通过且无 lint 错误”），而非自己说了算
- 涉及业务逻辑取舍（如用 session 还是 JWT）、合规风险（如 GDPR 数据处理）、跨团队协作（如接口对齐），它会暂停并提示“需人工确认”
- Git commit message 和 PR description 由 AI 生成，但最终提交权限仍绑定用户 SSH key 或 token，不可绕过
边界定义的关键动作：Scoping 由人完成，不是模型猜的
启动前，用户要主动做三件事，这本身就是职责划分的起点：
-
限定文件范围：用
.mimoignore或 CLI 参数指定只读写 src/ 和 tests/，排除 node_modules 和 config/ - 声明约束条件：比如 “必须兼容 Node v18”，“不能引入新依赖”，“所有函数需有 JSDoc”
- 设定退出阈值：如 “最多尝试 5 次修复 build error，失败则 halt 并输出诊断日志”
这些不是配置项，是契约。MiMo Code 严格按此履约，超出即报错，不自行脑补、不降级执行。
记忆与进化不等于自主决策
它用 SQLite FTS5 记住项目结构、常用模式、你偏好的命名风格，甚至上次失败的调试路径——但这只为更快、更准地执行当前任务，而非积累“经验”后擅自改变工作方式：
- Dream/Distill 是压缩记忆，不是自我迭代；生成的新 pattern 仍需人工 review 才进入项目记忆库
- Writer subagent 写 checkpoint，但内容格式和校验规则由 harness 固定，AI 无法修改 schema
- Compose 模式下生成的代码成品，始终带 diff 预览和执行沙箱，不自动落地
它越可靠，越强调人的掌控权。真正的 AI 协作，是从清晰划出“这里我来，那里你定”开始的。
