为什么出色的 AI 智能体在生产环境中会出现故障：缺失的基础架构层

早上 6 点，第一条警报弹了出来。紧接着是第二条，第三条。

值班工程师打开笔记本电脑，发现同一个 AI 智能体接连出现 3 个互不相关的故障。这个智能体负责处理支持工单、办理计费调整，并回答客户问题。它基于 LangChain 运行。它在预演环境中通过了所有测试，而且一直正常运行，突然就崩了。

我见过不少团队，花费数月时间钻研提示词工程、选择模型，结果却要耗费一个周末来处理与这两者毫无关联的故障。以下这些故障并非凭空假设。当智能体第一次进入生产环境时，如果没有配套的基础架构来提供支撑，就会发生这种情况。至今，我还没有见过哪个框架自带这种基础架构：即生产部署所需的身份边界、安全执行和运维治理。

43 个重复的支持工单

这个智能体是一个可以推理目标、选择工具并自主执行多步骤操作的 AI 系统，当时正在监控支持队列。客户提交了问题。智能体调用工单 API 来创建记录，API 接受请求并创建工单。但随后响应超时。

在智能体看来，这次调用失败了。在工具调用失败时，LangChain 采取了所有设计完善的框架都会采取的措施：重试。第一次重试，又创建了一个工单，响应再次超时。继续重试，又多了一个工单。

到早上 6 点，系统中共有 43 个重复工单。对于每个工单，系统都会自动发送确认电子邮件，这意味着客户的收件箱中有 43 封邮件。支持团队整个上午都在手动关闭重复工单，发送致歉信息，而不是处理本职工作。

我想把问题根源讲清楚，这点至关重要。LangChain 的处理逻辑没问题。框架检测到响应失败，执行重试，这正是重试逻辑的设计初衷。问题不在于重试，而在于基础架构中没有任何机制来跟踪原始请求是否成功。这里没有幂等封装（一种机制，可确保重复请求与原始请求产生相同的结果，从而防止重复数据）。没有重复数据删除层。平台层面也无法识别，这是对已完成操作的重复重试。

认真算过这笔账的任何决策者都清楚：这次事故的代价不仅仅是一个令人尴尬的上午。支持人员利用工作时间进行事后处理，机械化的重复电子邮件削弱了客户的信任，在人工逐条核查所有待处理工单前，整套系统都不可信。对于开发人员而言，重试逻辑的代码本身没问题。漏洞藏在代码之下的基础架构层面。

框架本身尽职尽责，可配套的基础架构根本不存在。

其他账户被误扣 4,000 美元

基础架构层面的漏洞有些动静很大（就像前面的 43 个工单），但有些却悄无声息。还是这个 AI 智能体，它同时负责计费调整。它可以访问计费 API，该 API 在部署期间通过服务账户完成置备。此服务账户可以访问多个计费账户，因为这是让智能体在开发环境中顺利运行的最快方式。在将智能体推向生产环境之前，没有设定凭据范围，因为根本没有构建身份边界，这个基础架构层会根据经过验证的身份（而不仅仅是配置）来控制给定工作负载可以访问哪些资源。

智能体本应从 A 账户扣款，提示词中也提供了账户标识符。但模型选择了 B 账户，对于任何大语言模型（LLM）来说，这都是一种合乎情理的错误。计费 API 接受了调用，并向其他客户误扣了 4,000 美元。

这并不是模型本身出现了故障。大语言模型的输出往往看起来合乎情理，但有时也会出错。这次问题可能的原因是相同的计费 API 使用了错误的账户参数，这可能是选择错误。

在传统软件中，API 调用路由错误的潜在影响受到 2 层限制：凭据范围会限制工作负载可以访问的服务，下游 API 强制执行哪些参数对给定调用方有效。开发人员绝不会发布这样的 Web 应用：仅凭一组凭据就能写入每个客户的账单记录，但这里恰恰发生了这种情况。

智能体被授予范围足够广泛的凭据，可以访问系统中的任何账户，而且技术栈中没有任何机制（无论是平台还是下游 API）对这一范围进行限制。目前没有框架附带凭据范围，也不提供加密工作负载身份，更无法根据基础架构级策略（而不是提示词内容）来限制智能体可以访问哪些服务。

直到下周一，有人核对账单，这件事才被发现。我在不同规模的项目里见过同类事故，只是细节各不相同，但根源始终是一致的：智能体获得了本不该拥有的凭据，且技术栈中没有任何机制强制执行边界。

公司从未制定过的退款政策

边界未被强制执行造成了那次 4,000 美元扣款的事故，但第三次故障造成的损失更难量化。一位客户向智能体询问所购商品的退货期限。模型给出了肯定、清晰的回复：退款政策支持 90 天内退货。根据公司政策，真实退货期限是 30 天。智能体的回复清晰明确，很有帮助，但却是完全错误的。

LangChain 将模型的输出传递到面向客户的回复通道。同样，框架完全做到了它该做的事情，将模型的输出路由到链路的下一环节。推理边界处缺少护栏，即模型输出进入真实业务世界的节点（无论是发送给客户、写入数据库还是用于触发操作）。没有验证层将输出与有文档记录的政策进行对比。在回复送达客户之前，没有任何机制检查智能体的回复是否与已知事实相矛盾。模型输出一路直达客户，中间没有任何环节。

这位客户在下单后的第 47 天退回了价值 280 美元的商品，依据是智能体给出的回复。团队最终只能同意退货。这次事故的代价不仅仅是退款本身，还有法律风险：AI 智能体在未经授权的情况下向客户做出了具备合约效力的承诺，而该公司没有审计跟踪可以证明采取了控制措施来防止这种情况发生。

扣款事故有明确金额，重复工单有具体数量。但向客户输出捏造的政策，这种问题带来的损失更难量化，也更难管控。这是一种会不断累积的风险，智能体在未经验证的情况下发送的每一条回复都可能是您的法务团队从未批准的另一项潜在合同承诺。企业只要运行着可直接与客户对话的智能体，就面临着这个风险，但其中大多数企业对此毫不知情。

智能体本身没问题

在开发过程中表现出色的智能体一夜之间出现 3 次故障。

我们来看一下规律。在每次事故中，框架都能正常运行。LangChain 负责编排工具调用，路由输出，并在失败时重试。智能体循环（推理、规划、工具调用、编排）按照设计正常运行。

每一次故障的根源都是缺少生产基础架构。对于第一个故障，需要平台层面的幂等机制和重复数据删除。对于第二个故障，需要具有凭据范围和加密工作负载身份的身份边界。对于第三个故障，需要在推理边界处设置护栏，即在将回复发送给客户之前，根据有文档记录的事实验证输出。

这些不是框架应该解决的问题。身份、工具治理（控制智能体在什么条件下可以访问哪些工具）、可观测性（跟踪智能体采取的每项操作，用于审计和调试）以及安全执行都是平台层面的问题，任何框架的设计初衷都不是为了解决这些问题。

我曾与基于 LangChain、CrewAI、LangGraph 和自定义框架运行智能体的团队进行过交流。他们选用的框架各不相同，但短板完全一致。他们都遇到了相同的问题：“在开发环境中跑通”和“在生产环境中运行”之间的鸿沟不是框架问题，而是基础架构问题。这个问题如果不解决，代价是真金白银、客户信任，还有工程团队大量的时间成本。

如何弥合这道鸿沟

这类基础架构问题具有特定的表现形式。智能体框架负责解决智能体循环。但它们从一开始就不是为生产基础架构而设计的，本就不该承担这份工作。我们不会指望 Web 框架自带传输层安全性（TLS）证书颁发机构。它们是不同的工程类别。

红帽 AI 提供了框架无法提供的生产基础架构。 红帽 OpenShift AI 充当基础。运行原则是 BYOA（自带智能体），平台可以让任何智能体运行时落地运行，无论是 LangChain、CrewAI、LangGraph 还是自定义代码，且无需对智能体进行任何更改。您在框架方面的投资可以保留。智能体代码不用更改。平台会在底层注入身份、安全、治理和可观测性层。

已经存在的鸿沟

早上 6 点出现故障的智能体本身并不差。这是一个优秀的智能体，只是缺少支撑它的基础架构。每个框架都会提供推理循环、工具调用和编排。它们都无法提供决定这些功能在现实世界中运行时是否安全的基础架构。框架应该处理什么，平台必须处理什么，这二者之间的分界线就是生产环境鸿沟。框架的设计初衷本就不是弥合这道鸿沟。

如果您目前有处于开发阶段的智能体，我敢说，它们同样缺少支撑它们的基础架构。这不是因为开发工作出现错误，而是因为框架本身就不自带这套基础架构。我们的下一篇文章将介绍这套基础架构的具体组件，以及构建它们需要做哪些工作。

开始使用

准备好了解生产就绪型智能体基础架构是什么样子了吗？从以下内容入手：

• 在开发人员沙盒中免费试用 OpenShift AI：用于试验 AI 工作负载的预配置环境
• 探索红帽 AI 交互式演示：红帽 AI 实训简介
• 从 BYO Agent 入门套件入手：面向 LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK 等的预配置模板
• 阅读红帽 AI 文档：完整的平台文档
• 在红帽 AI 上实现 BYOA：OpenClaw 篇：关于在平台上部署真实智能体的实训文章