mimo code 的任务调度以代码难度为核心，通过静态结构、影响面、确定性及历史数据量化难度，结合agent算力、专长、负载与信任等级动态匹配最优执行者。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的任务调度不是简单轮询或随机分发，而是把“代码难度”作为核心输入，动态匹配最合适的 Agent 执行。它不靠人工指定谁干哪部分，而是让系统自己判断：这段逻辑要改多少文件、涉及多少依赖、是否要跑测试、有没有并发风险——然后算出一个“难度分”，再结合每个 Agent 的实时状态和能力，选最优执行者。
任务难度怎么量化？
难度不是主观感觉，而是由多个可观测指标合成：
- 静态结构复杂度：AST 节点数、嵌套深度、跨模块引用数（比如修改一个被 12 个 service 调用的 core utils 函数）
- 变更影响面：Git diff 涉及文件数、是否含数据库 schema 或 API 接口定义
- 执行确定性：是否需调外部服务（如支付网关）、是否含非幂等操作（如发邮件）、是否有竞态条件
- 历史经验值：同类任务在该仓库中平均耗时、失败率、重试次数（来自 MiMo Code 内置的 SQLite FTS5 持久记忆）
Agent 能力怎么建模？
每个 Agent 不是“通用工人”，而是带属性的执行单元：
- 算力标签：CPU/GPU/NPU 类型、内存容量、是否支持本地模型（如 MiMo-V2.5-Pro）
- 领域专长：标记为 “backend-java”、“frontend-react”、“infra-terraform” 等，由 spec-manager 中 L2 Design 阶段自动打标
- 当前负载水位：不仅看队列长度，还计算“剩余有效 Token 容量”——即当前上下文压缩后还能承载多少复杂度分
- 信任等级：基于过往任务成功率、代码审查通过率、是否触发过 rollback，动态调整调度优先级
调度器怎么决策？
每次分配前，调度器会做一次轻量级模拟：
- 对候选 Agent，预估“加入该任务后”的 load_score = (当前负载 + 任务难度分) / Agent 容量
- 排除 load_score > 0.9 的节点（防过载）
- 在剩余节点中，优先选 load_score 最小 + 领域匹配度最高 + 信任等级 ≥ 0.85 的 Agent
- 若存在多个合格节点，则引入微小随机扰动，避免长期固化单点压力
和 spec-manager 怎么联动？
难度评估不是孤立进行的，而嵌入整个工程流程：
- L1 PRD 阶段就标注业务影响等级（P0/P1/P2），转化为基础难度系数
- L2 Design 输出的接口契约、边界约束、回滚方案，直接参与“执行确定性”打分
- L3 Impl 冻结后，spec-manager 生成可验证的 task-spec.json，其中包含预期变更范围——调度器据此校验实际 diff 是否超界
- 任务完成后，结果自动写回 spec-manager 的 evidence log，用于下一轮难度模型迭代
这套机制让 MiMo Code 在处理“重构用户鉴权模块”这类高难度任务时，能自动避开刚跑完 CI 的低信任度 Agent，把任务交给 GPU 节点上专精 security 的子 Agent，并预留 30% 容量应对可能的多轮验证迭代。不复杂但容易忽略。
