AI Agent 失败后怎么复盘：给数字员工设计错误处理闭环

在很多人的想象里，AI Agent 最理想的状态是“一次指令，全程自动完成”。但在万象片场的实际内容系统里，我越来越确信：真正可靠的数字员工，不是永远不失败，而是失败以后知道怎么交代、怎么修、怎么避免下次再犯。

自动化任务只要开始长期运行，就一定会遇到意外：网页加载慢了、登录状态失效了、接口限流了、图片地址失效了、构建警告变成错误了、部署成功但线上缓存没刷新。只要这些问题没有被记录和复盘，Agent 就会变成一个“偶尔很厉害、偶尔让人摸不着头脑”的黑箱。

这篇文章记录我给数字员工设计错误处理闭环的思路。目标不是把系统做得很复杂，而是让每一次失败都能变成下一次更稳定的材料。

一、失败不是异常，无法解释才是异常

很多自动化系统会把“成功”和“失败”看成两个简单状态：任务完成就是成功，命令报错就是失败。但真实工作里，状态往往更细。

以博客自动发布代理为例，它可能遇到这些情况：

• Markdown 写好了，但 frontmatter 字段不符合内容集合要求；
• 本地预览能打开，但首页排序没有出现新文章；
• 图片 URL 返回 200，却在浏览器里加载很慢或尺寸异常；
• npm run build 通过了，但部署命令需要重新认证；
• Cloudflare Pages 显示部署成功，但生产站点仍然读到旧缓存；
• Git 提交时发现仓库里有其他任务留下的未提交文件。

这些都不能简单归类成“失败了”。更准确的做法是让 Agent 说明：失败发生在哪一层、是否已经处理、是否需要人工介入、是否可以安全重试。

所以我给数字员工的第一条错误处理原则是：失败可以接受，无法解释的失败不可以接受。

二、把错误拆成五个层级

如果 Agent 只把所有问题都写成“执行失败”，后续就很难优化。更好的方式是给错误分层，让每一种问题都有对应处理策略。

1. 输入层错误

输入层错误通常来自任务前置条件不清楚，比如计划文件缺失、主题重复、必要素材不存在、用户授权边界不明确。

这类错误不应该硬做。正确处理是停止高风险动作，给出缺失项，并尽量提供安全替代方案。比如发现标题已经发布过，就不要换个近似标题继续写，而是重新读取文章列表，选择同一栏目下未覆盖的选题。

2. 生成层错误

生成层错误发生在内容或代码产出过程中，比如文章太空泛、品牌感缺失、结构不完整、脚本语法不合法。

这类问题适合自动修复。数字员工可以根据固定质量门槛自查：是否有清晰导语，是否有小标题，是否有可执行清单，是否自然体现万象片场，是否避免泛泛 AI 新闻。

3. 执行层错误

执行层错误来自命令、浏览器、API、网络和依赖环境。比如端口被占用、构建失败、部署超时、浏览器页面没有正常渲染。

这类错误要保留原始证据，但汇报时不必把所有终端输出都贴出来。对人最有用的是：哪条命令失败、关键错误是什么、已经尝试了哪种修复、当前是否可继续。

4. 验证层错误

验证层错误最容易被忽略。任务看似完成，但验证没有通过：文章页打不开、图片未加载、首页没出现、线上链接还是旧内容。

这类错误说明“执行完成”不等于“交付完成”。数字员工必须把验证当成正式步骤，而不是附加动作。没有通过验证，就不能直接报告已发布。

5. 资产层错误

资产层错误是长期风险，比如 Git 混入无关文件、同一主题重复发布、站点导航没有更新、文章没有沉淀到后续 SOP 或资源包。

这类错误短期不一定会让任务失败，但会慢慢损害内容资产库的质量。万象片场的博客不是一次性内容流，而是主资产库，所以资产层错误必须被记录。

三、错误处理闭环的最小流程

我会把数字员工的错误处理设计成一个很小的闭环：

发现异常
  ↓
定位层级
  ↓
判断风险
  ↓
尝试修复或停止
  ↓
重新验证
  ↓
写入复盘

这个流程看起来简单，但关键在于每一步都要有明确输出。

发现异常时，Agent 不能只说“出错了”，而要写出触发条件。定位层级时，要判断是输入、生成、执行、验证还是资产问题。判断风险时，要区分可以自动重试和必须停止等待授权的动作。尝试修复后，必须重新跑验证，而不是假设修好了。

最后一步“写入复盘”尤其重要。很多自动化任务失败后，只留下了一堆原始日志；下一次运行时，Agent 并没有吸收任何经验。真正的闭环应该把经验变成规则，比如：

• 如果生产站点短时间仍显示旧内容，下次验证自动加 cache-busting 参数；
• 如果图片加载不稳定，下次优先换更稳定的公开图源或本地化图片；
• 如果同类标题容易重复，下次选题前必须读取所有已有标题；
• 如果构建错误来自 Markdown frontmatter，下次写入前增加字段格式检查。

这才是数字员工逐步变可靠的方式。

四、哪些错误可以自动修，哪些必须停下来

不是所有错误都应该由 Agent 自动处理。一个成熟的数字员工要知道自己的权限边界。

我会把处理权限分成三类：

可以自动修复

• Markdown 格式问题；
• 标题和描述的小幅优化；
• 本地预览端口占用后更换端口；
• 构建前发现缺少必要字段并补齐；
• 线上验证遇到缓存延迟后使用带时间戳的 URL 复查。

这些动作风险较低，且属于任务本身范围内。

可以自动重试，但要记录

• 临时网络失败；
• Cloudflare Pages 部署短暂超时；
• 浏览器页面首次加载不完整；
• 图片远程响应较慢。

这类问题可以重试，但不能悄悄吞掉。因为如果连续多次发生，就说明流程需要优化。

必须停止或等待明确授权

• 删除线上资源；
• 修改账号资料、安全设置、支付设置；
• 覆盖已有域名服务；
• 在 Git 中提交明显无关的大量文件；
• 绕过登录、人机验证或平台风控限制。

数字员工不是权限越大越好。越是能操作真实资产，越需要清楚知道什么时候该停。

五、给 Agent 的失败复盘模板

为了让错误处理可执行，我会给每个数字员工准备一份固定复盘模板：

任务目标：
异常发生步骤：
错误层级：输入 / 生成 / 执行 / 验证 / 资产
关键证据：
已尝试处理：
当前结果：已恢复 / 已停止 / 需人工确认
是否影响线上资产：
下次改进规则：

这份模板不追求长，但要能回答三个问题：

1. 这次到底哪里出问题？
2. Agent 有没有在权限范围内正确处理？
3. 下次如何减少同类问题？

如果每次失败都能留下这样的记录，自动化系统就不再只是“跑任务”，而是在积累自己的操作经验。

六、从“会做事”到“会复盘”

万象片场接下来会继续把博客、小红书、公众号和素材生产流程串起来。任务越多，越不能只依赖“AI 很聪明”这件事。真正能长期运行的系统，需要的是清晰边界、稳定验证和可复盘的错误处理。

我的判断是：个人使用 AI Agent 的分水岭，不是能不能让它完成一次惊艳演示，而是能不能让它在连续 30 天的真实任务里，遇到问题不乱做、修复问题有证据、每次复盘都让系统变得更稳。

这也是我给万象片场数字员工的下一步要求：不仅要会写文章、会部署、会检查页面，还要在失败时像一个可靠同事一样，把原因、处理和下一步改进讲清楚。只有这样，AI 自动化才会从一次性工具，变成真正可以托付的内容生产基础设施。