MiMo Code 的协作 Agent 在管理跨模块依赖时，并非依赖单一模型处理全部上下文信息。其采用清晰的分工与结构化协调机制，各 Agent 分别聚焦不同维度——部分监控调用链路，部分检查接口契约，部分验证数据流转路径，最终由 Coordinator 汇总分析并生成综合判断。具体而言：RepoAgent 基于 SQLite FTS5 实现跨语言依赖识别，支持行号定位与 Git blame 溯源；Coordinator 依据契约一致性、测试覆盖率及历史失败率构建风险模型，输出风险评分与执行建议；状态信息通过三重记忆系统实现持久化，并与 spec-manager 协作，将依赖关系纳入可追溯的设计管理流程。
这套协作机制的本质在于——各 Agent 明确分工、各司其职，由协调者基于专业分析给出综合判断，而非简单通过多数投票进行决策。
依赖识别由 RepoAgent 配合文件级语义索引完成
RepoAgent 的功能远不止扫描 import 语句。它整合 MiMo Code 的 SQLite FTS5 全文检索能力，将跨文件的符号引用（如函数名、类名、配置键等）精准映射至实际定义位置，同时标注调用深度与变更敏感度。举例来说：当你计划修改 user-service 中的鉴权逻辑时，RepoAgent 会自动列举所有依赖该服务的 order-service 与 notification-service 中的调用节点，并区分直接调用与经由中间件转发的调用方式。
- 支持跨编程语言的依赖识别（例如 Python 调用 Go 微服务的 gRPC 接口定义）
- 能够区分强耦合（修改即报错）与弱耦合（存在 fallback 或 mock 机制）
- 分析结果包含行号与 Git blame 信息，便于快速追溯代码责任人
冲突消解由 Coordinator 主导，采用风险建模而非投票机制
Coordinator 并非简单采纳多数意见，而是基于三项输入进行加权评估：（1）RefactorAgent 提出的重构方案是否破坏现有接口契约；（2）RepoAgent 标识的跨模块调用是否位于测试覆盖范围之内；（3）历史提交记录中同类变更的失败概率。最终生成 0 到 100 的风险评分，并附带可执行建议。例如：“建议先为 notification-service 补充契约测试，随后再同步升级 user-service 的 auth SDK 版本”。
- 风险评分低于 30 → 可立即执行变更
- 30 至 70 → 需要人工复核关键路径
- 高于 70 → 自动挂起并生成验证清单（包含需执行的测试集合与需审查的日志关键词）
状态同步依托持久记忆系统，而非临时上下文传递
各 Agent 的中间结论并非通过 prompt 注入进行传递，而是写入 MiMo Code 的三重记忆系统：项目记忆（存储代码结构快照）、会话检查点（记录当前任务阶段）、任务进度（保存已验证的依赖链）。下次启动时，RepoAgent 可直接读取先前分析的模块边界，Coordinator 能够复用历史风险模型参数，从而避免重复运算。
- 记忆写入时自动触发增量差异比对，仅存储变化部分，有效节省空间
- 跨会话恢复时自动校验依赖图一致性（例如检测到某模块被 git rebase 移除，则触发重新分析）
- 支持通过 mimo memory list --tag=auth-deps 命令查看某次跨模块分析的完整记忆快照
与 spec-manager 协同，将依赖管理融入工程流程
当跨模块变更涉及 L2 Design 层规格时，MiMo Code 会自动调用 spec-manager 接口，将识别出的依赖关系写入设计文档。例如：RepoAgent 检测到 payment-service 依赖 user-service 的 token 解析逻辑后，自动在 spec-manager 的 L2Design 文档中追加记录：“支付服务需兼容 user-service v2.3+ 的 JWT 签名算法变更”，并关联对应的 PR 链接与测试用例编号。
- 确保依赖变更不仅作为技术操作，更是可追溯的设计决策
- 后续 CI 流程可自动对比规格说明与实际代码，发现未被记录的隐式依赖
- 新成员加入项目时，可通过 spec-manager spec show auth-L2 命令直接查看所有跨模块约束