搭过 Agent 的人都熟悉这种挫败：Demo 里跑得好好的，一到真实任务就各种翻车——绕着圈子不出结果、调错工具、把上一步的信息忘了、或者信心满满地交付一个错误答案。这时候最没用的结论是「这个 Agent 不行」，最有用的动作是定位到底是哪一环不行。
Agent 是「模型 + 工具 + 循环控制」拼起来的系统，失败可能发生在任何一环。这篇文章把 Agent 失败归成 8 类原因，按「任务定义 → 工具 → 上下文 → 循环控制」四个维度排开，每类给出判断信号和修法。下次 Agent 出问题，对照着排查，比盲目改提示词高效得多。
Agent 失败不是「它不行」，而是「某一环不行」——先定位环节，再对症下药。
维度一：任务定义没做好
1. 目标太模糊，没有验收标准
「帮我调研一下这个市场」——这种输入等于让模型自由发挥，它不知道要输出什么、查到什么程度算完成，于是要么草草了事，要么无限发散。判断信号：结果每次差别很大、深浅不一。修法：把目标写成可检查的要求——输出格式、必含要点、来源约束、完成标准。清晰的任务边界是 Agent 可靠的前提。
2. 一次给的任务太大太复杂
让 Agent 一步到位完成一个需要二十步、跨多个系统的大任务，它很容易在中途迷失。判断信号：长任务做到一半开始跑偏或卡住。修法：拆解——用规划-执行模式先让它列子任务，或者干脆你来拆，让它一次只干一段。
维度二：工具层出问题
3. 工具设计太泛或太乱
给 Agent 一个万能的 run_command，或者一堆命名含糊（doTask、process）的工具，它会选错、用错。判断信号：Agent 调用了不该调的工具，或参数填错。修法：工具接口要窄而明确——用 searchWeb(query)、readFile(path) 这种动词清晰、职责单一的工具定义，每个工具返回结构化结果。工具越具体，模型用得越准。
4. 工具太多，把模型淹没
挂了几十上百个工具，光工具描述就占掉大半上下文，模型在「能做很多事」里挑花了眼。判断信号：工具一多，选择准确率就下降。修法：按任务只挂需要的工具，或做「工具检索」——先按当前任务语义筛出最相关的几个工具再注入。
5. 工具返回没处理好
工具返回一整页 HTML、上万行日志，或者报错信息没喂回给模型，Agent 要么被垃圾信息淹没，要么不知道自己失败了。判断信号：Agent 基于残缺/过量信息做决策，或对工具失败无反应。修法：工具结果进上下文前先提炼要点；失败要返回清晰的错误信息让 Agent 能据此重试或换路。
一半以上的 Agent 失败能追溯到工具层：太泛、太多、或返回没处理好。
维度三：上下文与记忆
6. 上下文膨胀，把关键信息稀释或挤掉
长任务的历史越滚越长，要么撑爆窗口，要么把开头的关键约束淹没在中间——模型「忘了」最初的目标或限制。判断信号：长任务后期违反了早先明确的约束。修法：滚动摘要 + 结构化状态对象，把目标、约束、已完成、待办显式维护住，别指望模型从流水账里自己捞。这正是 Agent 记忆设计要解决的问题；也和长上下文的中间信息被忽略同源。
维度四：循环控制
7. 没有循环熔断，Agent 跑飞
没设最大步数和预算，Agent 陷入「搜索-没找到-再搜索」的死循环，跑几十步、烧掉一大笔 token 还不停。判断信号：任务不收敛，成本异常升高，反复调同一个工具。修法：设三重熔断——最大步数、token 预算、超时；检测到连续重复调用就中断，输出中间结果和「未完成原因」，而不是继续烧。
8. 没有验证环节，错误直接输出
Agent 做完就交付，没有自检，于是把幻觉、算错、没满足要求的结果当成答案给你。判断信号：结果看着完整，细究有硬伤。修法：加一步校验——尽量用外部信号（跑测试、核对来源、校验格式）而非纯自我感觉；代码类任务让它跑测试看报错，这是最硬的验证。校验不过就重来或标记待人工处理。
循环控制的两道底线：熔断防跑飞，验证防错误直接出门。
快速排查对照表
下次 Agent 出问题，从现象反查原因：
| 现象 | 优先怀疑 |
|---|---|
| 结果每次差别大、深浅不一 | 1 目标模糊 |
| 长任务中途跑偏 | 2 任务太大 / 6 上下文膨胀 |
| 调错工具、参数错 | 3 工具太泛 / 4 工具太多 |
| 基于错误信息决策 | 5 工具返回没处理 |
| 违反早先的约束 | 6 上下文膨胀 |
| 不收敛、成本飙升、反复调同一工具 | 7 缺熔断 |
| 结果完整但有硬伤 | 8 缺验证 |
这张表的前提是你有完整的执行日志——每一步的工具、参数、返回、模型决策都留痕。没有可观测性，排查 Agent 失败无从下手。所以在搭 Agent 时就要把日志和回放做进去，别等出了问题才想起。
适用人群与预防思路
适合正在调试 Agent、或准备把 Agent 推向生产的开发者。与其事后排查，不如事前预防——这 8 类原因反过来就是一份设计检查清单：目标写清晰、任务拆小、工具窄而少、返回要提炼、上下文有状态管理、循环有熔断、输出有验证、全程有日志。很多失败在设计阶段就能避免。
需要提醒：这 8 类是「功能性失败」。还有一类「安全性失败」——权限过宽被误用、提示注入被劫持、记忆被污染——性质更严重，单独讲在《AI Agent 为什么容易失控》。两类都要防。
常见问题
Q：这些问题换个更强的模型能解决吗？ A：部分能。更强的模型选工具更准、跑飞更少。但目标模糊、工具设计差、缺熔断缺验证是工程问题，与模型能力无关——再强的模型也架不住一个万能危险工具加没有熔断的循环。
Q：8 类里最该先查哪个？ A：先看日志确认是「没找对信息」还是「找对了但用错」。前者往工具（3/4/5）和任务定义（1/2）查，后者往上下文（6）和验证（8）查。有日志，一分钟就能分清大方向。
Q：Agent 老是重复调用同一个工具怎么办？ A：这是典型的跑飞前兆（原因 7）。加重复检测（连续 N 次相似调用即中断），并回头看是不是工具返回没给出有效信息（原因 5）导致它「以为没成功」而反复重试。
小结
Agent 失败不是玄学，8 类原因覆盖了绝大多数情况：任务定义（模糊、过大）、工具（太泛、太多、返回没处理）、上下文（膨胀稀释）、循环控制（缺熔断、缺验证）。排查的前提是有完整日志，方法是从现象反查环节。把这 8 类当成设计清单，很多失败在动手前就能避免。记住——定位到「具体哪一环」，才是解决 Agent 问题的开始。