AI Agent 回滚计划：在用户失去信任前撤销错误操作
一个可靠的 AI agent 不需要完美无缺。它需要知道如何停止、解释错误并进行恢复。
如果你的 agent 更新了错误的 CRM 字段或发送了重复的付款，简单的重试无法修复造成的损害。在面临真正的事故之前，你需要一套回滚计划。
随着 agent 从聊天转向实际工作，它们现在会改变状态 (mutate state)。这使得回滚成为一项产品功能，而不仅仅是后端任务。
常见故障模式：
- agent 使用了错误的记录 ID。
- 重试导致动作重复执行两次。
- 模型切换改变了工具的工作方式。
- 工作流使用旧记忆恢复运行。
- 部分序列执行导致数据不一致。
如何构建恢复层：
使用操作账本 (Action Ledger) 不要依赖日志。创建一个记录每一次状态变更的账本。每一次工具调用在执行前后都必须创建一个条目。这是你进行恢复的唯一事实来源 (source of truth)。
对操作进行分类 并非所有操作都是相同的。
- 只读：无需回滚。
- 内部更新：从快照中恢复之前的值。
- 外部可逆：删除事件或更新状态。
- 外部不可逆：使用补偿机制而非真正的“撤销”。对于电子邮件或付款，你无法“撤回”已发送的内容。你必须发送更正信息或进行退款。
强制执行幂等性 (Idempotency) 模型不会强制执行幂等性，但你的工具运行时 (runtime) 必须做到。使用幂等键 (idempotency keys) 来确保如果 agent 重试任务，不会产生重复的副作用。
使用 Saga 模式 (Saga Pattern) 对于长流程工作流，每一个前向操作都需要一个补偿操作。
- 创建任务？补偿操作是删除或取消它。
- 更新字段？补偿操作是恢复旧值。
- 发送邮件？补偿操作是发送更正邮件。
实现检查点 (Checkpoints) 不要在崩溃后还要求模型去“弄清楚我们刚才进行到哪了”。使用检查点来存储当前状态、已完成的操作和待处理的任务。系统应当通过加载检查点来恢复工作。
构建恢复队列 (Recovery Queue) 当验证步骤失败时，将任务移至恢复队列。这允许你恢复、补偿或关闭任务。对于高风险错误，务必请求人工审批。
信任是通过可见的恢复过程建立起来的。当 agent 犯错时，不要使用含糊其辞的语言。准确地告诉用户发生了什么变化、为什么会发生，以及你是如何修复它的。
在第一次事故发生之前，构建好你的回滚计划。
Optional learning community: https://t.me/GyaanSetuAi