AI Agent 回滚预案怎么设计：数字员工出错后如何安全撤回变更

很多人设计 AI Agent 时，只写“成功时应该做什么”，很少认真写“失败后怎么撤回来”。

但在万象片场的自动化博客流程里，我越来越觉得：一个数字员工是否可靠，不看它能不能连续跑 10 次成功，而要看它第 11 次出错时，会不会把现场越改越乱。

比如一个发布 Agent 可能会遇到这些情况：文章写完了，但构建失败；构建通过了，但部署失败；部署成功了，但线上页面标题错了；Git 提交前发现有无关文件；甚至更麻烦一点，Agent 把旧资源页链接改坏了。只要没有回滚预案，自动化就会从“省时间”变成“制造事故”。

这篇文章不是讲复杂的工程灾备，而是给个人博客、内容站、轻量工具站和本机自动化任务准备一套可复制的 AI Agent 回滚预案。

一、先定义：什么叫需要回滚？

回滚不是“只要有错误就全部撤销”。对个人自动化来说，更实用的判断是：

当当前变更已经影响线上可见结果、仓库一致性、数据真实性或后续任务判断时，就必须进入回滚流程。

我会把失败分成三类：

失败类型	是否需要回滚	例子
草稿阶段失败	通常不需要	文章还没写完，Markdown 格式不对
本地验证失败	视情况回滚	构建失败、图片链接错误、内链不存在
已发布后失败	优先准备回滚	线上页面错版、导航错链、部署了错误内容

这能避免两个极端：一是小错误就过度撤销，二是线上事故却只写一句“下次注意”。数字员工需要清楚：什么时候修复即可，什么时候必须先恢复稳定状态。

二、回滚预案的 5 个组成部分

一个可执行的 AI Agent 回滚预案，至少包含 5 块：

1. 变更边界：本次允许修改哪些文件、页面、配置和外部服务；
2. 前置快照：执行前记录 Git 状态、关键 URL、任务输入和预期产物；
3. 验证信号：什么结果代表正常，什么结果代表异常；
4. 回滚动作：异常发生后按什么顺序撤回；
5. 复盘记录：回滚后留下原因、影响范围和下一步修复建议。

我在设计发布类 Agent 时，会把这 5 块写进任务提示词，而不是事后临时让它“想办法处理”。因为出错时最怕的不是 Agent 不够聪明，而是它为了完成任务继续尝试，结果把状态变得更不可控。

三、变更边界：让 Agent 先知道不能碰什么

回滚的第一步，其实发生在执行前。

如果没有变更边界，Agent 就很难判断哪些东西可以撤、哪些东西不能撤。比如今天只允许新增一篇文章，它就不应该顺手改布局、改资源页、改构建脚本，更不应该把项目外的文件也带进提交。

我会要求数字员工在开始前写出类似这样的边界：

本次允许变更：
- src/content/posts/<new-post>.md

本次禁止变更：
- package.json / astro.config.mjs / src/layouts
- public 验证文件
- 其他项目目录
- 第三方账号资料、付款、删除、批量公开发布

如果任务确实需要改多个文件，也要提前列出来。边界越清楚，回滚越容易；边界越模糊，事故发生后越难判断“哪个修改才是问题源”。

这和《AI Agent 的权限分级》是同一件事：权限不是为了限制 Agent，而是为了让它在可控范围内稳定交付。

四、前置快照：执行前留下一个“恢复点”

个人项目里最简单、最有效的恢复点就是 Git 状态。

在万象片场的博客任务里，Agent 执行前必须先看：

git status --short

如果仓库不干净，它要先判断这些变更是不是本次任务的一部分。不是的话，不应该直接 git add .，更不能把无关修改一起提交。

除了 Git，我还会让 Agent 记录 3 个快照：

• 内容快照：今天准备新增或修改的标题、路径、目标 URL；
• 线上快照：首页、归档页、目标文章页部署前后的可见状态；
• 验证快照：构建结果、部署结果、浏览器检查结果、图片加载状态。

这些信息不是为了让日报好看，而是为了出错时能回答：问题发生在写作、构建、部署、缓存、路由，还是 Git 同步。

五、验证信号：不要只看命令退出码

很多自动化事故，都是因为 Agent 只检查了命令是否成功，却没有检查用户真正看到什么。

对博客发布来说，我会把验证信号分成四层：

Markdown/frontmatter 可解析
→ npm run build 通过
→ npm run deploy 成功
→ 线上首页/归档/文章页真实可见

其中最后一层必须用浏览器或至少浏览器式请求确认。因为 Cloudflare、缓存、路由、图片 CDN 都可能让“部署成功”和“用户可见”之间出现差距。

如果验证失败，回滚预案要明确下一步：

• 构建失败：不部署，修 Markdown/frontmatter/内链；
• 部署失败：保留本地文件但不提交，记录错误；
• 线上页面错误：先判断是否缓存，如果不是缓存，再修复并重新部署；
• Git 异常：停止提交，先查看 diff 和 status；
• 外部服务异常：不要扩大权限，不要尝试危险操作。

这也是《AI Agent 每日验收清单模板》里强调“证据”的原因：没有验证信号，Agent 很容易把失败包装成完成。

六、回滚动作：从低风险到高风险排序

回滚动作要按风险排序，而不是一上来就删除文件或重置仓库。

我常用的顺序是：

1. 暂停后续动作：先停止部署、提交、推送、外部发布；
2. 保存错误现场：记录报错、URL、文件路径、命令输出摘要；
3. 局部修复：如果只是 frontmatter、链接、图片或错字，优先修复后重新验证；
4. 撤销本次文件变更：如果方向错了或影响范围不明，再撤回新增文件或补丁；
5. 恢复到上一个稳定提交：只有在确认线上或仓库状态混乱时，才考虑更强回滚；
6. 人工交接：涉及账号、DNS、付款、删除、权限、登录验证时，必须停下来交给人。

给 Agent 的提示词里可以写成：

如果任一验证步骤失败：
- 不得继续 deploy/git push/外部发布；
- 先报告失败阶段和影响范围；
- 只允许在本次变更文件内修复；
- 如果需要修改配置、删除远端资源或更改第三方账号状态，停止并交接。

这条规则看起来保守，但它能避免数字员工在“补救”时制造更大的问题。

七、一个内容发布 Agent 的回滚模板

下面是一份可以直接放进定时任务里的简化模板：

# AI Agent 回滚预案

## 执行前
- 读取任务计划和已有内容，避免重复。
- 运行 git status --short，确认仓库状态。
- 列出本次允许修改的文件和禁止修改的范围。

## 执行中
- 每完成一个阶段记录产物：写作、预览、构建、部署、线上验证、Git。
- 任何阶段失败，不进入下一阶段。
- 只在本次允许范围内修复问题。

## 验证失败时
- 构建失败：不部署，修复 Markdown/frontmatter/链接后重跑。
- 部署失败：不提交，记录 wrangler 错误和本地构建状态。
- 线上验证失败：检查缓存和具体 URL；必要时重新部署；仍失败则停止。
- Git 状态异常：不 add .，先输出 status 和 diff 摘要。

## 回滚后
- 说明撤回了哪些文件或动作。
- 说明仍保留哪些本地变更。
- 给出下一次任务应该先检查的风险点。

这份模板的目标不是让 Agent “永远不出错”，而是让它出错后不扩大损失。

八、我的默认原则：先恢复稳定，再追求自动化

越是想让 AI Agent 像数字员工一样长期值班，越不能只奖励它“多做事”。真正的可靠性来自三件事：知道边界、留下证据、能安全撤回。

在个人内容系统早期，最好的自动化不是全自动冲到底，而是：

• 低风险动作自动做；
• 中风险动作先验证再继续；
• 高风险动作自动停下来交接；
• 每次失败都沉淀成下一版 SOP。

万象片场后续会继续把这些真实流程拆成可复制的数字员工 SOP。下一步，我会把“回滚预案”接到定时任务、验收清单和周报复盘里，让每个 Agent 不只是会执行，也能在出错时把系统带回稳定状态。