AI Agent 异常分级怎么做：哪些错误自动重试，哪些必须停下来交给人

很多人搭 AI Agent 的时候，最先设计的是“它要做什么”：写文章、查资料、部署网站、整理文件、生成日报、检查数据。

但万象片场在把博客自动发布变成每日数字员工任务以后，我发现更关键的问题其实是：它出错时应该怎么办？

如果没有异常分级，Agent 很容易出现两种极端：一种是遇到一点小问题就停止，导致自动化价值很低；另一种是明明已经进入高风险状态，还继续硬跑，最后把错误扩大成线上事故、无关提交，甚至权限风险。

所以今天这篇文章记录一个可复制的异常分级方法：把 AI Agent 的错误拆成“可自动重试、可降级处理、必须人工交接、必须立即停止”四类。数字员工真正可靠，不是因为它永远不出错，而是因为它知道什么错误能自己处理，什么错误不能逞强。

一、为什么 Agent 不能只写成功路径

大多数自动化提示词都很喜欢写成功路径：

读取计划 → 写 Markdown → 本地预览 → 构建 → 部署 → 验证线上 → Git 提交

这条链路看起来完整，但真实运行时几乎每天都有不确定性：

• 文件已存在，主题可能重复；
• 图片 URL 可写入，但浏览器里可能加载失败；
• 本地 dev server 端口被占用；
• npm run build 因一个 Markdown frontmatter 错误失败；
• Cloudflare Pages 部署命令可能遇到网络或认证问题；
• 线上页面可能被缓存，首页一时看不到新文章；
• Git 工作区可能存在别的任务留下的改动。

如果 Agent 的规则里只有“继续下一步”，它就会把异常当成噪音；如果只有“失败就停”，它又会把小波动也交给人。

更好的做法是：在 SOP 里提前定义异常等级，让它像一个受过训练的员工一样判断。

二、四级异常分级：从自动重试到立即停止

我现在会把 AI Agent 的异常分成四级。

1. L1：可自动重试的小波动

这类问题通常不改变任务本身，也不会带来额外风险，只是执行环境短暂不稳定。

例子：

• 页面第一次打开超时；
• 图片检测第一次返回未加载完成；
• dev server 启动后还没完全 ready；
• 部署后的生产页面需要几十秒刷新；
• API 请求偶发 502 / 503。

处理规则很简单：允许自动重试，但必须有次数上限和间隔。

L1 处理：等待 10-30 秒 → 重试 1-3 次 → 成功则继续 → 仍失败则升级为 L2 或 L3

这里的关键是“上限”。没有上限的重试不是可靠自动化，而是把问题藏进循环里。

2. L2：可降级处理的非核心问题

L2 异常会影响体验或证据完整性，但不一定阻止主任务完成。

例子：

• 首页缓存没立刻出现新文章，但具体文章 URL 可访问；
• 原定浏览器视觉检查失败，但 HTML 与图片加载检查正常；
• 某个非关键统计接口不可用，但不影响文章发布；
• 线上 sitemap 刷新慢，但文章页面已经 200。

处理方式不是假装没问题，而是降级完成，并在报告里写清楚：主交付已完成，哪个辅助检查需要后续观察。

例如博客发布任务可以这样判断：如果文章页、标题、正文、图片、build、deploy、Git 都正常，只是首页缓存短暂滞后，可以先记录“首页缓存待刷新”，再用具体文章链接作为主要验证证据。

3. L3：必须人工交接的决策问题

L3 异常不是技术失败，而是 Agent 没有资格替人做决定。

例子：

• Cloudflare 或 GitHub 要求重新登录授权；
• 需要改账号名称、头像、简介；
• 需要删除线上内容、覆盖已有站点或修改 DNS 指向；
• 需要对外群发、私信、投流、付款；
• 发现当前主题可能与已有文章高度重复，需要决定是否合并。

这类问题不能靠“再试一次”解决。正确动作是停止相关高风险步骤，保留已完成的低风险产物，并交接给人。

交接信息至少包括：发生在哪一步、系统要求什么、Agent 已经做了什么、下一步需要人确认什么。

4. L4：必须立即停止的安全问题

L4 是红线。只要触发，就不能继续执行。

例子：

• 需要输出、保存或提交密钥、Cookie、Token；
• Git diff 里出现 .env、密钥、账号凭证；
• 命令将删除大量文件或覆盖不相关项目；
• 目标目录与任务要求不一致；
• 检测到要操作被明确禁止的项目；
• 自动化准备执行不可逆的付费、删除或权限变更。

L4 的原则是：不要补救，不要绕过，不要“我觉得没事”。立即停止，报告风险，等待人类处理。

三、把异常分级写进数字员工 SOP

异常分级不能只存在脑子里，必须写进任务提示词或 SOP。

我会在万象片场的数字员工任务里加入类似这段规则：

异常处理规则：
- L1：网络、加载、缓存等短暂波动，最多重试 3 次，并记录重试结果。
- L2：非核心检查失败但主交付可验证，允许降级完成，但必须在报告中注明。
- L3：涉及登录、授权、账号身份、对外发布、删除、付费、DNS/域名替换，停止该动作并交接。
- L4：涉及密钥泄露、错误目录、禁止项目、不可逆破坏性命令，立即停止整个任务。

这段话看似简单，但能显著降低 Agent “自作主张”的概率。

尤其是长期定时任务，越应该把边界写死。因为定时任务运行时用户通常不在现场，Agent 不能靠临时追问来化解风险，只能依靠预先定义好的边界。

四、每次异常都要留下证据

异常分级还有一个容易被忽略的部分：证据。

如果 Agent 只说“部署失败”或“页面异常”，第二天很难接着处理。更好的异常记录应该包含五个字段：

字段	说明
时间	什么时候发生
步骤	写作、预览、构建、部署、线上验证还是 Git
等级	L1 / L2 / L3 / L4
证据	命令输出、页面 URL、错误信息、截图或检查结果
下一步	自动重试、降级完成、人工确认、立即停止

例如：

09:18，线上首页验证，L2：文章页已 200，但首页缓存未出现新卡片。已用文章 URL 完成主验证，建议 10 分钟后复查首页。

这样的记录比“有点问题但应该没事”可靠得多。

五、一个博客发布任务的实际判断模板

以一篇自动发布博客为例，我会这样判断：

• 主题重复：如果只是相近但角度不同，继续；如果标题和核心结构高度重复，升级 L3，避免重复发布；
• 图片失败：换一张稳定公开图或降级为无图前先检查站点 schema；如果 schema 要求 heroImage，就必须修复后再 build；
• build 失败：L2 或 L3，先修复 Markdown/frontmatter；不能部署失败构建；
• deploy 失败：网络波动可按 L1 重试；认证/权限问题升级 L3；
• 线上缓存：文章页正常但首页延迟，可按 L2 降级并记录；
• Git 有无关改动：停止提交，只 add 本次文件；如果无法判断来源，升级 L3；
• 发现密钥文件：L4，立即停止，不提交。

这套判断让 Agent 不只是“会发文章”，而是能像运营同事一样理解风险边界。

六、下一步：把异常分级变成可复用模板

对万象片场来说，AI 自动化的目标不是炫技，而是把一个人的内容生产变成长期可靠的系统。数字员工每天能多做一点事很重要，但更重要的是：它在不确定环境里仍然可控。

我建议每个准备使用 AI Agent 的人，都先给自己的任务写一张异常分级表，而不是一上来追求全自动。

最小版本只需要四行：

1. 哪些问题可以自动重试；
2. 哪些问题可以降级完成；
3. 哪些问题必须交给人确认；
4. 哪些问题一出现就立即停止。

下一篇我会继续拆数字员工的交接机制：当一个 Agent 做完任务以后，怎样把“今天发生了什么、明天该接着做什么”交给下一个任务，而不是每天从零开始。