我们不妨先做一个核心判断：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-ja va”、“frontend-react”、“infra-terraform”这样的标签，由 spec-manager 在 L2 Design 阶段自动打标，确保专业的人干专业的事。
- 当前负载水平：不只是看队列长度，还计算“剩余有效 Token 容量”——也就是当前上下文压缩后，还能承载多少复杂度分。这比简单的队列长度更精准。
- 信任等级：基于过往任务成功率、代码审查通过率、是否触发过 rollback，动态调整调度优先级。信任度低的 Agent，自然会少接一些关键任务。
调度器怎么决策？
具体来说，调度器在每次分配前会做一次轻量级模拟：
- 对每个候选 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，用于下一轮难度模型的迭代优化。
举例来说，当需要“重构用户鉴权模块”这类高难度任务时，调度器会自动避开那些刚跑完 CI、信任度较低的 Agent，把任务交给 GPU 节点上专精 security 的子 Agent，并提前预留 30% 的容量，以应对可能的多轮验证迭代。这套机制说起来不复杂，但在实际应用中，却很容易被忽略。