mimo code采用目标驱动的轻量级语义通信机制，以结构化goal指令、异步checkpoint状态同步、硬编码子agent权限及语义回滚容错为核心设计。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的多 Agent 系统并非依赖通用通信协议（如 A2A 或 ANP），而是围绕长程编程任务的可靠性与状态连续性，构建了一套轻量、内聚、面向语义的内部通信机制。它不追求跨系统互操作，而聚焦于子 Agent 之间“谁对谁说什么、何时说、怎么验证”的闭环控制。
通信以目标驱动，而非消息泛化
不同于传统协议强调字段定义与序列化格式，MiMo Code 的通信本质是 Goal-Driven 的指令流。主 Agent 不直接发送自然语言请求，而是生成结构化 Goal 指令（含预期输出类型、校验条件、超时阈值），交由 verifier、writer、executor 等子 Agent 分别响应。这种设计天然规避了语义歧义——每个消息都绑定明确的验收标准。
- Goal 指令自带可执行断言，例如
{"goal": "修改 src/utils/logger.ts，添加日志等级过滤功能", "verify": "grep -r 'levelFilter' src/utils/ && npm test | grep PASS"} - 子 Agent 只需返回
{success: true, output: "...", logs: [...]}，无需协商协议版本或重试策略 - 通信失败时，不是重发消息，而是触发 Goal 降级（如从“自动重构”退为“生成 diff 建议”）
状态同步靠 checkpoint，不依赖实时信道
MiMo Code 明确放弃长连接或流式推送，转而采用异步、离线、可验证的状态快照机制。writer 子 Agent 在预设窗口利用率节点（20% / 45% / 70%）主动写入结构化 checkpoint 文件，内容包括：当前任务树、已执行步骤哈希、待验证变更集、上下文摘要。
- checkpoint 是唯一权威状态源，所有子 Agent 启动时先加载最新 checkpoint，而非轮询中心服务
- 文件采用 JSON Schema 校验 + SHA256 签名，防止中间篡改或加载损坏状态
- 当主 Agent 因内存溢出重启，可从最近 checkpoint 恢复，跳过已验证步骤，避免重复执行
子 Agent 身份与权限硬编码在 harness 层
没有动态注册、服务发现或 token 认证环节。每个子 Agent 类型（verifier/writer/executor）在启动时由 harness 加载固定配置，其能力边界、输入约束、输出契约均在代码中静态声明。
- 例如 executor 只能调用白名单内的 shell 命令（
git, npm, curl, sed），且每次调用前自动插入 dry-run 检查 - verifier 不接收原始代码，只接收 executor 输出的
diff + test_result，强制解耦执行与判断 - 无跨进程通信开销——多数子 Agent 以 Python subprocess 方式运行，通过 stdin/stdout 传递结构化 JSON，零依赖外部消息中间件
容错靠语义回滚，不靠协议重传
当某步执行失败（如 npm install 报错），系统不尝试重发请求或切换传输通道，而是基于 Goal 语义发起回滚：writer 清理本次 checkpoint 中标记为“未验证”的变更，verifier 重新评估上一稳定状态是否仍满足用户原始 Goal。
- 回滚粒度是逻辑任务单元（如“添加登录拦截器”），而非字节或消息包
- 所有子 Agent 输出均带 trace_id 和 step_id，便于在日志中关联因果链，而非依赖协议层的 request-id 透传
- 不实现 ACK/NACK 机制，而是用 Goal 完成率（completed_goals / total_goals）作为健康指标，低于阈值时自动进入 debug 模式
