Why your AI agent framework isn't enough: 7 platform capabilities missing from production

为什么你的AI代理框架还不够：生产环境中缺失的7大平台能力

Component | Article_teaser

2026年7月17日

7

分钟阅读

人工智能

Richard Naszcyniec

AI技术产品营销总监

Joshua Wilson

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0授权

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

你的代理有效。我知道它确实有效。你基于LangChain或CrewAI或自定义方案构建了它，用真实场景进行了测试，它成功应对了这些场景。问题不在于代理本身，而在于它周围的一切。

在《为什么优秀的AI代理在生产环境中会失败：缺失的基础设施层》一文中，单个AI代理部署在一夜之间遭遇了3次重大失败——43个重复的客户支持工单、4,000美元错误计入账单账户、以及一个虚构的退款政策导致公司不得不支付280美元退货。该代理在开发阶段表现完美，但在生产环境中失效，因为生产基础设施存在不足。开发阶段有效代理与生产就绪部署之间的差距不是框架问题，而是基础设施问题。

本文将揭示这一差距。我将讨论：

• 当前没有任何框架提供的7项具体能力
• 你的框架在哪些方面存在局限
• 为什么3种常见变通方案会失败
• 实际上能帮助弥补差距的方法（无需要求你重写代理）

你的框架未提供的7项关键能力

凌晨6点的事件暴露了3次失败。但这些失败只是更广泛基础设施缺失的表征。当我将生产代理失败案例映射到不同组织时，每次都会出现相同的7个缺口。

1. 加密身份

加密身份提供可验证的证明，表明哪个工作负载正在发起请求，其身份属性决定了它可以访问哪些服务。4,000美元错误计入账单账户事件的发生，是因为代理使用了范围未限定于生产环境的广泛凭证。一个大型语言模型（LLM）选择了错误的账户标识符，而基础设施中没有任何机制阻止这一行为。通过加密身份，平台可以限制代理可访问的服务范围，下游API在正确配置后会强制验证特定调用者的有效参数。模型可能仍然会选错标识符，但潜在影响是可控的——损害仅限于代理授权范围内的资源，而非系统中所有账户。对决策者而言，这代表着"仅一个账户受影响"与"所有账户暴露"之间的关键差异。

2. 执行沙箱化

执行沙箱化提供硬件和应用级隔离，确保被入侵或行为异常的工作负载无法访问主机操作系统或影响其他工作负载。这并非代理独有需求——任何工作负载都需要隔离，但代理使这一需求变得紧迫，因为它们自主运行，以机器速度调用API并执行工具操作。没有沙箱化隔离，一个工作负载的故障将演变为同一机器上所有工作负载的故障。能够写入文件系统或在授权范围外建立网络连接的代理，是安全团队绝不会批准用于生产的隐患。

3. 工具治理

工具治理是基础设施级别的策略，用于确定代理可以调用的工具，该策略在网络层执行，因此无法通过提示注入（一种通过恶意输入欺骗代理执行非预期操作的技术）绕过。我曾见过团队试图通过提示工程来强制实施工具访问权限，但这种方法并不可靠。有决心的对手或足够有创意的模型会绕过提示级别的限制。治理应属于基础设施层面，而非提示内容本身。

4. 可观测性与追踪

可观测性与追踪包含完整的执行追踪，记录每个提示、工具调用和中间结果。在凌晨6点的事件中，所有3次故障直到客户和发票出现后才被发现。如果拥有完整的执行追踪，每次故障在客户报告之前就会被发现。对开发者而言，这意味着可以像调试分布式微服务调用一样调试多步骤代理交互。对业务而言，这意味着能够满足合规审查要求的审计追踪。

5. 持续评估

持续评估通过将代理输出与策略和真实数据进行生产环境评分，使回归问题在客户报告之前就被发现。幻觉退款政策（代理告诉客户退货窗口是90天而非实际的30天）之所以能到达客户，是因为没有评估层将输出与真实策略进行核对。静态测试套件能捕捉到你预期的问题，持续评估则能捕捉到你未预料到的问题。

6. 安全执行

安全执行在推理边界提供防护措施，在输出到达客户、数据库或下游代理之前进行拦截。在代理一天内失败3次的示例中，框架直接将模型生成的伪造响应发送给客户而未进行任何检查。安全执行使推理边界成为检查点，而非直接通过的通道。

7. 生命周期管理

生命周期管理包括在舰队中部署、更新、扩展和退役代理，同时保持一致的操作和安全态势。一个代理是一个项目，但三个团队共管理10个代理则是一个操作挑战。没有生命周期管理，每个团队都会发明自己的部署流程、安全模型和更新节奏。一致性将不复存在。

框架的局限性

上述7项能力的一致性是生产环境所要求的。那么你目前使用的框架实际上在哪些方面留有空白？LangChain和LangGraph为你提供了链式结构、代理、工具调用、结构化输出、基于图的编排、会话记忆和检索集成。其组合性确实非常强大。CrewAI为你提供了多代理协调、基于角色的代理设计、任务委派和团队编排，其多代理模式设计得非常周到。Google ADK与Google生态系统紧密集成。Claude Agents带来了推理深度。Strands（AWS）提供了AWS原生的工作流集成。

每个框架在代理循环（感知、推理和行动的循环，使代理成为代理的核心机制）方面都表现出色。但没有一个框架提供加密身份或执行沙箱。网络层的工具治理缺失。生产级分布式追踪、持续评估、推理边界的安全执行以及舰队生命周期管理在它们之中均不存在。

这不是批评，只是类别上的区分。框架是应用层的工具，但之前列出的7项能力属于平台层的范畴。期望框架自带这些功能，就像期望Django自带Kubernetes一样——容器编排属于基础设施，而非应用逻辑，要求Web框架包含它显然是不合理的。此处的情况也是如此，各层之间只是存在差异而已。

如果你尝试过使用具备完整身份认证、追踪和治理功能的LangChain代理，应该已经感受到这种困境。最终你会发现，需要编写的平台集成代码多于代理本身的代码。代理部分反而是最容易实现的。

三种无法扩展的方案

如果代理部分相对简单，团队仍需解决真正的难题。我与每个团队交流时发现，他们在寻找平台解决方案之前，至少都尝试过以下三种方法中的一种。

自行构建。团队自行开发身份注入、追踪集成和部署脚本。对于单个代理，这种方式可行，甚至令人满足，因为你能完全掌控每个组件。但当三个团队共维护10个代理时，每个团队都有自己的安全模型、追踪格式和部署流程。缺乏一致性与治理，维护负担却持续增长，资深工程师不得不花费更多时间维护自研平台胶水代码，而非专注代理功能开发。我曾目睹团队将超过一半时间用于维护自研平台代码。

托管代理平台（如Salesforce Agentforce、AWS Bedrock Agents或Azure AI Agent Service）通过掌控完整技术栈消除了生产环境的差距。但代价是它们也掌控了数据路径。每个提示、每个工具调用、每个推理产物都需经过第三方服务。在数据必须留在本地网络的受监管行业，这完全不可行。当平台调整定价或弃用功能时，你的代理也必须随之变更。

框架专用扩展在单一生态内提供面向生产的附加功能——例如LangSmith的追踪功能确实实用。但若组织同时使用LangChain、CrewAI和自研代理，就需要维护3套独立的生产方案。这意味着需要处理3种追踪格式、3种安全模型和3套工具链，团队需要学习3套不同的生产基础设施。生产基础设施应与框架无关，而非绑定于特定厂商生态的另一层限制。

每种方案都解决了部分问题，却引入了新的约束。第一种方案无法扩展，第二种方案用便利性换取了自主权，第三种方案则在框架边界上碎片化了生产故事。

你的代理，Red Hat的平台

所有方案共有的约束是：假设生产基础设施必须与代理框架来自同一来源，或需要从零构建。我认为这种假设是错误的。BYOA（Bring Your Own Agent）——Red Hat AI的方案，通过平台为任何代理框架提供生产基础设施而无需代码变更——采用的是完全相反的出发点。

红帽不会在框架层进行竞争。无论您的代理运行在LangChain、CrewAI、Claude Agents、Google ADK、Strands还是自定义Python上，红帽AI都能将其投入生产。团队在开发阶段编写的代理代码，与生产环境运行的代码完全一致。身份验证、沙箱、工具治理、追踪、评估和生命周期管理由平台注入，而非由代理开发者编写。组织内所有框架的生产基础设施保持一致。

对决策者而言，这意味着组织在所选框架上的投资不会陷入困境。团队无需在首选框架与支持合规性的生产基础设施之间做出取舍，而是可以同时获得两者。平台将生产基础设施引入框架，而非相反。

自带代理（BYOA）也标志着从租赁AI基础设施向拥有基础设施的转变。红帽定义了数字主权的四大支柱：数据主权、技术主权、运营主权和保障主权。BYOA平台覆盖这四大支柱，相关内容将在后续文章中深入探讨。

驱动自主站点可靠性工程师（SRE）代理的同一平台基础设施，同样可以支持人力资源（HR）入职助手、采购审批流程或客户服务升级机器人——即使使用场景不同，基础设施也保持领域无关性。

红帽为LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK等框架提供了集成平台的启动套件——已预置认证、模型上下文协议（MCP）连接和追踪初始化功能。团队可在第0天立即开始构建，无需经历数周的集成工作。

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

第0天而非数周——这种表述方式应该很熟悉。十年前，组织在容器方面面临同样的问题：每个团队都可以构建容器，但整个组织内无法在生产环境中统一实现容器的安全性、网络和生命周期管理。答案不是“选择更好的容器运行时”，而是红帽OpenShift——一个通过基础设施实现任何容器运行时运营化的平台。此处讨论的内容之所以熟悉，是因为红帽AI正是构建在OpenShift之上。

代理的差距具有相同的形态。问题不是“我应该使用哪个框架”。您已经做出了这个决策，而且很可能是正确的选择。真正的问题是“谁提供我所选框架未自带的生产基础设施”——而第一个需要弥补的差距，正是开发与生产之间距离最远的领域。这就是安全性，我们的下一篇文章将从这里展开。

立即开始

准备好为您的代理弥合生产差距了吗？

• 在开发者沙箱中免费试用OpenShift AI：无需成本即可在预配置环境中构建和测试代理。

• 探索自带代理（BYOA）启动套件：LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK等框架的预配置模板。

• 免费学习红帽AI基础课程：涵盖在红帽AI上构建的基础知识的动手实验。

• 了解红帽AI：平台概述及生产基础设施能力。

• 在红帽AI上实现自带代理（BYOA）：OpenClaw版：通过真实代理部署实例了解BYOA。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

适应性企业：为何AI准备就是应对变革的准备

这本电子书由Red Hat首席运营官兼首席安全官Michael Ferris撰写，帮助IT领导者应对当前面临的AI驱动的技术变革和颠覆性挑战。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Richard Naszcyniec

Subpattern | social_links

在Sybase、Siebel Systems、Oracle、IBM和Red Hat（自2012年起）等公司拥有三十多年软件行业经验，我目前担任AI技术架构师和AI未来学家。在Red Hat任职期间，我曾领导团队通过战略性销售策略和战术提升全球销售业绩，此前还负责Application Services（中间件）事业部的技术竞争营销管理。如今，我的使命是揭开AI架构的神秘面纱，帮助专业人士和组织理解AI如何创造商业价值、推动创新并有效集成到软件解决方案中。我借助丰富的经验，指导AI的战略实施。我的工作重点在于解释AI架构的组成部分、实际应用方式，以及它们如何转化为可衡量的商业效益，例如获得竞争优势、实现差异化并以简单而创新的方案取悦客户。我热衷于赋能企业不仅利用AI预见未来技术格局，更主动塑造未来。同时，我也致力于推动AI的负责任使用，让每个人都能实现超越以往的成就。

更多该作者的文章

Joshua Wilson

类似内容推荐

Dynamic pattern

Blog post

物理AI：当机器开始在现实世界中思考和行动

模型即服务（MaaS）治理：管理AI访问权限和令牌配额

Original podcast

技术深谈 | 用开源定义主权AI

技术深谈 | 开源AI战略解析

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是智能体AI？ 文章

• 预测性AI与生成性AI 文章

• 构建生产就绪的AI/ML环境的关键考量 电子书

• 以Ansible方式实现生成性AI 视频

• 通过现代应用平台实现创新与转型 电子书

Keep Exploring mbox

Subpattern | simple_text

按频道浏览

探索所有频道

Pattern | raw_html

自动化

IT自动化在技术、团队和环境中的最新进展

人工智能

让客户能在任何地方运行AI工作负载的平台更新

混合云

探索我们如何通过混合云构建更加灵活的未来

安全

在不同环境和技术中降低风险的最新进展

边缘计算

简化边缘操作平台的最新动态

基础设施

全球领先的企业级Linux平台最新动态

应用程序

我们应对最复杂应用挑战的解决方案解析

虚拟化

您本地或跨云工作负载的企业级虚拟化未来