很多团队都有类似经历：AI Agent 在精心准备的演示中流畅完成任务，一到真实用户手里就状况百出。这不是个别现象。Agent 需要连续做出多次正确决策，每一步的小概率错误会层层累积，任务链条越长，整体成功率下降得越快。理解常见的故障模式，是把 Agent 从演示推向生产的第一步。

七类常见故障模式

1. 误解任务目标

用户说“帮我整理一下上周的会议记录”，Agent 可能理解为总结内容、重新排版或者归档到某个文件夹。目标模糊时，Agent 往往按自己的猜测执行，而不是先确认。

2. 工具选择或参数错误

选错工具、漏传参数、参数格式不对，是最高频的错误。根源常常在于工具描述不够清晰，或者提供的工具太多、彼此相似，相关设计原则见 Function Calling 详解。

3. 陷入循环

Agent 反复执行同一操作：搜索没有结果就换个词再搜，一直搜下去；或者在两个方案之间来回修改。缺少终止条件和进展判断是主要原因。

4. 过早放弃或过早宣布完成

遇到一次报错就停止，或者只完成了一部分就报告“任务已完成”。后者尤其危险，因为用户可能直接相信结果。

5. 上下文丢失

长任务中，早期的重要约束被挤出上下文或在摘要中丢失，导致后续步骤违背用户最初的要求。记忆管理方法可参考 AI Agent 记忆设计。

6. 被外部内容带偏

Agent 读取的网页、文档或邮件中包含误导信息甚至恶意指令，导致它偏离原本任务。这是提示注入在 Agent 场景下的表现。

7. 环境变化未感知

网页改版、接口变更、权限过期，Agent 却仍按照旧的方式操作，并且不能正确识别错误原因。

系统化的排查方法

记录完整的执行轨迹

每一步的模型输入、思考过程（如果可见）、工具调用、工具返回结果和最终输出都要记录下来。没有轨迹日志，排查 Agent 问题几乎无从下手。

对失败进行归类

收集一批失败案例，按上述类型分类统计，找出占比最高的问题优先解决。很多时候，修好一两类问题就能显著提升整体成功率。

建立任务级评测集

为典型任务准备测试用例，包括正常情况和边界情况，并定义清楚“成功”的判定标准。每次修改提示词、工具或模型后都跑一遍，防止修了这个坏了那个，方法可参考如何构建评测集。

区分模型问题与工程问题

不少失败其实与模型能力无关：工具返回的错误信息不清晰、超时设置过短、返回数据格式混乱。先修工程问题，往往性价比更高。

提升可靠性的设计原则

  • 缩短任务链：能用确定性代码完成的步骤就不要交给模型决策；
  • 显式规划与检查：让 Agent 先输出计划，执行后对照计划检查完成情况；
  • 结果验证：完成后用独立步骤验证，比如检查文件是否真的生成、邮件草稿内容是否符合要求；
  • 优雅降级：无法完成时清楚说明卡在哪里、已完成哪些部分，而不是假装成功；
  • 人工兜底：对高风险或不确定的情况，主动请求用户确认。

小结

Agent 失败大多有迹可循：目标理解、工具使用、循环控制、上下文管理和外部干扰是主要来源。完整的轨迹日志、失败归类和任务级评测，是把 Agent 可靠性从“凭运气”变成“可改进”的关键。