话不多说，先上结论。MiMo Code 这套架构的核心思路，并不是去预设一个固定的 Agent 团队，而是搭建一个“任务驱动、按需启停、能力感知”的动态运行机制。它的精髓，其实已经内化在了 Dynamic Workflow 和 Max Mode 这些设计里，不需要我们从零开始造轮子。
Dynamic Workflow：从“固定编制”变成“项目制外包”
parallel() 这个原语，是整个动态调度体系的起点。它厉害的地方在于，不跟具体 Agent 数量挂钩。任务简单，可能只启动 3 个子 Agent；任务复杂，并行规模可以拉到 50 个。这就像从“固定编制”变成了“项目制外包”。
- 子任务由主 Agent 动态生成的 Ja vaScript 脚本描述，例如：
await parallel([agent({prompt:"写接口"}), agent({prompt:"补测试"}), agent({prompt:"做安全扫描"})]) - 每个子 Agent 都被关在隔离沙箱里独立执行。一个子任务失败，不会拖垮整个流程，系统会支持重试或降级策略
- 实际能并行跑多少，不是硬编码死的，而是由当前的内存、模型并发限制等系统资源，以及任务本身的复杂度（比如代码行数、依赖深度）共同决定的
Max Mode：用“货比三家”来换取更有把握的方案
当某个子任务特别关键，不容有失时，就可以启动 Max Mode。它的做法很简单粗暴：并行生成多个候选方案（默认 5 个），然后由裁判模型从中挑出最优解。这本质上是一种“横向扩维”的调度，用算力换质量。
- 特别适合用在核心模块实现、安全策略生成这类关键路径上
- 是否启用 Max Mode，由主 Agent 根据任务的优先级、历史成功率、成本阈值等信号动态判断
- 虽然 token 消耗会多出 4~5 倍，但带来的回报是 SWE-Bench Pro 完成率提升 10~20%，这笔账算下来是划算的
四层记忆体系：确保“前线的通讯不会断”
动态调度最怕的就是上下文丢失，每次都要从头推理。MiMo Code 的四层记忆设计，就是为了解决这个痛点——让不同 Agent 能共享必要信息，避免重复劳动。
- Session 记忆：保存当前会话的完整状态（11 个结构化字段），同一流程内的所有子 Agent 都能实时读取
- Project 记忆（MEMORY.md）：记录了架构决策、技术约束、用户规则。子 Agent 启动时，这些上下文会被自动注入，不用再问一次
- Global 记忆：跨项目保存用户的偏好，比如默认语言、代码风格等。它会直接影响调度倾向，比如偏好用 TypeScript 的子 Agent
- History 轨迹（SQLite）：记录每一条消息和工具调用，用于事后复盘调度瓶颈，或者优化子任务的拆解策略
MCP & A2A：把“外部帮手”也拉进调度体系
纯内部的调度总有边界。现实场景下，经常需要调用数据库、CI/CD、Git 或是第三方 API。MiMo Code 通过标准化协议，把这些“外部力量”也纳入了混合调度。
- MCP（Model Context Protocol）：统一了工具接入的规范，让任意子 Agent 都能安全地调用 Shell、Git、SQL 等能力
- A2A（Agent2Agent Protocol）：这是一种基于 JSON-RPC 的异步委托机制。主 Agent 可以把子任务“委派”给外部服务型 Agent，比如部署 Agent、测试 Agent
- 调度器会根据响应延迟、成功率、成本标签（比如用 GPT-4 还是 GLM-4v），动态决定是本地执行，还是远程委托