MiMo Code 本身并不直接介入多 Agent 之间的依赖链管理，真正发挥核心作用的是其背后的 spec-manager 规格管理器。这套分层规格与任务冻结机制，本质上就是把开发者脑海中“谁先执行、谁后执行”的调度逻辑，转化为一份清晰可读、可审查、可追溯的工程契约——而不是让 AI 智能体自行猜测。
从实际协作效果来看，依赖关系并非由 Agent 自主推导，而是通过规格显式声明来确定的。
依赖关系并非靠 Agent 自行推导，而是通过规格显式声明
在 MiMo Code 与 spec-manager 构成的体系中，Agent 不需要自行判断“谁先运行、谁等待谁”。所有依赖关系都明确记录在一个三层规格模型里：
- L1 PRD（需求层）——定义业务目标与验收标准，是所有后续工作的唯一参照源。
- L2 Design（设计层）——明确技术选型、接口契约以及边界约束。这一层天然承载着前置依赖。典型示例：“必须等待 auth-L2.1 完成后，user-profile-L2.2 才能确定 token 校验方式”。
- L3 Impl（实现层）——绑定具体文件路径、函数签名与测试用例。每个 L3 规格必须且仅关联一个 L2 父项，形成强依赖锚点。
这样一来，依赖关系不再是运行时临时判断的，而是写入规格中、任何人都能一目了然的约定。
多 Agent 并行时，通过“规格状态”而非“进程信号”实现同步
当团队启用 Compose 模式，或接入类似 Claude Agent Teams 的多实例架构时，MiMo Code 完全不依赖 IPC 或共享内存来协调 Agent。它借助 spec-manager 维护的本地规格状态进行同步：
- 每个 L3 规格都有明确的生命周期状态：draft → review → frozen → implemented → verified。
- Agent 启动前会自动检查所依赖的父规格是否已标记为 frozen（冻结）。若未冻结，则暂停执行并明确提示阻塞原因。
- 多个 Agent 可以同时处理不同的 L3 规格——只要它们的父 L2 不冲突、修改的文件不重叠，就能天然支持安全并行。
该机制的优势在于：无需操心进程间信号，无需维护共享内存，只需监控一个本地状态文件，简洁高效。
跨会话/跨 Agent 的依赖回溯，依赖规格 ID 而非聊天记录
传统 AI 编程协作中常遇到尴尬场景：A Agent 修改了 config.yaml，B Agent 却浑然不知，需要重新加载配置。这种断裂源于上下文无法沉淀。spec-manager 的解决方案是使用唯一规格 ID（如 auth-L2.1）作为事实源：
- 所有代码变更、命令执行、测试结果都必须关联到某个 L3 规格 ID。
- Git commit message 会自动注入
[spec: auth-L3.2]标记。后续可通过git log --grep="spec:"快速追踪整个依赖链。 - spec-manager CLI 还提供
spec-manager spec trace auth-L3.2命令，一键展开从 L1 需求到当前实现的完整依赖树。
说到底，这不仅是给 Agent 看的工具，更是为人类工程师留下的可审计、可回溯的“工程日志”。不依赖记忆，不依赖聊天记录，全靠规格 ID 串联起来的稳定链条。