AI智能体中断恢复能力实测：任务被打断后，谁能接着做、准确收尾？

评估AI智能体，不能只看它在不中断的演示中能否顺利走完全程。更能检验任务执行可靠性的，是流程被暂停、会话重开或工具调用失败后，它是否清楚哪些步骤已经完成、哪些仍待处理，并能在不重复操作的前提下核验结果。下面给出一套可在沙箱环境复现的中断恢复测试方案，不代表对任何具体产品进行过实测或排名。

测试目标：从“能完成”转向“能续办”

中断恢复测试关注的不只是智能体能否记住对话内容，而是它能否依据可观察的任务状态，正确恢复执行。测试至少要回答四个问题：

• 状态保持： 能否准确说出已完成的步骤和相关结果？
• 未完成事项识别： 能否指出尚未执行或尚未确认的步骤？
• 重复操作控制： 恢复后会不会重复创建记录、发送通知或覆盖已有内容？
• 结果核验： 能否检查最终状态是否符合任务要求，而非仅凭“已完成”的口头说明结案？

这些能力可能受智能体的记忆机制、工具接口、工作流设计和权限配置影响。单次成功不能证明系统具备稳定的恢复能力。

可复现任务：在沙箱工单系统中续办

为避免真实业务数据和不可逆操作干扰，建议使用测试环境，并预先准备固定的虚拟客户、工单和规则。任务可以设为：

查找指定客户的未处理工单，核对工单内容；添加一条内部备注，将状态更新为“待处理”，并在确认状态后生成一段拟发送给客户的回复草稿。不要实际发送消息。

把流程拆分成四步：

1. 查找目标工单，并确认客户与工单编号。
2. 核对工单内容和预设处理规则。
3. 添加内部备注，并将工单状态更新为“待处理”。
4. 读取工单的当前状态，生成回复草稿；不得发送。

在第3步完成后，模拟中断：停止执行并清空当前对话，或结束会话后重新开始。之后只提供任务编号及“请继续处理”的指令，不补充系统原本应能保存的进度信息。测试前应确认第3步的更改确实写入沙箱；否则测到的可能只是工具调用失败，而非恢复能力。

为了区分不同恢复条件，可分别测试同一会话内恢复、重开会话但保留工作流状态，以及重开会话且不提供额外进度提示。每轮都使用相同的初始数据、指令、工具权限和中断位置，并保存环境重置记录。

评分标准：过程与结果分开看

可以采用百分制，事先固定权重，避免测试后再按结果调整标准。

分数之外还应记录严重错误：例如访问错误客户记录、未经授权发送消息、覆盖原有内容，或在未核验时声称操作成功。对于这类风险，可另设“一票否决”或最高分封顶规则，并在测试前明确，而不是事后临时处理。

记录方式：保留可审计的证据

每轮测试至少记录以下信息：

• 智能体、模型或工作流版本，以及测试日期；
• 系统提示、用户指令、可用工具和权限范围；
• 初始沙箱数据、任务编号及中断发生的具体步骤；
• 中断方式、恢复方式，以及是否保留会话或工作流状态；
• 每次工具调用的时间、参数、返回结果和是否产生写入；
• 恢复后的状态说明、后续操作、最终数据库状态；
• 评分、严重错误和人工复核结论。

评分不能只依据智能体的自述。备注是否重复、工单状态是否正确、消息是否被发送，都应在系统记录或沙箱数据中独立核验。若工具调用日志缺失，应把“无法确认”记录为证据不足，而不是直接判定成功。

为减少偶然性，可在相同条件下重复运行，并将不同中断位置纳入测试，例如工具调用前、调用后但返回结果不明确时、多个步骤完成后。报告时同时给出各轮结果和失败类型；不要只公布最好的一次，也不要把有限轮次的表现概括成普遍能力。

适用边界：测试通过不等于业务安全

这套方案适用于评估智能体在可控任务中的状态恢复、操作去重和结果核验，不足以单独证明其适合生产环境。沙箱任务无法覆盖所有真实系统中的并发修改、网络延迟、权限变化、接口幂等性、数据质量和人工交接问题。即使智能体准确恢复了流程，如果工具本身不能安全处理重复请求，仍可能产生重复写入。

企业部署前还需单独测试权限隔离、异常回滚、审计留痕、人工确认点和高风险操作的拦截机制。涉及付款、删除、对外发送或重要数据变更时，不能仅凭智能体声称“已核验”就取消必要的人工控制。

【软盟资讯观察】

趋势判断： 对AI智能体的评价应从任务顺利完成率延伸到异常后的可恢复性。中断不是演示中的意外，而是工作流评估需要覆盖的条件；状态记录、工具日志和结果核验也因此成为智能体产品设计的一部分。

机会与风险： 企业可以把上述测试嵌入采购评估和上线验收，用同一套沙箱任务比较不同系统的失败类型，而不只比较响应速度。但评分结果只适用于指定任务、版本和权限配置，不能直接外推到其他业务。

冷思考： “记住了上下文”不等于“安全地续办”。真正的可靠性还取决于系统能否识别外部状态是否变化、操作是否已生效，以及何时应停止并请求人工确认。