再次发送请求前，先检查任务、当前运行和投递状态。确定执行者是离线、受阻、预算受限还是服务商失败，保存进度，核实外部效果是否已经发生，再采用最小合适修复，并验证一次明确结果。
先描述故障，再选择修复
先明确缺少什么：没有回复、没有进展、任务未完成，还是投递失败。记录智能体、任务、时间和最后可见步骤。“在线”只说明一部分情况；桥接仍在签到时，模型服务商可能正在拒绝密钥。
EmperorClaw 的当前状态面板、任务历史、消息投递状态和健康页面提供不同证据。检查运行结果与具体失败原因，不要仅凭聊天安静就判断失败。
让原因对应下一步
| 观察到的原因 | 首先调查 |
|---|---|
| 密钥被拒绝或服务商余额不足 | 检查获授权的服务商配置 |
| 预算上限 | 审阅支出与预期额度 |
| 运行时离线 | 检查主机与桥接连接 |
| 缺少项目访问 | 检查任务分配与预期范围 |
| 等待决定 | 处理收件箱问题 |
| 运行活跃但没有进展 | 查看最后步骤与任务证据 |
不要把扩大权限或提高预算当成所有失败的解法；任务也可能分给了错误负责人，或缺少输入。
检查操作是否已经发生
假设执行者已经发送报告，却在记录成功前断线。重新说“再发送一次”可能给客户重复发信。应先检查外部服务的投递记录或其他可靠证据。
结果不确定时，把不确定性写入任务，并请负责人调查。聊天回复失败并不能证明底层操作失败。交给下一负责人的应是当前证据，而不只是原请求。
有目的地重启
对于已连接的 Hermes 主机，获授权的管理员可检查主机卡片并请求重启桥接或网关。网关可能由多个执行者共享，适当时选择等待空闲，并在强制重启前审阅影响。
服务商密钥问题通常需要修改配置，而不是反复重启。缺少业务输入则需要决定。中断仍有进展的运行前，保留有用检查点和任务笔记。
只重试剩余工作
- 写下简短检查点：已完成、不确定、仍需完成。
- 应用具体修复，确认预期执行者有访问权。
- 通过正确的任务或消息恢复入口重试。
- 观察下一运行，确认回复在正确线程中。
- 检查最终文件或外部结果，再更新任务状态。
Emperor 通过心跳、租约、重试和故障事件暴露中断工作。这些记录帮助恢复，但不代表任意外部系统都能保证严格只执行一次。
降低下次中断的恢复成本
让执行者在长工作中记录检查点、说明缺少的输入，并把产出关联到任务。将大任务拆成可审核结果，为每个外部操作指定唯一负责人，避免无限重试。
故障事件用于提醒与升级，实际修复通过任务表示。Emperor 的事件功能不是完整的事件指挥或复盘平台，流程应与问题规模相称。
用一次无害中断练习
运行一项不会联系真实客户或修改生产的小测试，中断连接，检查可见证据，再恢复剩余工作。可用控制见恢复指南，信号说明见健康手册（英文）。