面试官问“Agent执行多步任务时某一步失败了，怎么处理”怎么回答

面试官提问：“设计了一个Agent系统，在执行多步任务时某一步失败了，你会怎么处理？”

这个问题的一种回答思路诞生在大模型出现之前，就是典型的软件工程答案：加异常处理、设置最大重试次数，重试三次仍然失败就返回错误信息。

这个回答不能说错，确实是工程基本功。但问题在于这是传统软件系统的错误处理思路。如果把这一套原封不动搬到 Agent 系统里，其实只解决了最简单的一类问题。

面试官真正想考察的是：你有没有意识到，Agent 的失败和传统软件的失败根本不是同一种问题。（我的回答放在文末了）

本质区别：显性失败与隐性失败

在传统软件中，失败通常是显性的。

接口超时、参数校验失败、数据库连接异常，这些问题都会抛出明确的错误信息，所以咱扒拉一下log或者报错，系统能够捕获异常，也能清楚地知道失败发生在什么位置。

但在Agent系统里，大量的所谓失败却都是隐性的，就像是：

这些情况下，系统层面没有任何异常，接口正常、解析正常、流程也顺利执行，但最终任务结果是错的。从系统日志来看一切正常，但任务已经偏离目标。

因此，Agent的失败大致可分为两类：一类是系统级显性失败，另一类是语义级隐性失败，两类失败的检测方式和恢复策略完全不同。

很多人会习惯性地做“盲重试”，也就是把同一个请求再发一次，之前我在调用大模型的时候经常这样干，虽然很蠢，但有效果，说不定哪一次调用，它就真顺利跑起来了。

但在Agent系统中，这种方式往往效果很差。因为LLM虽然是非确定性的，但我们设计Agent的目的不就是为了解决这个随机性嘛，所以遇到的错误往往是有模式的，如果某次输出的JSON格式无法解析，用同样的prompt再试一次，很可能还是同样的问题。（这个我真的有话要说，给自己挖个坑，后面找机会唠唠）

更有效的方式是带着错误信息重试。把解析失败的原因反馈给 LLM：上一次的输出是什么、哪里解析失败、期望的格式是什么，然后让模型根据错误信息重新生成。

所以：这是Agent系统与传统软件最大的不同就是，你的“执行引擎”能够理解自然语言错误，并参与到自身的错误恢复过程中。LLM 本身具备一定的自我纠错能力，它能理解错误描述并调整输出。

相比显性失败，真正困难的是隐性失败的识别。因为系统没有报错，但他娘的Agent已经在错误的方向上越走越远。

Agent不断重复调用同一个工具，或在两个状态之间反复震荡。

例如查询数据库没有得到想要的结果，于是不断更换关键词重新查询，循环往复。

解法：记录每一步的action，如果连续多步调用的工具和参数高度相似，就触发中断机制。

Agent从早期步骤就误解了用户意图，导致整条执行链路都在解决一个错误的问题。

从局部看每步都自洽，但整体目标已经错了。

解法：引入自我反思机制。让Agent每执行几步就暂停一次，回顾执行历史，评估当前路径是否仍然符合最初目标。如果发现方向偏离，就回滚到某个检查点，重新规划执行路径。

多步任务执行时间越长，历史记录越多，容易把上下文窗口撑满。

此时模型开始丢失早期关键信息，后续决策质量明显下降，但系统层面依然没有任何报错。

解法：对执行历史进行摘要压缩。不是把所有历史对话都塞进上下文，而是定期将关键步骤总结成结构化摘要，既保留关键信息，也释放上下文空间。

传统软件中的重试通常是无状态的：同一个请求再发一次即可。但Agent的多步任务是有状态的流程，每一步都依赖前面的结果。如果第五步失败，却让系统从第一步重新执行，前四步的计算就全部浪费了，浪费的是token、延迟和成本。

在每一步记录当前状态、中间结果和已调用的工具。当某一步失败时，可以回滚到最近的有效检查点，从那里尝试不同路径，而不是从头再来。

游戏存档比喻：玩家失败后不会从第一关重打，而是从最近的存档继续。Agent 的检查点机制同理——记录关键节点状态，失败时从最近的有效节点恢复，避免重复计算已完成的工作。

并不是所有失败都值得恢复。有些任务继续重试的成本，可能已经超过任务本身的价值。

例如用户让 Agent 做竞品分析，系统成功获取了三个竞品的数据，但第四个数据源出现故障。如果继续卡在第四个数据源上反复重试，体验会非常糟糕。更好的策略是先返回已完成的三份分析结果，并明确说明第四个数据获取失败。再严重一些的情况，就应该触发人工介入，将执行历史和当前状态交给人工审核。