面试官问「Agent执行多步任务时出现某一步失败的情况怎么办？」

如题，实话实说在我的开发中，回答很可能是“加上异常处理，设置最大重试次数，重试三次如果仍然失败就返回错误信息给用户。”

你就说有没有毛病吧……这个思路虽然是工程的基本功，但它却是传统软件的错误处理模式。把这个模式直接搬到Agent上，虽然解决了部分简单的失败，但远远不够。

零、为什么Agent的失败不同于传统软件？

传统软件的失败是显性的，通常表现为接口超时、参数校验不通过或数据库连接失败等，这些都会抛出明确的异常，让你清楚地知道问题在哪里。而Agent系统的失败则是隐性的，尤其是像基于大语言模型（LLM）的系统。例如，LLM可能返回了一个格式正确、没有报错的JSON，但它可能选错了工具、传错了参数，或者在多步任务的某一步产生了错误的推理。没有报错，系统也没有抛出异常，但任务的最终结果却是错误的。

可以将Agent的失败分为两类：

1. 显性失败：如工具调用超时或LLM输出无法解析的格式。
2. 隐性失败：如推理错误、陷入死循环或错误选择工具。

这两类失败的检测方法和恢复策略是截然不同的。

一、显性失败：如何避免盲目重试？

对于显性失败，单纯的重试通常是无效的。比如LLM返回错误的格式或工具调用失败，传统软件的解决方式可能是直接重试相同的请求，但Agent系统不一定能通过简单的重试解决问题。

LLM的错误往往是有规律的，如果它生成了一个错误的输出，下一次用相同的输入可能还会出错。正确的做法是将错误信息反馈给LLM，告知它你上一次输出的错误和解析错误。LLM能够理解这些错误，并进行自我纠正，这是Agent系统相较于传统软件最显著的不同。通过这种方式，Agent系统能够利用自然语言描述来调整自己的输出，从而实现更智能的错误恢复。

二、隐性失败：如何发现系统走偏？

隐性失败的检测和恢复相对复杂，因为它没有显性的错误信息。常见的隐性失败类型包括：

1. 死循环：Agent在反复调用同一个工具，或者在两个状态之间震荡。比如它查一次数据库没得到结果，就换个关键词继续查，但始终得不到期望结果，陷入死循环。
2. 方向偏离：Agent从第二步开始就走错了路径，后续的每一步看似合乎逻辑，但实际上是在解决一个错误的问题。
3. 上下文溢出：多步任务执行的历史信息积累过多，导致系统开始丢失关键信息，影响后续决策。

针对这些隐性失败，以下是几种常见的检测方法：

• 死循环检测：通过记录每一步的操作，检测是否有重复的、相似的行为。如果发现连续几步的工具调用和参数高度相似，就触发中断。
• 自我反思机制：定期让Agent回顾之前的执行历史，判断是否还符合原始目标。如果发现偏离了目标，就回滚到某个检查点，重新规划执行路径。
• 上下文管理：为了防止上下文溢出，应定期对执行历史进行摘要压缩，保留关键信息。必要时，通过设置检查点，避免从头开始，减少计算和资源浪费。

三、Agent恢复策略：如何避免从零开始？

传统软件的重试通常是无状态的，重新发一次请求就行。但对于Agent系统而言，每一步都依赖前一步的结果。

因此，如果任务的某一部分失败，重新开始从头计算将是极大的浪费。毕竟Token是真金白银啊~

正确的做法是在每个关键步骤保存检查点，记录当前的状态和已获取的中间结果。如果某个步骤失败，可以从最近的检查点开始，而不是从零开始。这样不仅可以节省资源，还能显著提高恢复效率，毕竟我是发现了，领导们真的不爱看进度条，就算我设计的很好看。

四、最后的兜底策略

其实啊其实，并不是所有的失败都值得恢复。

在某些情况下，恢复失败的成本甚至高于失败本身。例如，如果Agent重试了多次，每次都消耗大量资源，但结果依旧错误，继续重试可能并不值得。这时最理智的做法是快速失败，将已有的部分结果返回给用户，并明确指出哪些步骤没有完成。

如果任务完全走偏，无法恢复，则应触发人工介入。将执行历史和当前状态交给人工审核，尽可能避免系统继续无效运行。这样的方法其实是一种设计良好的降级策略，不代表系统失败，而是应对失败的一种理智选择。

五、我的回答：设计Agent系统的错误处理

对于Agent系统而言，失败恢复的策略需要分为显性和隐性两类：

1. 显性失败通过反馈错误信息给LLM让它自我修正；
2. 隐性失败则通过循环检测、自我反思和上下文管理来识别；
3. 恢复策略上，要使用检查点和回滚机制，避免从头开始，灵活调整路径；
4. 最后，设定硬性底线，如最大循环次数、最大token预算等，以确保在恢复代价过高时能够果断降级。

面试官想听到的不仅是你是否会加异常处理，而是你是否能意识到Agent系统中的错误处理是一个全新的领域。因为Agent系统能够理解语言，进行自我反思，并动态调整策略，这正是其核心优势所在，也是解决失败恢复时的关键特性。

当然当然，这套分层容错策略，主要适用于多步规划、自主工具调用的复杂Agent；

而针对单次执行、流程固定的轻量极简Agent，无需过度设计，传统的异常捕获+有限重试的基础方案，就足以满足稳定性要求，避免冗余损耗。