MiMo Code 的多 Agent 系统强调可观测性、状态一致性与轻量级干预协同；实时采集阶段、上下文ID、心跳、错误码、资源占用等最小必要字段，用枚举和预定义错误码；状态分层持久化，避免全内存存储。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 的多 Agent 系统中，Agent 监控与状态管理不是“加个日志就完事”的事，核心在于可观测性、状态一致性与轻量级干预能力三者协同。监控不能只看是否存活，而要能回答“它正在做什么”“为什么卡在这里”“上次成功/失败在哪一步”。状态管理也不能靠全局变量或内存硬编码，得兼顾隔离性、可恢复性和跨节点一致性。
实时状态采集：聚焦关键维度，避免埋点泛滥
每个 Agent 应主动上报最小必要状态字段：当前执行阶段（如 init → planning → action → feedback）、上下文 ID、最近一次心跳时间、错误码（非堆栈）、资源占用（CPU/内存增量、token 使用量）。不建议上报原始输入或完整历史，既增开销又存隐私风险。可用轻量级结构化格式（如 JSON 行）通过本地 Unix Socket 或 gRPC 流式推送到中央 Collector，延迟控制在 200ms 内。
- 阶段字段用枚举值而非字符串，便于聚合分析和告警规则配置
- 心跳超时阈值需按 Agent 类型差异化设置（例如 planner 类设为 5s，executor 类设为 120s）
- 错误码统一映射到预定义集（如 ERR_TIMEOUT=101、ERR_VALIDATION=203），不依赖语言级异常名
状态持久化：分层存储 + 显式生命周期
Agent 状态不应全放内存。短期运行态（agent_session 表），含 session_id、status（running/paused/failed/completed）、last_updated 和 checkpoint_json 字段。关键点是：所有状态变更必须走原子写入，且每次更新附带版本号或 CAS token，防止并发覆盖。
- 暂停操作不是 kill 进程，而是将状态设为 paused 并保存当前 context snapshot 到 checkpoint_json
- 恢复时校验 checkpoint_json 中的 schema 版本，不兼容则拒绝启动并告警
- 失败后自动归档原始 input + error trace + checkpoint_json 到对象存储（如 S3），保留 7 天供回溯
可视化与干预闭环：从“看见”到“管住”
Dashboard 不仅展示 Agent 列表和颜色状态灯，应支持按 session_id、user_id、error_code、stage 多维下钻。点击任一 Agent 可查看其完整执行链路图（含子任务耗时、调用外部 API 的响应码、LLM 调用的 prompt token 数）。更关键的是提供安全干预按钮：Pause（触发 checkpoint）、Retry（重放最后一步，带可编辑参数）、Force Complete（跳过剩余步骤，标记为 completed_with_skips）——所有操作记录审计日志，含操作人、时间、原因备注（必填）。
- Retry 操作默认复用原 prompt template，但允许临时覆盖 temperature 或 max_tokens
- Force Complete 前强制弹窗提示影响范围（如“将跳过数据校验，下游模块可能收到未验证结果”）
- 所有干预动作触发事件通知（如 Slack webhook），并同步更新关联 session 的 status 字段
故障自愈与降级策略：让系统有“呼吸感”
单个 Agent 故障不应导致整条流水线阻塞。建议设计两级降级：一级是同类型 Agent 的热备切换（如 planner-A 失效，自动路由至 planner-B，共享同一 session state）；二级是流程级兜底（如当 executor 连续失败 3 次，自动启用规则引擎 fallback，用确定性逻辑生成简化结果）。自愈动作需有冷却期（如 30 秒内不重复触发相同恢复策略），并记录“降级生效次数”指标用于后续模型优化。
- 热备切换前校验目标 Agent 的 readiness probe（如 /health?deep=true 返回包含 session store 连通性）
- fallback 规则需提前注册，不可运行时动态注入，确保可测试、可审计
- 每次降级发生时，向 session 关联的 user_id 发送轻量通知（如站内信：“您的请求已启用备用处理路径，结果可能略有差异”）
