在构建 LLM Agent（智能体）的过程中，我们往往沉迷于提示词工程、工具调用和复杂的工作流设计，却刻意回避了一个尴尬的事实：Agent 是极其脆弱的。
它不像传统软件那样遵循“输入-处理-输出”的确定性逻辑，而是充满了不确定性。当 Agent 失败时，如果只是简单地报错退出，用户体验将是一场灾难。

本文将从显性和隐性两个维度深度剖析 Agent 的失败模式，并提供一套工程化的恢复解决方案。

---

一、冰山之上：显性失败

显性失败是指系统能明确感知到的异常。这类失败通常伴随着错误日志、异常抛出或状态码。这是最容易发现和处理的一类问题，但如果处理不当，也是最打断用户心流的。

1. 常见场景

• 工具执行错误：Agent 试图调用一个不存在的 API、Python 脚本报错、或者权限不足无法写入文件。
• 格式解析失败：LLM 返回的 JSON 格式损坏，导致 json.loads() 抛出异常。
• 资源限制触发：触发了 Token 限制，或者达到了最大迭代次数（如 max_iterations=20）。
• 外部服务不可用：LLM Provider 返回 500 错误或网络超时。

2. 恢复策略：自愈与重试

对于显性失败，核心策略是**“将错误转化为反馈”**。

策略 A：错误自愈循环

不要在工具抛出异常时直接停止，而是将异常信息回填给 LLM，让它尝试修复。

代码逻辑示例：

try:
    result = tool.execute(arguments)
except Exception as e:
    # 不直接抛出错误，而是构造一个错误反馈消息
    result = f"Tool execution failed. Error: {str(e)}. Please check your parameters or try an alternative approach."
finally:
    # 无论成功失败，都将结果送回 LLM 上下文
    context.add_tool_result(result)

策略 B：分级降级

当主模型（如 GPT-4o）失败时，自动降级到更稳定的轻量模型（如 Haiku）进行重试；或者当外部搜索工具失败时，自动切换到本地知识库检索。

---

二、冰山之下：隐性失败

隐性失败是指系统判定任务“成功完成”，但实际上偏离了用户目标。这类失败极其危险，因为它不会抛出异常，Agent 会自信地给出一个错误的结果，甚至陷入死循环而不自知。

1. 常见场景

• 逻辑死循环：Agent 在两个工具之间反复横跳（如：搜索 -> 打开网页 -> 搜索 -> 打开网页…），直到耗尽 Token。
• 目标漂移：用户问“帮我订一张去北京的票”，Agent 却开始“分析北京的旅游攻略”，完全忘记了订票任务。
• 幻觉与无效操作：Agent 声称“已经发送邮件”，但实际上调用的邮件工具只是打印了一行日志；或者修改了错误的配置文件。
• 上下文丢失：在长对话中，Agent “忘记”了最初设定的约束条件（如“预算不超过 500 元”）。

2. 恢复策略：监控与干预

隐性失败无法通过简单的 try-catch 解决，需要引入监督机制。

策略 A：死循环检测

记录最近 N 次的工具调用序列。如果检测到重复的模式（如连续 3 次调用同一工具且参数相似），强制中断并引导 Agent 换个思路。

# 简易死循环检测逻辑
history = ["search", "read", "search", "read", "search"]
if len(history) >= 5 and len(set(history[-5:])) <= 2:
    inject_prompt = "You seem to be stuck in a loop. Please try a completely different approach or ask the user for clarification."

策略 B：Validator Agent（验证者模式）

引入第二个轻量级 LLM 作为“裁判”，专门负责验证结果是否符合用户意图。

---

三、终极方案：构建“检查点-回滚”机制

借鉴数据库和游戏设计中的概念，Agent 系统应当具备时间回溯的能力。当无法恢复时，允许用户或系统回退到上一个健康状态。

解决方案架构图

1. 状态快照

定期保存 Agent 的状态快照。这不仅包含消息历史，还应包含：

• 当前工作目录的文件状态。
• 已加载的工具集。
• 关键的中间变量。
  当 Agent 陷入死胡同，用户可以使用 /rollback 命令回到上一步，就像玩游戏存档读档一样。

2. 人类介入

当所有自动恢复手段失效时，最优雅的方案是承认无能并请求支援。

• 方案：Agent 暂停执行，将当前的“思维链”、“已尝试的工具”、“失败原因”整理成报告发送给用户。
• 交互：用户可以直接修改 Agent 的参数、补充信息，或者手动执行一步操作后，让 Agent 继续。

3. 记忆分离

通过 nanobot 源码中的 MEMORY.md 机制，将任务状态与长期记忆分离。

• 短期失败：只需清空当前 Session 的上下文，重新开始任务，不影响已经沉淀的知识。
• 长期污染：如果 Agent 错误地更新了长期记忆（如记住了错误的用户偏好），需要提供“遗忘机制”或版本控制来回滚记忆文件。

---

四、总结

构建一个健壮的 Agent 系统，10% 的代码在处理“Happy Path”（成功路径），而剩下 90% 的代码都在处理“Unhappy Path”（失败路径）。

失败类型	特征	核心解法	关键技术
显性失败	系统报错、崩溃	错误反馈、自愈重试	Try-Catch、Error Reflection、Retry Policy
隐性失败	结果错误、死循环	过程监控、结果验证	Validator Agent、Loop Detection、Human-in-the-loop

只有当我们不再害怕 Agent 的失败，而是为其设计好完善的“复活甲”和“回血机制”时，Agent 才能真正从“玩具”走向“生产工具”。