AI Agent 如何处理中断与重试：从检查点、流式重连到技能级回退

本文采用的是基于所列资料的工作性理解，不是行业统一定义。本文关注的不是“Agent 会不会出错”，而是产品和研发团队该如何把中断、暂停、重试、回退、人工介入设计成一条可控的执行链路。

先把“中断”拆开：不是一种问题

在本文采用的工作性理解里，AI Agent 的“中断”至少可以分成三类：

1. 任务执行受阻：比如工具调用失败、外部系统返回异常、计划走不通。
2. 传输或会话中断：比如流式连接断开，但任务本身可能还在后台继续。
3. 上下文切换型中断：比如 Agent 需要额外知识、额外说明或更细的操作指令，必须临时加载新的能力模块。

这三类问题看起来都像“停住了”，但处理方法并不相同：

• 执行受阻，重点是判断当前步骤是否成功。
• 连接中断，重点是如何续上同一任务。
• 上下文切换，重点是如何只加载当前需要的知识与流程。

如果产品上不先做这层区分，后面的“重试”就很容易变成一句空话：出了问题就再试一次。但很多时候，真正需要的不是再次生成文本，而是重新取环境真值、切换替代路径，或者暂停并等待人类判断。

中断处理的核心，不是重试，而是先拿到“环境真值”

Anthropic 在对 Agent 的说明中提到，Agent 在执行过程中，需要在每一步从环境中获得“ground truth”，例如工具调用结果或代码执行结果，用来判断进度和状态[1]。

对研发来说，这意味着：

• 不能只看模型“觉得自己完成了什么”；
• 要看外部系统实际返回了什么；
• 每一步是否成功，更适合由程序化检查或外部结果来确认，而不是只靠模型自评。

Anthropic 还提到，在 prompt chaining 的工作流中，可以在中间步骤加入程序化检查，以确认流程是否仍在正确轨道上[1]。在这些资料的语境中，可以这样理解：

把重试放在“步骤”上，而不是放在“整段任务”上

如果一个 Agent 任务被拆成多个明确步骤，那么每一步都可以有自己的：

• 输入
• 输出
• 校验门
• 失败原因
• 可重试条件
• 升级条件

这样做的价值在于，系统不必在失败后把整条任务从头再跑一遍，而可以只在失败节点附近处理。

我们的建议是，把每一步都设计成一个小状态机，例如：

• pending
• running
• succeeded
• failed_retryable
• failed_non_retryable
• waiting_human
• fallback_running

这种设计通常比“Agent 自主执行中”更适合产品落地，因为它让中断和恢复都更可观察。

检查点是 Agent 可恢复性的关键结构

Anthropic 提到，Agent 在执行时可以在检查点暂停，等待人类反馈，或在遇到阻塞时返回给人类进一步信息或判断[1]。同时，也常见为任务设置停止条件，例如最大迭代次数，以保持控制[1]。

据此可以得到一个实用判断：

一个可运营的 Agent，通常应支持“暂停—确认—继续”

我们的建议是，把检查点分为三种：

1. 结果确认检查点

适合会影响外部世界的动作，例如：

• 是否提交内容
• 是否发送消息
• 是否覆盖原有数据
• 是否进入下一阶段自动化

2. 风险升级检查点

当出现下列情况时，未必适合继续自动重试：

• 同一步骤连续失败
• 返回结果和预期格式明显不符
• 外部工具返回了明确错误
• Agent 发现缺少必要信息

这时更合理的做法，可能是暂停并向用户或运营人员请求判断[1]。

3. 边界检查点

Anthropic 明确提到可以设置停止条件，例如最大迭代次数[1]。在产品里，可以考虑进一步扩展为：

• 最大步骤数
• 最大工具调用次数
• 最大等待时长
• 最大重试次数

这些配置不只是为了控成本，也是在错误状态下避免反复打转。

连接断了，不一定等于任务失败

Google Cloud 的 Gemini Deep Research 文档给了另一类中断的例子：研究任务可以用 background=True 和 stream=True 启动，API 会立即返回 interaction_id；如果要重新连接到流，需要这个 ID[2]。

基于这一点，可以提炼出一个对网站、工作台和企业应用都很实用的设计思路：

前端断流与后端任务可以考虑解耦

如果你的 Agent 产品支持：

• 长时间研究
• 多步骤生成
• 持续工具执行
• 流式返回中间进度

那么就不宜把“流式连接还在不在”当作任务是否存在的唯一依据。更稳妥的做法通常是：

• 后台任务有独立身份标识，例如 interaction_id[2]
• 客户端断开后，允许重新附着到同一任务上[2]

这和很多团队直觉里的“失败了就重新请求一次”不同。重新请求一次，往往意味着重新发起一次新执行；而“重连”保留的则更接近同一条任务上下文。对于 Deep Research、报告生成、代码修复、长流程审核这类场景，这种设计通常更稳定。

对外显示“进度”，本质上是在暴露可恢复状态

Google Cloud 文档提到，Deep Research 的流式传输可以实时接收研究进度更新，包括思路总结、文本输出和生成的图片[2]。从产品角度看，这不只是交互层面的增强。

它至少还有两个恢复层面的意义：

1. 让用户知道任务停在了哪里

一旦中断，用户更关心的通常不是底层异常，而是：

• 任务开始了吗？
• 已经做到哪一步了？
• 现在是卡住了，还是还在继续？
• 重新连接之后能否继续看到后续更新？

2. 让系统更容易组织恢复动作

如果系统把过程拆成了明确的阶段或事件，那么重连或恢复时，就不必只能采取“从头开始”这一种策略。

对于网站和控制台产品，我们的建议是把 Agent 的中断信息做成用户可理解的状态，例如：

• 已接收任务
• 正在检索资料
• 正在分析文档
• 正在生成结构化输出
• 等待人工确认
• 连接中断，可尝试重新连接
• 任务完成

这种状态建模，会直接影响你的“重试”到底只是工程补丁，还是产品能力。

回退不只是重复请求，也可以是替代路径

给定资料中，腾讯云文章把异常处理和恢复模式描述为：要预测潜在问题，并准备错误日志、重试机制、回退方案、优雅降级和通知机制；恢复机制还可包括状态回滚、诊断分析、自我纠正和问题升级[4]。文中示例还展示了一种顺序式回退：先尝试精确位置工具，失败后再从用户查询提取城市，转而使用更一般的区域信息工具[4]。

需要注意的是，这类材料更适合作为单一案例或工程观察来参考，而不宜直接当作通用行业共识。基于这类观察，本文的工作性理解是：

可用的回退设计，往往不只是“再试一次”

可以考虑把回退分成三层：

1. 同工具重试

适用于看起来像瞬时性问题的场景，例如超时、连接异常、临时不可用。

2. 换工具或换粒度

如果主路径拿不到精确结果，可以考虑退一步拿较粗结果。腾讯云示例中的“精确位置失败后改用一般区域信息”，就属于这种路径切换[4]。

3. 升级给人

当问题本质上需要判断、授权或补充信息时，继续自动重试往往意义有限。Anthropic 也提到，Agent 可以在阻塞时返回给人类获取进一步信息或判断，并在检查点暂停等待反馈[1]。

也就是说，在这些资料的语境中，回退设计的关键不一定是“永远自动化”，而是明确自动化能做到哪一层为止。

技能按需加载，也可以看作一种“上下文恢复”机制

很多中断并不来自 API 报错，而是来自 Agent 没有足够的操作知识，或者当前上下文太臃肿，导致执行质量下降。Agent Skills 的资料提供了另一种视角。

GitHub 上的 Agent Skills 规范说明：启动时，Agent 只加载每个 skill 的名称和描述；当任务匹配某个 skill 时，才读取完整的 SKILL.md 指令；执行时还可以按需运行附带代码或加载引用文件[3]。Claude API 文档也说明了类似的三级结构：元数据始终加载，SKILL.md 在触发时加载，额外资源和代码按需加载；这种渐进式披露是为了让只有相关内容占用上下文窗口[5]。

这对“中断与重试”的意义在于：

有些失败不是执行失败，而是知识装配失败

例如：

• Agent 知道要处理 PDF，但没有把相关 skill 真正载入上下文；
• Agent 已触发某个 skill，但还缺该 skill 引用的补充文件；
• Agent 的当前上下文过大，关键操作指令被稀释。

从这个角度看，恢复动作不一定是“重新调用模型”，也可能是：

• 重新匹配 skill
• 显式触发对应 SKILL.md
• 按需读取补充资源
• 缩小当前任务范围，只保留必要工作流

Claude 文档明确说明，Skill 被触发时，Claude 会通过文件系统读取 SKILL.md，若指令引用了其他文件，也会再读取这些文件[5]。因此，在这些资料的语境中，可以把“按需补上下文”理解为一种可操作的恢复方式，而不是笼统地增加系统提示。

一个实用判断：什么时候该重试，什么时候不该重试

基于以上资料，本文给出一个工作性判断框架。

适合重试的情况

可以考虑重试的前提，是失败更像一次执行噪声，而不是目标理解错误：

• 流式连接断开，但后台任务仍在，可基于任务标识重新连接[2]
• 工具调用返回瞬时异常，且步骤本身定义清晰
• 某一步骤有明确程序化校验，重试后能较快知道是否成功[1]

不适合直接重试的情况

以下情况更适合回退、暂停或人工介入：

• Agent 缺少必要输入信息[1]
• 当前路径已经多次失败
• 输出格式持续不符合校验门[1]
• 需要额外专业 workflow 或资源，应先加载相关 skill[3][5]
• 结果会对外部系统产生不可逆影响，应先过检查点[1]

从研发落地看，建议至少设计这五个部件

如果你在做网站后台、小程序助手、企业工作台或垂直数字化 Agent，我们的建议是至少补齐下面五类能力。

1. 步骤级状态机

不要只保存“任务成功/失败”，而要保存每一步的状态、输入、输出、错误原因和重试信息。

2. 校验门

Anthropic 提到可在中间步骤加入程序化检查[1]。这意味着关键步骤最好有独立 gate，例如：

• JSON 是否可解析
• 必填字段是否齐全
• 工具结果是否为空
• 代码是否执行成功

3. 检查点与停止条件

把“等待人类确认”“最大迭代次数”“最大重试次数”做成产品层的显式配置，而不是隐藏在 prompt 里[1]。

4. 可重连的任务标识

如果任务会持续较长时间，至少要有类似 interaction_id 的后端任务 ID，以支持断流后的重新连接[2]。

5. 预先设计的替代路径

不要只写一个 retry()。更稳妥的做法通常是为关键流程提前定义：

• 主路径
• 备选路径
• 降级输出
• 人工升级条件

这里的“替代路径”属于我们的建议，主要依据是前述资料中的工程观察与官方文档对检查点、重连和技能加载的描述[1][2][3][4][5]。

对产品经理的一个提醒：不要把“重试”设计成黑箱

很多 Agent 产品在中断后只给用户一个按钮：重试。这在短任务里也许够用，但在长流程里问题很大，因为用户不知道：

• 是从头重来，还是从失败步骤继续？
• 是重新推理，还是重新连接？
• 是重复调用外部工具，还是切换到替代路径？
• 是否需要自己补充信息？

我们的建议是，把可恢复动作拆开显示，例如：

• 重新连接进度
• 重试本步骤
• 改用备选方案
• 补充信息后继续
• 提交人工处理

这类设计不一定来自某一篇文档的明确规定，但与前述资料呈现出来的方向相符：Agent 的可靠性更依赖状态可见、边界明确、恢复路径清晰，而不是一句“模型会自我修复”。

结语

基于本文所列资料，我们对“AI Agent 如何处理中断与重试”的工作性理解是：

不要把中断理解成单一报错，也不要把重试理解成简单重复请求。

更实际的做法可以是：

• 用环境真值和程序化校验确认每一步是否真的成功[1]
• 用检查点和停止条件控制任务边界[1]
• 用任务 ID 支持断流后的重新连接[2]
• 用技能按需加载处理知识与上下文层面的“恢复”[3][5]
• 在合适场景下为关键流程准备替代路径，而不是无差别重试[4]

如果一个 Agent 产品能把这些能力做成显式结构，那么“中断”就不再只是失败现场，而可能变成一个可观测、可恢复、可运营的执行过程。