Agent 回退机制

文章目录

• • 一、什么时候触发回退
  • • 需要回退（逻辑/决策错误）
    • 不需要回退（只做原地重试）
  • 二、回退几步
  • 三、回退干什么
  • 四、怎么实现回退（工程落地步骤）
  • • [1. State 增加回溯字段](#1. State 增加回溯字段)
    • 2、快照保存时机
    • 3、为什么不能更新/覆盖旧快照
    • 4、回退怎么实现（完整流程）
    • 5、关键总结

一、什么时候触发回退

需要回退（逻辑/决策错误）

• LLM 工具参数生成错误
• 任务拆解不合理、顺序错乱
• 理解用户意图跑偏、答非所问
• 输出格式不合法（要求 JSON 乱输出）
• 幻觉严重、结论明显错误
• 分支路由选错、进错业务流程
• 工具返回结果逻辑矛盾、无效数据
• 用户明确否定结果，要求重新来

不需要回退（只做原地重试）

• 接口超时、网络波动
• 临时服务宕机
• 简单调用异常
  这类只原地重试，不回退流程节点。

二、回退几步

1. 回退 1 步（最常用）

   退到上一个决策节点，适合：参数错、选工具错、路由选错、格式错误。

2. 回退到指定关键节点

   不一步步退，直接跳回：

• 意图识别节点
• 任务拆解节点
• 流程分支入口节点
  适合：整体方向跑偏、任务走死胡同、完全理解错用户意图。

3. 步数限制
   全局最多允许回退 2～3 次，防止死循环；超过次数直接终止流程。

三、回退干什么

1. 回滚状态
   恢复上一步 State 快照，清空错误临时变量、脏数据。
2. 重新思考
   退回决策节点，让 LLM 重新理解、重新拆任务、重新生成参数。
3. 重新走流程
   用正确状态重新往下流转，抛弃错误路径。
4. 不破坏记忆
   只回退流程临时状态 ，不回退会话短期记忆、用户长期记忆，聊天上下文不丢失。

四、怎么实现回退（工程落地步骤）

1. State 增加回溯字段

在 LangGraph State 里固定加：

• step_history：每一步节点 + 状态快照列表
• current_step：当前步数
• revert_step：要回退到第几步
• retry_count：回退次数限制

1. 采用两个平行列表，下标一一对应

• node_path：记录走过的节点名称轨迹

• snapshot_list：记录每一步对应 State 快照轨迹

  node_path = [节点A, 节点B, 节点C]
  snapshot_list = [快照A, 快照B, 快照C]

2. 核心规则

• 两个列表严格同步追加
• 只末尾追加，不修改、不覆盖、不删除历史
• 历史快照一旦存入，永久封存

2、快照保存时机

只在刚进入新节点瞬间保存一次

1. 进入节点A → 追加节点A、追加快照A
2. 进入节点B → 追加节点B、追加快照B
3. 进入节点C → 追加节点C、追加快照C

正常流程往下执行时：

• 只修改当前业务 State
• 绝不改动 node_path、snapshot_list 历史数据

3、为什么不能更新/覆盖旧快照

如果正常流程里刷新、覆盖旧快照：

后续回退 2 步、3 步时，取出的已经不是当时原始状态 ，回退失效、逻辑错乱。

所以原则：历史快照只封存，不许覆写。

4、回退怎么实现（完整流程）

1. 节点执行出错/结果不合法
2. 根据想回退步数，从列表按下标 取目标：
   • 回退1步：取倒数第2个节点 + 对应快照
   • 回退2步：取倒数第3个节点 + 对应快照
3. 用历史原始快照覆盖当前 State
4. 截断 node_path 和 snapshot_list 到目标位置
5. 通过全局路由，跳转到目标节点重新执行

5、关键总结

1. 快照是列表结构，全程只追加不覆写
2. 进节点才存快照，正常流程不碰历史数据
3. 节点路径和快照列表下标一一绑定
4. 回退靠列表下标取历史快照，复原状态
5. 靠全局路由实现自动跳回目标节点，无需每个节点单独配置