AI Agent备份≠恢复：必须做还原测试

备份任务变绿，并不意味着你的 Agent 仍然可以恢复。

问题出在备份里只有文件，却没有维持这些文件意义的状态：数据库 schema、待处理工作、凭证引用、工具配置，或者解读它们所需的精确版本。

对于 AI Agent 来说，"我们有一份快照"不等于"有恢复计划"。恢复计划要回答的问题更窄：

我能否在干净环境中重建 Agent，证明正在进行的工作是什么，且无需丢失或重复外部副作用就继续？

这篇文章演示了一个小型恢复演练，适用于 OpenClaw 式常驻 Agent、编码 Agent worker，或任何在本地存储持久状态的服务。

1. 定义恢复边界

先写下什么必须存活。不要从备份工具入手。

这些都是相互独立的故障域。容器镜像备份不自动保留挂载卷。数据库备份不自动保留由另一个服务持有的投递回执。秘钥引用不证明恢复后的身份有权解析它。

2. 使用恢复清单

让备份自描述。清单应与备份存放在一起，而不是只存在于运维人员的记忆中。

{
  "backup_id": "agent-2026-08-19T090000Z",
  "image_digest": "sha256:replace-with-real-digest",
  "state_schema": 7,
  "state_snapshot": "state.sqlite",
  "workspace_commit": "replace-with-commit",
  "credential_refs": ["agent/runtime", "agent/outbound-webhook"],
  "last_event_id": "evt_0189",
  "delivery_cursor": "delivery_0042",
  "created_at": "2026-08-19T09:00:00Z"
}

上面的值是示例，不是真实凭证。在真实系统中，永远不要把 API key、cookie、浏览器 profile 或 bearer token 放入这个清单。存储引用关系，然后单独验证访问权限。

关键字段是游标。"最后事件"和"最后投递"不可互换。Agent 可能已在本地提交了任务结果，而出站通知仍处于待发送状态。

3. 恢复到空环境

如果复用了原始进程、文件系统或凭证，而没有证明边界，恢复演练就是无效的。

使用一次性环境，包含：

• 新容器或虚拟机
• 具有最小必需权限的新服务身份
• 复制的备份，先以只读方式挂载
• 出站投递指向测试接收端
• 网络访问仅限于演练所需的依赖

最小序列类似如下：

set -euo pipefail

export BACKUP_DIR=./restore-drill/agent-2026-08-19T090000Z
export RESTORE_DIR=$(mktemp -d)

cp "$BACKUP_DIR/manifest.json" "$RESTORE_DIR/"
cp "$BACKUP_DIR/state.sqlite" "$RESTORE_DIR/"

sqlite3 "$RESTORE_DIR/state.sqlite" 'PRAGMA integrity_check;'
# Start the exact recorded image with outbound delivery disabled.
# Run migrations in check-only mode before allowing the worker to start.

首次启动应尽可能只读或干运行。这 catch 住了一类危险的故障：恢复流程在操作员还未验证恢复的游标之前，就开始消费队列或发送消息。

4. 测试不变量，而非仅验证进程存活

健康端点通过说明不了什么。检查对应真实用户可见故障的不变量：

-- No task may be both completed and pending.
SELECT task_id
FROM task_attempts
GROUP BY task_id
HAVING SUM(status = 'completed') > 0
   AND SUM(status IN ('queued', 'running')) > 0;

-- Every delivery marked sent must have a durable provider receipt.
SELECT delivery_id
FROM deliveries
WHERE status = 'sent' AND provider_receipt IS NULL;

-- Every running task must have an owner and a lease timestamp.
SELECT task_id
FROM task_attempts
WHERE status = 'running'
  AND (worker_id IS NULL OR lease_until IS NULL);

如果这些查询返回行，测试应该大声失败。空结果是该检查的证据，不是整个恢复正确的证明。

然后注入一个已知测试任务并验证其完整生命周期：

• 恢复后的 worker 认领它一次
• 强制终止进程后留下可观察的中间状态
• 替换 worker 按策略恢复或重试
• 测试投递恰好一次到达接收端，或被明确标记为重复安全
• 在再次重启替换 worker 后最终状态可见

不要用真实客户通知或生产凭证做这个测试。

5. 分别测试崩溃点

至少在这些边界处练习：

• 任务已提交之后，投递尝试之前
• 投递请求已发送，provider 回执已存储之前
• 回执已存储，任务已标记完成之前
• schema 迁移期间
• 用新二进制恢复旧备份之后

第二个 case 是很多系统做错的。如果网络请求成功但进程在记录响应之前就挂了，盲目重试会导致副作用重复。安全的设计不是"多试几次"，而是幂等 key 或 provider 端去重合约，加上对尝试的持久记录。

6. 设置恢复验收清单

恢复演练应产生一份小型签名或追加只读报告，包含：

• 备份标识符和镜像 digest
• schema 迁移结果
• 状态完整性结果
• 凭证引用检查（不含秘钥值）
• 队列和投递游标对比
• 测试任务 ID 和投递回执
• 恢复到可用干运行 worker 的时间
• 未解决差异及负责人

如果报告无法回答 Agent 可能重复什么，演练就不完整。

对于需要持续运行的 Agent，当运维问题是把运行时及其持久状态放在一起时，在 Ampere 上托管的常驻 Agent 托管服务可能会有用。它不能消除定义凭证边界、测试恢复、或使出站操作幂等的需要。那些仍是应用职责。

行动项

• 选一个有真实持久状态存储的 Agent
• 写下它的恢复边界，记录镜像、schema、workspace、身份引用和投递游标
• 在出站投递禁用状态下恢复到空环境
• 在启动 worker 前运行完整性和不变量检查
• 注入一个无害测试任务，在两个不同崩溃点杀掉进程
• 把恢复报告随备份一起保存

备份只是一份拷贝。恢复是失败下已验证的行为。对于能改代码、调用工具或发消息的 Agent，这个区别是重启服务与安全恢复工作之间的差异。

你的恢复演练分别验证什么：执行状态、出站投递状态，还是两者都有？