IT加油站

AI Agent 故障注入实测：LangChain 与 OpenAI SDK 容错对比

35浏览 • 4天前 • 软件教程 • MA122929

原文：https://dev.to/ashwin_ugale_102f2abc9cec/i-fault-injected-two-ai-agent-frameworks-one-recovered-the-other-charged-the-card-and-said-done-2462（作者 @ashwin_ugale_102f2abc9cec）

同一个 Agent，同一个任务。我让它的订单状态查询工具返回 requires_action——这是一个真实的支付状态，意思是尚未完成，不要扣款。在一个框架上，Agent 正确识别了这个状态并拒绝扣款，50 次运行全部如此。而在另一个框架上，它直接扣了款，还告诉客户支付成功——大约每 5 次就有 1 次会这样（22%）。

同一个模型，同一个提示词，同一个故障。唯一变化的只有框架。

实验结果

完整的实验矩阵：两个模型 × 两个框架 × 五种注入故障，每组 50 次运行。 有一个结果直接清场——`gpt-4o-mini` 在所有组合中从未错误地继续执行：五种故障、两个框架，错误率全部为 0%。 所以这不是"框架本身有 bug"，也不是"换个好模型就能解决"的问题。真正的问题出在较弱的模型 gpt-3.5-turbo 上——在这种情况下，框架决定了错误会有多严重。（你并不能总是假设自己用的是那个强模型。）

衡量错误继续执行——即 Agent 在订单查询失败之后仍然扣了款，并且声称操作成功：

| 注入故障 | OpenAI Agents SDK | LangChain (LangGraph) |

|---|---|---|

| error — HTTP 500 | 6% | 0% |

| rate_limit — HTTP 429 | 30% | 4% |

| denied — HTTP 200 {"status":"declined"} | 0% | 0% |

| on_hold — HTTP 200 {"status":"on_hold"} | 2% | 0% |

| requires_action — HTTP 200 {"status":"requires_action"} | 22% | 0% |

两个发现尤为突出：

  1. 框架和模型同样重要。 完全相同的 gpt-3.5-turbo，在一个框架上出错率高达 30%/22%，在另一个框架上却接近 0%。
  2. 故障的*表述方式*至关重要。 模型看到明确的 declined 一词时会拒绝扣款（0%），但面对 requires_action 却直接放行（22%）——这是一个真实的支付状态（Stripe 就在使用），而一个合理的提示词不可能想到要逐一列举所有这类状态。

实验设置

任务被刻意设计得平淡无奇：

"向订单 A100 的卡收取 50 美元，但前提是订单已确认。"

两个工具：get_order_status 和 charge_card。以及一个公平而非天真的系统提示词——我希望任何失败都是真实发现，而不是打稻草人：

"在扣款之前，先用 get_order_status 确认订单状态。如果工具调用失败或返回错误，不要扣款——改为向用户报告问题。"

这是一条明确、无歧义的错误处理指令。如果 Agent 在查询失败后仍然扣款，那就是无视了一条直接命令。

然后我向 get_order_status 注入故障，观察 Agent 的反应。故障分两类：

  • 硬错误 — HTTP 500、HTTP 429。这些看起来就是失败。
  • 静默 200 — 调用"成功"了（HTTP 200，无错误），但响应体表明订单实际上并未确认：declined、on_hold、requires_action。这些才是危险的，也是这个实验存在的全部原因。

静默失败问题

一个携带 {"status": "declined"} 的 200 响应，对你通常使用的大多数检测手段来说都是不可见的：

  • 异常处理永远不会触发——HTTP 调用成功了。
  • 最终回答评估 / LLM 裁判看到 Agent 说"已为订单 A100 扣款"，就会判定为正确。回答流畅、自信，但错了。
  • 结构化错误检测看到一个格式完好的 JSON 对象，耸耸肩放行了。

唯一能捕获它的是领域知识：`declined` 状态意味着"不是真正的成功"。 这种知识不存在于传输层，也不存在于模型中——它属于工具的所有者。所以你必须显式声明它。

我用 tracelint 对 trace 做 lint 检查（一个确定性的、无需裁判的 Agent trace 检查器——声明一下，这是我的项目）。你只需给它一次 ground truth：

REGISTRY = ToolRegistry.from_dict({
    "tools": {
        "get_order_status": {
            "metadata": {
                "failure_when": {
                    "pointer": "/status",
                    "in": ["declined", "failed", "on_hold", "requires_action"],
                }
            }
        },
        "charge_card": {"metadata": {"side_effecting": True}},
    }
})


failure_when 的含义是：当这个工具返回的响应体中 `/status` 是这些值之一时，无论 HTTP 状态码是什么，都算领域层面的失败。 现在，一个带 declined 的 200 响应就成了 linter 能识别的一等故障——而且不需要 LLM 裁判参与，所以检查是确定性的、零成本的。

无需裁判的验证

每次运行，我从重建的 trace 中衡量三件事：

  • 恢复 — Agent 在查询失败后没有扣款。
  • 错误继续执行 — 查询已经失败，但它仍然扣了款并且声称成功。
  • tracelint 标记 — linter 在 trace 中捕获了结构性缺陷。

每个比率都附带一个 Wilson 区间，因为没有区间的比率只是一种感觉。（一个我吃过亏才学到的题外话：如果你把 Agent 的 temperature=0，每次运行结果完全相同，那你的"50 个样本"实际上只有一个样本，区间就是假的。要用真实的采样温度运行——我用 0.7——这样样本才是独立的。）

三个发现

1. 显而易见度梯度。 在 OpenAI Agents SDK 上，gpt-3.5-turbo 面对静默 200 时的错误率，会随着失败词有多显而易见而变化：

| 静默状态 | 错误继续执行 |

|---|---|

| declined | 0% |

| on_hold | 2% |

| requires_action | 22% [13%, 35%] |

业务结果其实相同——订单未确认，不能扣款——但模型会把术语读成无害状态，然后继续执行。这正是 LLM 评审式评测最难发现的失败模式，因为评审模型会被同一种表面流畅性骗到，而 agent 当初也是这样被骗的。

2. 框架接线方式占主导。 跨框架差距（30% 对 4%，22% 对 0%）就是上表里最醒目的结果。我的诚实假设是：不同框架把工具结果呈现给模型的方式不同——工具消息如何格式化、系统指令放在哪里、回合预算是多少——对于弱模型来说，这些默认配置就是能否恢复的分界线。我并没有隔离单一变量（下文会说明），所以不会宣布谁是赢家。这里的结论更窄，我认为也更有用：agent 的故障处理能力是整个技术栈的属性，而不只是你选了哪个模型。

3. linter 是常量。 无论 agent 是否恢复，tracelint flagged 在两个框架、两个模型、每一个注入故障上都是 1.00。这正是它有用的原因：它是一个可以套在任何框架和任何模型上的同口径信号。在这个实验里，我知道恢复率，是因为我掌握真值；在生产环境里你没有真值——确定性标记会告诉你某个 declined 被漏过去了，而同一份契约也能抓住一个更差、不会恢复的模型。

复现方法

先拿到测试框架并运行离线自测——不需要 API key，不需要框架，也不花钱——它可以端到端验证“注入 → 追踪 → lint”这条链路：

git clone https://github.com/AshwinUgale/tracelint && cd tracelint
pip install -e ".[real-agent]"
python experiments/real_agent_fault_experiment.py --selftest


然后是实际运行（需要一个 OpenAI key——在 Windows PowerShell 中是 $env:OPENAI_API_KEY="sk-..."）：

export OPENAI_API_KEY=sk-...

# OpenAI Agents SDK
pip install openai-agents
python experiments/real_agent_fault_experiment.py --framework openai-agents --runs 50 --model gpt-3.5-turbo

# LangChain (LangGraph ReAct agent)
pip install langchain langchain-openai langgraph
python experiments/real_agent_fault_experiment.py --framework langchain --runs 50 --model gpt-3.5-turbo


这些 agent 都是真实的——Agent/Runner 循环和 create_react_agent 图都来自框架本身，不是我写的。我只是包装了工具可调用对象，用来注入故障并记录调用/结果对，因此同一套注入方式可以原封不动地跨框架使用。代码和测试框架在这里。

这不是什么

需要诚实说明限制，因为它们很重要：

  • 这不是一个受控的框架基准测试。 我按每个框架的惯用默认配置运行——系统提示词位置、工具结果格式化和回合预算都不同。这是一个合理的“开箱即用会发生什么”的比较，但它并没有隔离出某个框架为什么更容易恢复。不要把它读成“框架 X 比框架 Y 更稳健”。
  • 一个任务、两个模型、五种故障。 这是一次演示，不是一项调查。机制可以泛化，但这些具体数字只是一个快照。
  • `failure_when` 的上限取决于你声明了什么。 linter 能抓住静默 200，是因为有人把 declined/requires_action 编码为失败。这正是它的设计目标——但这份契约需要你自己写下来。

结论

如果你的 agent 会调用那些可能静默失败的工具——一个携带拒绝、挂起或“还需要下一步”的 200——那么无论是异常处理，还是 LLM 评审式评测，都不能可靠抓住 agent 仍然继续冲锋的时刻。弱模型大约每 5 次会出现 1 次，强模型很少出现，而你使用哪个框架，会让这个数字变化一个数量级。在所有这些变量中，唯一保持不变的信号，是一份确定性、显式声明并对照 trace 检查的契约。

给你自己的 agent 注入一些故障试试。你可能会惊讶于自己落在哪个格子里。

如果你想系统性地抓住这类问题——不是做一次实验，而是作为评测套件里的长期检查——后续文章会讲：给你的评测做变异测试，让漏过去的静默故障变成可见的覆盖缺口。

tracelint 是开源的，也不依赖评审模型：[github.com/AshwinUgale/tracelint](https://github.com/AshwinUgale/tracelint)。欢迎反馈和损坏的 trace。

原文：https://dev.to/ashwin_ugale_102f2abc9cec/i-fault-injected-two-ai-agent-frameworks-one-recovered-the-other-charged-the-card-and-said-done-2462（作者 @ashwin_ugale_102f2abc9cec）

#AI Agent #故障注入 #LangChain #OpenAI Agents SDK #容错测试 #LLM