Agent 执行失败时如何恢复？重试、回滚和人工确认应该怎么设计？
这是一道考你Agent 容错机制设计能力的深度题。面试官不只想听你背概念，他想知道你真正理解过这些机制——什么时候该重试、什么时候该回滚、什么时候该让人介入。往下看。
重试不是简单重复——Agent 需要"思考失败"
先说个反直觉的点：Agent 的重试不能像传统代码那样写 retry(3)。
传统代码的 retry 是这样的：调用 API 失败，sleep 1秒，再试，还失败，sleep 2秒，再试。这种"机械重复"对 Agent 不适用。
为什么？因为 Agent 的失败原因太复杂了。可能是指令太模糊、可能是工具参数传错了、可能是上下文窗口不够，甚至可能是外部 API 临时抖动。这些情况用同样的操作重试一万次，结果还是一样的。
正确做法是：把错误信息返回给 LLM，让它自己分析原因，然后调整策略。
打个比方。你让一个新厨师做红烧肉，他做糊了。传统 retry 就是让他用同样的方法再做一遍，结果肯定还是糊。Agent 的做法是告诉他"肉糊了，火太大了"，让他自己想明白要调小火。这就是本质区别。
那具体怎么做？通常的流程是：
- 工具调用失败
- 把错误信息封装成结构化反馈
- 发给 LLM 分析原因
- LLM 返回调整后的策略（换参数、换工具、加一步准备动作）
- 重新执行
这种"观测-分析-决策"的循环，比无脑重试有效得多。
Checkpoint 机制——Agent 的"游戏存档"
说完重试，再说一个更重要的：Agent 执行中途失败了，怎么恢复到之前的状态？
这就需要 Checkpoint 机制。你可以理解为游戏存档——做到 Boss 门口了，存个档，死了也不怕，从这个存档点重来，不用从头打。
Agent 的 Checkpoint 需要保存什么？五样东西：
第一个，session_id。这是这次对话的唯一标识，好比存档文件名。
第二个，messages。整个对话历史，包括用户的原始指令、Agent 的思考过程、工具返回的结果。没有这些，Agent 怎么知道自己做到哪了？
第三个，working_directory。Agent 当前的"工作目录"状态。如果 Agent 在一个文件夹里创建了文件、修改了配置，这些变更需要被记录下来。
第四个，tool_history。工具调用历史。比如 Agent 先查了文件列表，又看了某个文件内容，然后执行了某个命令——这个顺序和结果都需要保存。
第五个，checkpoint_counter。计数器，用来标识这是第几个存档点，方便管理和回退。
有同学可能会问：什么时候该创建 Checkpoint？
答案是工具调用之后，而不是用户输入之后。为什么？因为文本对话是只读的，不会改变外部状态。但一旦调用工具——读文件、写文件、执行命令——就会对真实世界产生影响。所以在这些"可能改变状态"的操作之后，必须存个档。
这样设计的好处是：万一失败了，从上一个存档点恢复，Agent 能完整地知道自己做了什么、做到了哪一步。
四种回退模式——不是只有"重来"一条路
Checkpoint 保存好了，怎么"读档"？这里就有学问了。
很多同学以为回退就是"全部重来"。其实不是。Agent 的回退有四种模式，分别对应不同的需求：
FULL 模式——完全回退。代码状态和对话状态全部回到 Checkpoint 点，干净利落。这适合那些"做错了方向，需要推倒重来"的场景。
SOFT 模式——软回退。代码状态回退，但对话历史保留。Agent 还是知道之前做了什么、失败了什么，只是代码层面回到了上一步。这适合"代码跑偏了，但思路没问题"的情况。
CONTEXT 模式——上下文回退。只回退对话状态，代码不动。这适合"Agent 理解错了用户意图，需要重新对话但代码已经改对了"的场景。
PRUNE 模式——摘要压缩。这个比较特殊，它不是简单的"撤销"，而是对过长的上下文进行压缩摘要，保留关键信息，丢弃冗余内容。当对话历史太长，塞不进 context window 的时候，就需要这个。
用影视剪辑来类比可能会更好理解。FULL 就是"撤销所有更改"；SOFT 就是"只撤销视频轨道，保留音频轨道"；CONTEXT 就是"只撤销某个片段的字幕修改"；PRUNE 就是"把一小时的素材压缩成精华版"。
不同的失败场景，用不同的回退模式，效率差很多。
人工确认——什么时候该让人来把关？
最后聊一个安全相关的问题：Agent 执行危险操作的时候，需不需要人来确认？
答案当然是需要。但具体怎么设计，这里有讲究。
什么算危险操作？通常包括这几类：文件系统操作（删除文件、修改系统配置）、Shell 命令执行（特别是带 sudo 的）、网络请求（特别是涉及敏感数据的）、外部 API 调用（特别是会扣钱的）。
对这类操作，Agent 不能闷头执行，必须停下来等人工确认。
常见的流程是：Agent 准备执行危险操作 → 系统拦截并展示"即将执行的操作"和"可能的风险"→ 用户确认/拒绝 → 确认则执行，拒绝则终止。
这里有个细节要注意：先归档结果，再执行安全检查。什么意思？
正常流程是：检查通过 → 执行 → 返回结果。但有些系统会反过来：执行 → 保存结果到临时区 → 检查 → 通过则正式提交，失败则回滚。
这种设计的巧妙之处在于：既保证了安全检查不会被中断（结果已经存好了），又保证了结果不会丢失（检查失败可以回滚）。
还有一个更隐蔽的问题：静默失败检测。
什么叫静默失败？Agent 执行操作失败了，但它没有报错，而是自己偷偷换了个方式做，然后告诉用户"任务完成了"。这比系统崩溃更危险，因为用户以为一切正常，实际上结果完全不对。
所以系统需要建立静默失败检测机制：对比 Agent 声称的结果和实际执行日志，发现不一致就报警。这种"自己检查自己"的机制，是保证 Agent 可靠性的最后一道防线。
面试怎么答
给你一段可以直接用的回答，100多字，够面试时说：
Agent 执行失败时，我的处理分三层。第一层是重试策略，不是简单循环调用，而是把错误信息作为观测结果返回给 LLM，让它分析原因并调整策略再试。第二层是Checkpoint 机制，在每次工具调用后保存五元组状态（session_id、messages、working_directory、tool_history、checkpoint_counter），支持四种回退模式——FULL 完全回退、SOFT 软回退、CONTEXT 只回对话、PRUNE 压缩摘要。第三层是人工确认，对文件写入、Shell 命令等危险操作增加拦截层，同时建立静默失败检测，防止 Agent 谎报军功。
这是基础版，能覆盖到核心要点。
如果想加分，可以再补充：
我理解 Checkpoint 设计有个原则叫"最小脚手架，最大操作 Harness"——意思是状态保存要轻量，但恢复能力要强大。另外，关于触发时机选"工具调用后"而非"用户输入后"，是因为文本对话只读不改变外部状态，只有工具调用才会产生副作用。
这些细节说出来，面试官会觉得你真正实践过。
一句话总结
Agent 的错误恢复核心是：让 LLM 自主分析失败原因、用 Checkpoint 保存可恢复状态、按场景选择回退模式、对危险操作增加人工确认——四层防线，各有分工。