核心用法
Mission Control 是一套专为 Telegram 设计的多代理实时可视化仪表盘技能，通过单条消息的动态编辑、反应表情状态切换和内联按钮交互，完整呈现任务从初始化到完成的 6 阶段生命周期（INIT → RUNNING → PARTIAL → AWAITING APPROVAL → COMPLETE → ERROR）。
关键特性：
- 4+1 层 UX 模型：Pin（置顶锚定）→ Ack 反应（👀 瞬时确认）→ Phase 反应（🔥/🎉/❌ 状态）→ 消息本体（进度详情）→ Inline 按钮（人机交互）
- 视觉规范：禁用框线字符与空格对齐，采用 Emoji 语义结构、16 段进度条（▓░）、Unicode 粗体与层级符号 ↳
- 双通道架构：DM 运营商通道（全功能：置顶、反应、按钮、实时编辑）+ @MIYABI_CHANNEL 日志通道（仅起止通知）
- 人机确认门（Phase 4）：在不可逆操作（发布/发送/删除/计费）前强制暂停，提供 Approve/Preview/Revise/Abort 四键决策
进度追踪机制：
- 代理状态：⏳ INIT → 🔥 RUNNING → ✅ DONE / ❌ ERROR / 🔄 RETRY
- 消息反应同步：🔥（进行中）→ 👀（待确认）→ 🎉（完成）→ ❌（错误）
- 成本计时：每个代理独立累计时间与费用，全局汇总至任务级
错误恢复：支持 Retry/Skip/Partial Complete/Abort 四种错误处理按钮，自动重试计数与依赖等待状态可视化。
显著优点
1. 零客户端依赖：纯 Telegram Bot API 实现，无需用户安装额外应用
2. 状态一目了然：反应表情允许从聊天列表直接判断任务阶段，无需点开消息
3. 防误触设计：AWAITING APPROVAL 阶段强制人机确认，避免自动化任务的不可逆操作风险
4. 细粒度透明：16 段进度条 + 实时 "thinking" 输出行，满足用户对黑盒 AI 的可解释性需求
5. 成本可控：实时费用累加显示，适合 API 按量计费场景的心理预期管理
潜在缺点与局限性
- 平台锁定：深度绑定 Telegram 生态（reactionLevel=extensive、pin/unpin API），迁移成本高
- 单消息约束：复杂任务（>10 代理）可能导致消息过长，触发 Telegram 4096 字符限制
- 编辑频率限制：高频状态更新可能触及 Telegram 编辑速率限制（实测约 1 次/秒安全）
- 无历史追溯：消息编辑覆盖历史状态，需依赖外部日志（如 Channel 归档）保留完整记录
- 人机确认延迟：AWAITING APPROVAL 阶段阻塞后续流程，不适合完全无人值守的夜间批处理
适合人群
- 需要协调多个 LLM 代理完成复杂工作流的技术团队
- 对 AI 自动化有心理安全顾虑、要求关键节点人工确认的管理者
- 追求"可见即所得"透明度的 AI 产品演示场景
- 基于 Telegram 构建内部 Ops 工具链的中小团队
常规风险
| 风险类型 | 说明 | 缓解措施 |
|---------|------|---------|
| 状态漂移 | 消息编辑失败导致显示与实际状态不一致 | 实施编辑失败重试 + 最终状态强制覆写校验 |
| 误操作批准 | 用户误触 Approve 按钮执行不可逆操作 | 关键操作要求二次确认（如 Preview 先行）或时间延迟 |
| Token 泄露 | Bot API 调用日志中泄露 chat_id/message_id | 日志脱敏 + 最小权限 Bot Token 管理 |
| 依赖死锁 | 代理 A 等待代理 B，B 因错误停滞 | 可视化依赖关系 + 超时自动 Skip/Abort 机制 |
| 费用失控 | 重试循环导致 API 费用累积 | 设置单任务费用上限与重试次数上限 |
本技能作为"人机协作多代理编排"的展示层，需配合底层 spawn/会话管理技能使用，不单独具备任务执行能力。