失败模式:Agent 为何崩溃

失败模式:Agent 为何崩溃

本节摘要:团队交付的 Agent 在 90% 的轨迹上工作正常,但那 10% 的失败不是随机噪声——它们落入少数几个反复出现的类别。一旦你能命名它们,就能监控、就能修。MASFT(Berkeley,arXiv:2503.13657,多智能体系统失效分类)把 14 种失效模式聚成 3 大类,标注者间 Cohen's Kappa 0.88(类别可靠可区分);其核心主张是——失效是多智能体系统的根本设计缺陷,而非靠更好的基座模型就能修的 LLM 局限。微软的 Agentic AI 失效分类白皮书指出:既有的 AI 失效(偏差、幻觉、数据泄漏)在智能体场景下被放大,而自主性还带来新失效(规模化下的非预期动作、工具误用、任务漂移)。《LLM Agent 幻觉调研》(arXiv:2509.18970)给出两种主要表现:指令遵从偏离(不跟系统提示走)、长程上下文误用(忘了早轮约束),以及三类子意图错误(遗漏、冗余、乱序)。Arize、Galileo、NimbleBrain 在 2024-2026 的现场分析趋同出五种行业复发模式:幻觉动作(调不存在的工具或捏造参数)、范围蔓延(超出用户请求,多建 PR、多发邮件)、级联错误(一个错调用引发下游连锁,一个幽灵 SKU 幻觉触发四次 API 调用变成多系统事故)、上下文丢失(长程任务忘了早轮约束)、工具误用(对工具但参数错,或干脆用错工具)。其中级联是杀手——Agent 分不清「我失败了」与「任务不可能」,常在 400 错误上幻觉出一条成功消息来「闭环」。本节吃透这套分类,并用标准库实现一个给轨迹打失效标签的检测器。读完本节,你应能用「每步验证门」防御,并避免「只标崩溃、无基线、过度告警」三种监控陷阱。

对应原课程:Phase 14 · Lesson 26 · failure-modes-agentic(原英文 phases/14-agent-engineering/26-failure-modes-agentic/docs/en.md)。前置:第 05 节(Self-Refine 与 CRITIC)、第 24 节(可观测性)。

学习目标

阅读完本节,你应当能够:

1. 说出 MASFT 的三大失效类别,以及每类至少四种具体模式。
2. 解释为何智能体场景会放大既有 AI 失效(偏差、幻觉)。
3. 描述五种行业复发模式及其缓解。
4. 解释为什么级联错误是其中最致命的。
5. 用标准库实现一个给 Agent 轨迹打失效模式标签的检测器。
6. 识别三种监控陷阱:只标崩溃、无基线、过度告警。

一、问题与直觉

一个在生产里跑的 Agent,90% 的轨迹看起来正常。但剩下的 10%——它们不是「随机坏掉」,而是系统性地落入少数几个模式。这些模式的可怕之处在于:它们大多产出看起来合法的输出——不崩溃、不报错,只是悄悄地错了。所以只盯崩溃日志的人,根本看不见真正的失败。

MASFT(Berkeley,arXiv:2503.13657)

多智能体系统失效分类。14 种失效模式聚成 3 大类。标注者间 Cohen's Kappa 0.88——类别可靠可区分(不同标注者几乎总把它们归到同一类)。

核心主张:失效是多智能体系统的根本设计缺陷,而非靠更好的基座模型就能修的 LLM 局限。这对你意味着——等「下一个更强的模型」救不了你,得在架构层防。

微软:Agentic AI 失效分类白皮书

• 既有的 AI 失效(偏差、幻觉、数据泄漏)在智能体场景下被放大——因为 Agent 会把一个错传播到多个系统。
• 自主性带来新失效:规模化下的非预期动作、工具误用、任务漂移(mission drift)。
• 这份白皮书是智能体产品的风险登记册。

《刻画智能体 AI 故障》(arXiv:2603.06847)

• 失效源自编排、内部状态演化、环境交互。
• 不是简单的「坏代码」或「坏模型输出」——而是这三者的交互。

《LLM Agent 幻觉调研》(arXiv:2509.18970)

两种主要表现:

1. 指令遵从偏离(Instruction-following Deviation) —— Agent 不跟系统提示走。
2. 长程上下文误用(Long-range Contextual Misuse) —— Agent 忘了或误用早轮的上下文。

子意图错误(计划执行层的 bug):遗漏(漏步骤)、冗余(重复步骤)、乱序(步骤顺序错)。

五种行业复发模式

Arize、Galileo、NimbleBrain 在 2024-2026 的现场分析趋同:

1. 幻觉动作(Hallucinated actions) —— Agent 调一个不存在的工具,或捏造参数。
2. 范围蔓延(Scope creep) —— Agent 把任务扩到用户请求之外(多建 PR、多发邮件)。
3. 级联错误(Cascading errors) —— 一次错调用触发下游连锁。一个幽灵 SKU 幻觉触发四次 API 调用——一场多系统事故。
4. 上下文丢失(Context loss) —— 长程任务忘了早轮约束。
5. 工具误用(Tool misuse) —— 调对的工具但参数错,或干脆调错工具。

级联是杀手。Agent 分不清「我失败了」与「任务不可能」,常在 400 错误上幻觉出一条成功消息来「闭环」——这是第 06 节「400 要变观察字符串」没做对时的灾难性后果。

缓解:每步验证门

在推理链的每一步设自动验证门,把事实锚定查环境状态。具体:

• 每步安全分类器(第 21 节)。
• 工具调用参数校验(第 06 节)。
• 把检索内容与已知事实交叉核对(第 05 节 CRITIC)。
• 用重新探查状态来检测成功幻觉(文件真的建了吗?)。

⚠️ 三种监控陷阱:① 只标崩溃——大多数 Agent 失效产出看起来合法的输出;需要内容级检查。② 无基线——漂移检测需要「上次已知良好」;没有它,你说不出「这变糟了」。③ 过度告警——每次失败都发 page;应聚类 + 限流。

二、从零实现

原课程 code/main.py 实现一个标准库失效模式打标器:

• 一个合成轨迹数据集,覆盖五种模式。
• 每种模式的检测函数(基于工具调用、输出、重复动作的签名模式)。
• 一个打标器,给每条轨迹打标签并报告模式分布。

Step 1:五种模式的检测签名

def hallucinated_action(trace):
    return any(c.tool not in REGISTRY for c in trace.calls)   # 调不存在的工具

def scope_creep(trace):
    return count_side_effects(trace) > trace.expected_actions  # 超 user 预期

def cascading_error(trace):
    # 第一个失败后,后续 N 步都基于错误状态
    first_fail = next(i for i,c in enumerate(trace.calls) if c.error)
    return sum(1 for c in trace.calls[first_fail:] if c.based_on_prior_error)

def context_loss(trace):
    early = trace.constraints[:3]
    return any(c not in trace.late_turn_context for c in early)

def tool_misuse(trace):
    return any(c.args_invalid or c.wrong_tool for c in trace.calls)

def success_hallucination(trace):
    return trace.final_status == "success" and not target_state_changed(trace)
​

Step 2:打标器 + 分布

DETECTORS = {"hallucinated_action": hallucinated_action,
             "scope_creep": scope_creep, "cascading_error": cascading_error,
             "context_loss": context_loss, "tool_misuse": tool_misuse,
             "success_hallucination": success_hallucination}

def tag(trace):
    return [name for name, fn in DETECTORS.items() if fn(trace)]

def distribution(traces):
    return Counter(t for tr in traces for t in tag(tr))
​

运行 python3 code/main.py 会输出每条轨迹的标签 + 聚合分布——一份 Phoenix 追踪聚类所揭示东西的廉价复现。

💡 设计要点:级联错误之所以致命,是因为 Agent 没有「我失败了」的概念——它只有「闭环」的目标。当一个工具返回 400,Agent 倾向于把它当成「待解决的问题」而非「失败」,于是基于错误状态继续走,最后幻觉一条成功消息闭环。解法是第 06 节的纪律:错误必须是结构化观察,且验证门要在每一步查真实状态——文件建了吗、订单下了吗,而不是听 Agent 说「成功了」。

三、框架对比

四、可复用产物

原课程 outputs/skill-failure-detector.md:生成针对你领域的失效模式检测器,接到一个追踪存储,含每模式的签名模板与 CI 阈值(如某模式占比≥5% 即 fail build)。

五、练习

1. (Easy) 加一个「成功幻觉」检测器:Agent 返回 success 但目标状态未变。
2. (Medium) 给你建过的产品的 100 条真实轨迹打标。哪种模式主导?修它的成本多大?
3. (Medium) 实现「级联半径」指标:给定第 N 步失败,它影响了多少个下游步?
4. (Hard) 读 MASFT 的 14 种失效模式。挑三种适用于你产品的,写检测器。
5. (Hard) 把一个检测器接进 CI job:若 ≥5% 轨迹打了某模式标签,fail build。

本节要点回顾

1. 10% 失效非随机:落入少数复发类别;大多产出看起来合法的输出,只盯崩溃看不见。
2. MASFT:14 模式聚 3 类,Kappa 0.88 可靠区分;主张是设计缺陷而非模型局限——等更强模型救不了。
3. 微软白皮书:既有 AI 失效(偏差/幻觉/泄漏)被放大,自主性带来新失效(规模化非预期动作/工具误用/任务漂移)。
4. 故障三源:编排、内部状态演化、环境交互——非简单坏代码或坏输出。
5. 幻觉两种表现:指令遵从偏离、长程上下文误用;子意图错误:遗漏/冗余/乱序。
6. 五种行业复发:幻觉动作、范围蔓延、级联错误、上下文丢失、工具误用。
7. 级联是杀手:Agent 分不清「我失败」与「任务不可能」,400 上幻觉成功消息闭环。
8. 每步验证门防御:每步安全分类器、参数校验、CRITIC 交叉核对、重探查状态查成功幻觉。
9. 成功幻觉检测:重探查真实状态(文件建了吗),而非听 Agent 说成功。
10. 三种监控陷阱:只标崩溃(要内容级检查)、无基线(没法说变糟)、过度告警(聚类+限流)。

下一节,我们深入 Agent 安全的头号威胁——提示注入与间接提示注入(PVE),以及为什么对检索到的内容「零信任」是 2026 年所有生产 Agent 的底线。