为什么仅靠 AI 代理框架还不够：生产环境中缺失的七项平台能力

您的代理能够正常运作。我知道确实如此。您利用 LangChain 或 CrewAI 或某种自定义方案构建了代理，并基于真实场景对其进行测试，它表现得不错。问题不在于代理本身，而在于它周围的一切。

在“为什么优秀的 AI 代理在生产环境中会失败：缺失的基础架构层”一文中，某项 AI 代理部署在一夜之间遇到了三个问题：43 张重复的支持工单，4,000 美元被记入错误的计费账户，以及一条虚假的退款政策导致公司不得不退还 280 美元。该代理在开发环境中运行良好，但在生产环境中却出现问题，原因是生产环境中的基础架构不够完善。一个在开发环境中能正常运行的代理与生产就绪型部署之间的差距，并不是框架问题，而是基础架构问题。

本文将揭示这一差距。我将介绍以下内容：

• 目前所有框架都尚未内置的七项具体能力
• 您框架的局限性
• 为什么三种常见的解决方案都行不通
• 什么才能真正帮助您弥合这一差距，且无需您重写代理

您的框架中缺失的七项能力

凌晨六点的事件暴露出三个问题。但这三个问题只是更广泛的基础架构能力缺失的表象。当我梳理各企业组织内的代理在生产环境中出现的问题时，同样的七个缺口每次都赫然在目。

1.加密身份

加密身份提供可验证的证明，能够确认是哪项工作负载发出请求，并通过身份属性决定该工作负载可以访问哪些服务。之所以会出现从错误账户扣款 4,000 美元的问题，是因为该代理使用了过于宽泛的凭据，而这些凭据从未针对生产环境进行过权限范围限定。大语言模型（LLM）选择了错误的账户标识符，而基础架构中没有任何机制来阻止这一行为。借助加密身份，平台会限制代理可以访问的服务，并且正确配置的下游 API 会严格限定哪些参数对特定调用方有效。模型可能仍然会选择错误的标识符，但潜在影响是可控的，损害仅限于代理授权范围内的资源，而非系统中的所有账户。对于决策者而言，这是“一个账户受到影响”与“所有账户均处于暴露风险之下”之间的区别。

2.执行沙盒

执行沙盒提供硬件和应用级隔离，从而确保遭到入侵或行为异常的工作负载无法访问主机操作系统或影响其他工作负载。这并非代理所独有，任何工作负载都需要隔离，但代理之所以使隔离变得尤为紧迫，是因为它们能够自主运行，以机器速度调用 API 并执行工具操作。如果没有沙盒，一个工作负载的故障会变成同一台计算机上所有工作负载的故障。一个能够写入文件系统或在其权限范围之外建立网络连接的代理程序，对安全团队而言是一个安全隐患，绝不会被批准投入生产环境。

3.工具治理

工具治理是一种基础架构级策略，用于确定代理可以调用哪些工具，该策略在网络层实施，因此任何提示注入（一种通过恶意输入诱使代理执行非预期操作的技术）都无法绕过它。我曾看到一些团队试图通过提示词工程来控制工具访问权限，但这种做法并不可行。一个蓄意的攻击者，或者一个足够有创造力的模型，能够绕过提示词层面的限制。治理机制应当在基础架构层面实现，而非在提示层面。

4.可观测性和跟踪

可观测性和跟踪包含完整的执行跟踪记录，可捕获每个提示词、每次工具调用和每个中间结果。那次凌晨六点事件中出现的三个问题，全都没有被及时发现，直到客户投诉和发票异常才将问题暴露出来。如果有完整的执行跟踪记录，每个问题在客户报告之前就会暴露出来。对于开发人员而言，这意味着可以像调试分布式微服务调用一样，对多步骤的代理交互进行调试。对于企业而言，这意味着审计跟踪日志能够满足合规审查人员的要求。

5.持续评估

持续评估会根据策略和真实标准对代理输出进行生产性评分，从而在客户报告之前就发现问题。代理编造了一条虚假的退款政策，告知客户退款窗口期为 90 天（实际仅 30 天），而这条错误信息之所以能真的传到客户那里、被客户看到，是因为没有评估层将输出与真实政策进行核对。静态测试套件能够捕获您预料到的问题，而持续评估则能够捕获您未曾预料到的问题。

6.安全执行

安全执行在推理边界处提供护栏，可在输出到达客户、数据库或下游代理之前将其拦截。在代理一天内出现 3 次问题的示例中，框架将模型生成的虚假响应直接发送给客户，而未进行任何检查。安全执行将推理边界变成了一个检查点，而非直接放行的通道。

7.生命周期管理

生命周期管理包括在整个代理集群中部署、更新、扩展和停用代理，并保持一致的运营和安全态势。如果只有一个代理，那它更像是一个独立的项目；但如果三个团队要管理十个代理，那将会成为运营层面的挑战。如果没有生命周期管理，每个团队都会自行制定部署流程、安全模型和更新周期，从而导致一致性不复存在。

您框架的局限性

生产环境要求这七项能力保持一致。那么，您目前使用的框架究竟会给您带来什么影响？LangChain 和 LangGraph 为您提供链、代理、工具调用、结构化输出、基于图形的编排、会话内存和检索集成。可组合性非常强。CrewAI 为您提供多代理协调、基于角色的代理设计、任务委派和人员编排，并且多代理模式经过了周密的考量。Google ADK 与 Google 生态系统紧密集成。Claude Agents 带来了深度推理能力。Strands（AWS）提供 AWS 原生工作流集成。

每个框架都在代理循环（即感知、推理和行动的循环）方面表现出色，正是这一循环使代理成为真正的代理。但没有任何一个框架提供加密身份或执行沙盒。网络层面的工具治理也缺失。生产级分布式跟踪、持续评估、在推理边界安全执行以及代理机群生命周期管理，在这些框架中均不存在。

这并非批评，仅仅是类别上的区分。框架属于应用层工具，但我列出的这七项能力属于平台层范畴。期望您的框架内置这些能力，就像期望 Django 内置 Kubernetes 一样，容器编排是基础架构，不是应用逻辑，指望 Web 框架包含它是不切实际的。这里的情况亦是如此，只是层级不同而已。

如果您尝试过部署具备适当身份、跟踪和治理能力的 LangChain 代理，那么您应该已经感受到这一点。最终，您编写的平台集成代码比代理代码还要多。代理是比较简单的部分。

三种无法扩展的方法

如果代理是简单的部分，团队仍然需要解决困难的部分。我采访过的每个团队，在寻找平台级解决方案之前，都至少尝试过以下方法之一。

自行构建。团队编写自己的身份注入、跟踪集成和部署脚本。若仅有一个代理，这确实可行，甚至会让人挺有成就感，因为您对每一个环节都了如指掌。但当三个团队共同管理十个代理时，每个团队都有自己的安全模型、跟踪信息记录格式和部署流程。这既缺乏一致性，也缺乏治理，只会带来日益沉重的维护负担，使高级工程师无法专注于代理本身。我发现许多团队将更多时间花在维护自研的平台粘合层上，而非构建代理能力。

托管代理平台：Salesforce Agentforce、AWS Bedrock Agents 或 Azure AI 代理服务等托管代理平台，通过掌控整个堆栈来消除生产环境中的这一缺口。代价是，这些平台同时也掌控着数据路径。每个提示词、每次工具调用、每个推理工件都通过第三方服务进行路由。在受严格监管的行业中，数据不得离开企业内部网络，因此这种模式根本行不通。而且，当平台调整定价或停用某项功能时，您的代理也必须随之调整。

特定于框架的扩展：特定于框架的扩展在单个生态系统中提供面向生产的附加组件，用于跟踪的 LangSmith 就是一个很好的例子，而且它确实非常实用。但是，运行 LangChain、CrewAI 和自定义代理的企业组织，现在需要三套彼此独立的生产方案。这意味着团队需要学习三种跟踪信息记录格式、三种安全模型以及三套工具。生产基础架构应当与框架无关，而不应成为又一个被锁定到单一供应商生态系统中的组件。

每种方法解决了一部分问题，但同时也引入了新的限制。第一种方法无法扩展；第二种方法以牺牲主权为代价来换取便利；第三种方法会使生产方案因不同框架边界而变得支离破碎。

您的代理，红帽的平台

每种方法都存在一个共同的局限，即假设生产基础架构与代理框架来自同一地方，或者从头开始构建。我认为这种假设是错误的。BYOA（自带代理）是红帽 AI 采用的方法，即平台无需修改代码即可为任何代理框架提供生产基础架构，其出发点与前文假设截然相反。

红帽不在框架层展开竞争。无论您的代理是在 LangChain、CrewAI、Claude Agents、Google ADK、Strands 还是自定义 Python 上运行，红帽 AI 都能使其投入生产运营。您的团队在开发环境中编写的代理代码，就是生产环境中运行的代码。身份、沙盒、工具治理、跟踪、评估和生命周期管理均由平台注入，而不是由代理开发人员编写。而且，生产基础架构在企业组织内的每个框架中都保持一致。

对于决策者而言，这意味着企业组织对其所选框架的投资不会化为泡影。团队无需在首选框架与能够支持他们满足各种监管限制的生产基础架构之间做出选择，而是可以两者兼得。平台将生产基础架构引入框架，而非反之。

BYOA 同时也标志着从租用 AI 基础架构向拥有 AI 基础架构的转变。红帽提出了数字主权的四大支柱：数据主权、技术主权、运营主权和保障主权。BYOA 平台同时覆盖这四大支柱，我们将在后续文章中详细探讨。

为自主站点可靠性工程师（SRE）代理提供支持的同一平台基础架构，也可以支持人力资源（HR）入职助理、采购审批工作流或客户服务升级机器人，即使用例不同，该基础架构也不受领域限制。

红帽为 LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK 等框架提供了入门工具包，且已预先配置好平台集成，包括身份验证、模型上下文协议（MCP）连接和跟踪初始化。团队从 Day 0 起便可开始构建，无需在数周的集成工作完成后才开始。

您已经知道如何做出的决定

Day 0，而非几周之后——这种表述听起来应该很熟悉。十年前，各企业组织在容器方面面临着同样的问题：每个团队都可以构建容器，但没有人能在整个企业组织范围内，以一致的安全性、网络和生命周期管理方式在生产环境中运行容器。答案并非“选择更好的容器运行时”，而是红帽 OpenShift，这一平台通过提供运行时并不具备的基础架构，使任何容器运行时都能投入实际运营。我们在此讨论的内容之所以听起来很熟悉，是因为红帽 AI 正是在这个平台的基础之上运行。

代理领域存在的差距，与当年容器领域面临的问题如出一辙。问题并不在于“我应该使用哪个框架”。您已经做出了这个决定，而且这很可能是正确的决定。问题在于“谁提供我的框架未附带的生产基础架构”，并且首先需要弥合的，正是开发环境与生产环境之间差距最大的那一环。这便是安全防护，我们的下一篇文章将从这里开始继续探讨。

开始使用

准备好弥合您的代理在生产环境中的缺口了吗？

• 在开发人员沙盒中免费试用 OpenShift AI：在预配置的环境中免费构建和测试代理。
• 探索 BYO Agent 入门套件： 面向 LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK 等的预配置模板。
• 学习免费的红帽 AI 基础课程： 涵盖基于红帽 AI 进行构建的基础知识的实训教学。
• 了解红帽 AI： 平台概述与生产基础架构能力。
• 在红帽 AI 上实现 BYOA：OpenClaw 篇： 通过真实的代理部署案例，了解 BYOA 的实际应用。