Demo 里表现完美，上线后十次有一次出错。这不是模型的问题，是工程的问题。

---

一、那个让人不安的数字

如果你问做过 Agent 开发的工程师一个问题："你的 Agent 在生产环境里的任务成功率是多少？"，大部分人沉默一会儿之后会告诉你一个数字：大概 85%-90%。

这意味着每 10 个用户里，就有 1 到 2 个遇到失败——可能是任务做到一半停了，可能是给了个看似正确但其实离谱的结果，也可能是悄悄进入了一个死循环在后台疯狂烧 Token。

更扎心的数据来自一项针对多 Agent 系统的研究：不做任何容错设计的情况下，失败率在 41% 到 87% 之间。也就是说，不做可靠性工程，你的多 Agent 系统基本是废的。

更扎心的是另一个数据：单次执行成功率 60% 的 Agent，如果需要连续成功执行 8 步，整体成功率会降到 25% 以下。每多一步，可靠性就指数级衰减。

二、Agent 到底会怎么"挂"

在传统软件里，故障通常是"非黑即白"的——要么报错了，要么没报错。但 Agent 的失败模式远比这复杂，很多时候它"没挂"但"做错了"。

大致有这么几类：

模型输出不合格

这是最常见的问题。你让模型返回一个 JSON 格式的执行计划，它返回了一段夹杂着解释性文字的半成品 JSON。或者你让它从四个选项里选一个，它选了一个不存在的第五个。

这类问题在 Demo 的时候很少出现（因为你用精心准备的输入测的），但在生产环境里，用户输入千奇百怪，模型的输出格式稳定性会明显下降。

工具调用出错

Agent 的核心能力是调用外部工具——查数据库、发请求、读文件。但它传给工具的参数可能是错的：日期格式不对、字段名拼写错误、查询条件超出有效范围。

工具本身通常不会因为参数错误而崩溃（返回空结果或错误码），但 Agent 拿到这些"没报错但也没用"的结果后，会继续基于错误信息推理，越走越偏。

死循环和发散

Agent 在执行过程中发现上一步的结果不满意，于是重试。重试之后还是不满意，再重试。有时候它会在两种策略之间反复横跳，永远达不到自己满意的结果。

这种情况在日志上的表现就是：Token 消耗疯狂飙升，但最终没有有效输出。

上下文漂移

在多轮对话或长链条任务中，Agent 的上下文窗口被大量历史信息填满。随着信息越来越多，Agent 对早期指令的遵循度会下降，开始偏离最初的目标。

这是一种非常隐蔽的失败——Agent 在做的事"看起来跟任务有关"，但实际上已经跑偏了。

三、核心策略：不要给 LLM 完全的自主权

所有做过生产级 Agent 的团队，最后都会得出同一个结论：最可靠的 Agent 架构不是让 LLM 自由发挥，而是用确定性的框架把它"框住"。

具体来说就是"确定性脚手架 + LLM 决策点"的混合架构：

• 整体工作流用状态机或 DAG（有向无环图）来管理：每一步做什么、做完之后走哪条分支、最多重试几次——这些都是确定性的，不交给 LLM 决定。

• 只在需要"理解"和"判断"的节点让 LLM 出场：比如理解用户意图、分析搜索结果的相关性、生成最终的自然语言回答。

• LLM 的输出必须经过验证才能往下走：而不是直接当成下一步的输入。

这种架构听起来"不够 AI"，但它是目前被验证过的最可靠的方案。纯 LLM 驱动的"全自主 Agent"在学术论文里很酷，在生产环境里非常脆弱。

四、五个必须落地的可靠性模式

1. 输出验证：分两层做

第一层：结构验证。 检查模型输出是否符合预期的格式——JSON Schema 校验、字段是否齐全、值的类型是否正确。这一层成本几乎为零，但能拦住大约 60% 的格式类错误。

第二层：语义验证。 用一个更小、更便宜的模型来判断主模型的输出是否合理。比如主模型生成了一份执行计划，用验证模型检查计划中的步骤是否逻辑自洽、是否遗漏了关键环节。成本会增加一些，但能显著提升可靠性。

2. 重试策略：区分错误类型

不是所有错误都值得重试。

• 暂时性错误（API 限流、网络超时）：用指数退避 + 随机抖动来重试，避免"惊群效应"。

• 确定性错误（格式不对、参数错误）：立即走降级路径，不要重试同样的 Prompt——因为同样的 Prompt 大概率会得到同样的错误结果。

• 内容策略拦截：不重试，直接走人工兜底。

一个实用的原则：如果同一种错误连续出现两次，就不要再重试了。转降级、转人工、或者用更简单的方式完成任务。

3. 熔断机制（Circuit Breaker）

从微服务架构借鉴过来的模式。当某个外部服务（比如某个模型供应商的 API）连续失败达到阈值时，"熔断"它——暂时停止向它发请求，过一段时间再"半开"探测是否恢复。

但要注意一个细节：只在基础设施层面的故障（502、503、504）上触发熔断，不在业务逻辑错误上触发。模型返回了一个不好的回答，是业务问题，不应该熔断；模型 API 返回 503 Service Unavailable，是基础设施问题，应该熔断。

4. 降级链

给每个关键能力准备 B 方案甚至 C 方案：

• GPT-4o 不可用？自动降级到 GPT-4o-mini

• GPT-4o-mini 也不行？降级到本地部署的小模型

• 模型全挂了？返回预设的兜底回答 + 通知人工介入

这件事的前提是你的调用层支持多模型路由和自动切换。如果你通过 poloapi.top 之类的统一 API 入口做模型调用，降级链可以在路由层配置，应用代码不用改。否则就得在每个应用里各写一套切换逻辑，维护成本很高。

5. 超时和预算上限

给每个 Agent 任务设两个硬限：

• 时间上限：一个任务最多执行多长时间。超过了就中断，返回"当前进度 + 无法在规定时间内完成"的结果。

• Token 预算：一个任务最多消耗多少 Token。超过了就强制结束。这能有效防止死循环和发散场景下的成本失控。

这两个限制听起来简单粗暴，但在实际生产中非常有效。没有上限的 Agent 就像没有信用额度的信用卡——早晚会出事。

五、一个实际的架构参考

把上面的模式组合起来，一个生产级 Agent 的执行流程大致是这样的：

用户请求进入
  → 意图识别（LLM 调用 + 结构验证）
    → 如果格式错误 → 重试一次 → 仍然失败 → 走兜底意图
  → 状态机选择执行路径（确定性）
  → 逐步执行（每一步都有）
    → 调用前：检查 Token 预算 + 检查时间上限
    → 调用中：设超时 + 熔断保护
    → 调用后：结构验证 + 语义验证
    → 验证失败：走降级路径
  → 生成最终结果（LLM 调用 + 内容安全检查）
  → 返回用户

这套流程比"直接把任务扔给 LLM 让它自己搞"要复杂不少，但可靠性从 60% 提升到 95% 以上的差距，全靠这些"不够酷"的工程手段。

六、最后一个忠告

如果你的 Agent 在 Demo 里跑得很漂亮，千万不要因此就觉得"直接上生产应该也行"。

Demo 环境和生产环境有三个根本差异：输入的多样性（Demo 用的是精心准备的输入，生产用户什么都可能输入）、运行时长（Demo 跑几分钟，生产跑几个月）、容错要求（Demo 失败了重来，生产失败了就是事故）。

Agent 的"智能"来自模型，但 Agent 的"可靠"来自工程。不做可靠性工程的 Agent，就是一个随时可能翻车的 Demo。