什么是失败补偿？做一半怎么收场

AI 智能体执行长任务时，最尴尬的处境是做到一半失败：资料检索完了、草稿写了一半、文件改了三处，然后第某步报错停住。这时系统里已经留下了半成品和副作用，放着不管就是垃圾现场。失败补偿就是一套「收场」机制：把已做的动作退回去或抵消掉，让系统回到干净状态。

类比网购退款：货发出去了订单取消不了，商家就走退款流程把交易抵消掉。退款不是让订单没发生过，而是用一笔反向操作把后果对冲掉。

做到一半断了怎么办

失败补偿要处理两类遗留。一类是产物遗留：半成品文件、临时记录、已经写入的中间数据，收场时要标记作废或清理。另一类是外部副作用：已发送的通知、已创建的记录，这类最难办，只能靠反向操作或联系接收方作废。

所以设计任务时要把动作分成两档：可重来的（生成、计算、检索）失败了直接丢弃重做；不可逆的（发送、创建、提交）必须放到最后一步，前面全验证通过再执行。把不可逆动作往后放，是最便宜的补偿策略。

补偿的两种路子：退回与冲正

退回式补偿：把每个已完成的步骤按相反顺序撤销，像退台阶一样退回起点。要求每一步的「反操作」都可执行：删了临时文件、还原了被改的内容。冲正式补偿：不撤销原操作，而是执行一笔抵消操作，比如已发的通知补发一条更正说明。

两种路子常常混用：内部产物用退回，外部副作用用冲正。海螺AI、讯飞星火这类助手执行多步任务时，通常只在前端展示进度，真正要做补偿的系统，收场逻辑都要自己显式设计。

收场方式不止一种，按情形挑：

收场动作要在开工前想好

补偿最容易犯的错是「出事后才想怎么收场」。正确的做法是开工前就为每个不可逆动作写好两件事：它的反操作是什么、它的补偿触发条件是什么。任务状态也要清晰标注——进行中、已失败待补偿、已补偿——避免崩溃重启后分不清哪些动作做没做。

补偿本身也会失败，所以要留兜底：补偿重试几次仍不成功，就把它转成人工待办，附上当时的执行记录，别让系统在原地无限转圈。

类比哪里失效：机器不怕尴尬

人做错事要顾及面子，收场常拖泥带水；机器补偿干脆利落，只要反操作定义清楚，退回就是一条命令的事。所以补偿设计的难点不在技术，在于事前有没有把每一步的「怎么退」想清楚。

失效的还有「时间倒流」：现实里泼出去的水收不回，系统里只要动作设计得当，大部分状态都能还原——前提是可逆性从一开始就是设计目标。

退场前的一句忠告

看一个智能体系统靠不靠谱，别只看它成功时多流畅，要看它失败时能不能干净退场。失败后留下一堆半成品的系统，成功次数再多也难托付重任。

失败补偿三原则

• 不可逆动作尽量后置，前面能验证的全验证
• 每个副作用动作预埋反操作，产物可退、外部可冲正
• 状态标注到步骤级，补偿失败转人工兜底

画一张任务流程图，给每个箭头标注「失败时怎么办」，没标出来的就是隐患。

相关词条：补偿依赖重复执行的安全底座，见什么是幂等设计？重复执行不出乱；收场后流程怎么改，参考什么是工作流的版本化？流程改动可控；任务怎么拆才好补偿，见任务规划是怎么生成的？先列提纲；动作执行的完整链路，看工具调用是怎么发出去的？从决策到执行。

换个问法再问失败补偿三句

• 补偿和重试有什么区别？：重试是原地再试一次，适合临时性故障；补偿是放弃重来、收拾残局，适合确定失败或重试多次仍不通的场景。
• 所有任务都需要补偿设计吗？：只读任务不需要，失败重跑即可；只要任务会写文件、发通知、建记录，补偿就值得预埋。
• 补偿由谁触发？：通常由任务执行器在捕获失败后触发，也可以由定时巡检发现「卡在半路」的任务后触发，两条路都要有。