How Delta Air Lines scaled AI-native development to 1,200 engineers with cloud development environments

Delta航空如何通过云开发环境将AI原生开发扩展至1200名工程师

Component | Article_teaser

2026年10月20日

9分钟阅读

应用开发与交付

,

人工智能

Jonathan Recinos

高级产品市场经理

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

当Delta航空的开发者体验团队开始测量其净推荐值（NPS）时，他们面对着残酷的现实：这个数值非常低。两年后，当该团队向超过1200名开发者部署云开发环境（CDEs）后，实现了以下成果：

• NPS显著提升
• 使用虚拟桌面基础设施（VDI）的开发者性能获得提升
• 新人入职时间从小时和周数缩短至分钟级

Delta通过Red Hat OpenShift Dev Spaces（云开发环境）构建平台，解决传统开发问题如入职流程、依赖冲突和治理。随后AI原生开发出现，该平台以公司未预料到的方式变得至关重要。

在2026年Red Hat峰会，Delta航空IT总经理Vidheer Gadikota与Red Hat架构师Charro Lee Gruver和开发者工具高级总监Balaji Sivasubramanian共同分享了Delta的基础设施如何实现企业级AI代理。这正是他们构建过程的故事——以及为何为传统挑战打造的平台恰好为AI原生开发做好了准备。

为什么Delta从云开发环境开始

在AI代理出现之前，开发者需要在本地工作站处理依赖冲突，这个过程可能需要数天。这种设置工作占用了工程师创新和为Delta创造价值的时间。

想象一个开发者正在使用最新Java版本构建新应用，却被分配了一个需要维护运行在Java 8（2014年版本，现已停更）的遗留应用的工单。他们不得不花费数小时重新配置笔记本电脑在不兼容环境之间切换，而不是真正修复这个bug。

本地运行开发环境给Delta带来了多个问题：

• 新开发者因需要正确配置项目环境，入职往往需要数周时间
• 本地开发环境使源代码和凭证的治理更加困难
• Windows机器无法运行云原生开发所需的基于Linux的容器化工作流

Delta用20名工程师试点云开发环境，通过测试、学习和验证其可扩展性，最终实现了为期一周的成功实操体验。开发者终于在不牺牲安全性的前提下获得了自主权。

然后AI原生开发到来了。

笔记本电脑成为瓶颈并随着AI更加脆弱

Delta 在推出 AI 原生集成开发环境（IDE）数月后，团队发现一位资深开发者利用 AI 在午休前解决了整整一周的复杂问题。但这里存在一个矛盾：当 AI 代理程序运行时，他无法使用笔记本电脑处理其他任务，例如发送电子邮件。该代理程序占用了 100% 的 CPU 和内存。

这不是孤立事件。随着 Delta 工程师采用 AI 原生工具，三个关键挑战逐渐浮现。

计算需求激增

AI 代理程序持续运行，而不仅仅是在用户主动编码时工作。它们在后台运行构建流程、测试套件和环境模拟。开发者报告称，他们不得不整夜保持笔记本电脑开机并连接充电器，无法关闭设备或切换网络，否则会影响代理程序的进度。笔记本电脑反而成为限制因素，而非助力工具。

安全风险扩大

AI 原生 IDE 通过 AI 推理端点和大语言模型（LLM）集成增加了新的集成点。新扩展程序不断涌现，验证它们需要大量时间。本地开发使这种治理变得更加困难。

一致性无法实现

传统开发中困扰团队的依赖冲突问题，在 AI 工具的加持下被进一步放大。当每个开发者的环境设置、API 密钥、模型配置和 Model Context Protocol（MCP）服务器都不同时，团队无法复现代理程序的行为。故障排查变成了一种猜测游戏。

Delta 需要能够大规模运行 AI 代理程序的解决方案，具备默认的企业级安全性，并且能够使用不会耗尽笔记本电脑资源的弹性计算能力。

他们已经拥有解决这个问题的平台。

解决方案：Red Hat OpenShift Dev Spaces 用于 AI 代理程序

Delta 为传统开发挑战构建的架构，通过设计解决了 AI 原生开发问题。

开发者使用 Kiro、AWS 的 AI 原生 IDE 等 AI 原生工具作为界面。工作区（代码存放、构建运行和 AI 代理程序执行的环境）完全在 Red Hat OpenShift 集群中运行，使用 OpenShift Dev Spaces。

以代码形式定义工作区

每个项目的环境（工具、库、框架、AI 配置、API 密钥、MCP 服务器）以 YAML 文件的形式存储在 Git 仓库中。这不是为每个开发者单独定义一次，而是为每个代码库定义一次。当开发者开始处理任何项目时，系统会在 2 分钟内为其生成一个专为该代码库定制的工作区。Java 25 项目拥有自己的工作区，Java 8 旧版应用则使用不同的配置。不再出现依赖冲突。每个工作区都相互隔离、配置完善且随时可用。

云端 AI 推理和代理程序

Delta 控制模型的托管位置：对于需要物理隔离的场景采用自托管，对于适合的场景则使用经过批准的云服务提供商。API 密钥由中心化系统管理，而非分散在各台笔记本电脑上。

默认的企业级安全性

Gadikota 表示：“对开发者而言，最好的安全措施是他们根本无需绕过安全限制。”

组件 | 引述

安全性不应是工作流程中的一个关卡，而应是支撑整个工作流程的底层基础。

代码始终保留在企业边界内。扩展程序会经过扫描，并从 Delta 的私有仓库中提供。敏感信息永远不会接触本地硬盘。

这满足了 AI 原生开发所需的核心要求：

• 持续运行的代理程序：开发者可以关闭笔记本电脑、切换网络甚至去吃午饭，而代理程序仍会在云端持续运行。它是一个 Kubernetes 工作负载，而非本地进程。

• 按需弹性资源：无需提交工单即可使用图形处理单元（GPU）节点和额外计算资源。无需担心笔记本电脑的热限速问题。

• 多代理、多项目：开发人员可以启动独立的工作空间并并行运行代理，不受笔记本电脑资源的限制。

安全且大规模启用AI代理

当Delta为AI原生工作流程扩展云开发环境时，他们遇到了大多数企业尚未遇到的技术障碍。

AI代理不仅仅是编写代码。在幕后，代理和子代理需要运行构建过程、执行单元测试并模拟环境以验证解决方案的有效性。为了自主完成所有这些操作，代理需要在已经在云中运行的工作空间容器内启动容器。

嵌套容器。容器中的容器。

Gadikota在Red Hat Summit上向观众解释道：“这意味着用户需要拥有权限和root访问权限才能做到这一点。”“如果在座的任何InfoSec人员听到我说这个，你们可能感到有些不安。”

为了启用AI工作流程，整个集群都需要root访问权限？这在安全方面是不可接受的。但没有它，AI代理就无法完成工作。

这就是Delta与Red Hat合作变得关键的地方。这也说明了与开源供应商实际合作的样貌。

与Delta团队嵌入的Red Hat架构师Gruver开始构建一个解决方案，通过在命名空间级别而非整个集群的root访问权限来启用权限。这个方案是在“代理AI”概念出现之前创建的，目的是让开发工具在开发人员的隔离工作空间内运行容器。但它也使AI代理能够做到同样的事情。Delta的架构师Adnan构建了集成，将他们的AI IDE连接到OpenShift Dev Spaces。他们进行了实验，向Red Hat Engineering提供了反馈，Red Hat从Red Hat OpenShift 4.17版本开始提供了这一功能。

Gadikota指出：“我们正在回馈给Red Hat，因此每个人都能从中受益。”

现在，开发人员可以在其AI启用的工作空间内运行Podman、Docker、测试容器、Ansible部署和Tekton函数，AI代理会根据需要启动任何内容以验证解决方案。无需root访问权限。无需提交安全例外。

Gruver解释道：“如果你与Red Hat合作，这不像传统的供应商-客户关系。”

你有像我这样不仅热爱产品，而且每天都在使用它的人。我和编写代码的人是朋友。所以当Delta团队遇到问题时，如果他们自己没有提交PR[拉取请求]来解决问题（他们确实会这么做），我会与他们保持持续互动，并通过渠道与工程师沟通。你几乎能从软件供应商那里获得定制的软件……只不过它是开源的。

Delta所需的用于大规模AI原生开发的解决方案，现在已成为整个OpenShift社区都可以使用的功能。

用于AI原生开发的平台，而不仅仅是工具

Delta最具战略性的洞察：投资平台，而不仅仅是工具。

Gadikota强调：“这非常重要，因为今天提供的产品或工具在一个月或一年后可能就不再可用。我们今天使用的产品将会有三种不同的变体，然后会出现一个全新的产品。”

AI工具发展迅速。新的AI助手每周都会出现。如今IDE Delta使用的功能，6个月后可能会发生很大变化。模型能力正以前所未有的速度进步。

“但最重要的是拥有平台思维，”Gadikota继续说道。

每当有新工具出现时，如果我们有将其集成并纳入生态系统的选择，我们的采用率将持续增长，工程师们也会持续保持满意。

这就是Delta选择基于OpenShift Dev Spaces构建的原因——这是一个原生的OpenShift工作负载，与现有的GitHub、GitLab、持续集成和持续交付（CI/CD）流水线以及安全工具集成。当新的原生AI IDE出现时，Delta可以将其集成而无需重构整个开发者体验。工作区定义、安全态势、治理模型和计算基础设施始终保持一致，唯一变化的是用户界面（UI）层。

与开发者见面并提供他们想要的工具，但要与您需要的安全防护措施集成。

允许原生AI开发的4个要点

• 从开发者当前的环境出发。在您的治理模型中启用开发者想要的原生AI IDE。云开发环境在保持企业安全的同时，赋予开发者自主权。

• 将安全作为默认设置，而非障碍。在受控环境中运行AI代理，安全功能是内置的而非事后添加的。最好的安全措施对开发者是隐形的。

• 通过游戏化促进采用，而非强制要求。带有实际操作体验的产品发布效果更好。电子邮件强制要求往往会被忽视。

• 投资平台而非仅仅工具。构建一个能够集成未来任何AI工具的平台，无论哪个具体助手最终胜出，您的采用率都能持续增长。

Delta的转型始于用CDE解决传统开发问题。当原生AI开发带来新挑战时——代理占用100%的笔记本计算资源、新安全问题浮现、一致性噩梦——他们的现有平台已做好准备。

对于Delta的数千名工程师而言，他们每天运营超过5000次航班，服务2亿乘客，从与笔记本电脑限制的斗争转向为客户创造价值的转变至关重要。

开发的未来是原生AI。支持它的基础设施需要是云原生的。

准备好通过提升开发者体验来加速应用交付？

• 尝试Red Hat OpenShift Dev Spaces：了解如何为开发者提供零配置工作区和集中的安全控制。立即开始自助试用。

• 提供代理就绪的开发者门户：为开发者和AI代理提供组织上下文——服务、文档和黄金路径——使他们能够在企业标准内构建、部署和运营应用。立即使用Red Hat Developer Hub开始。

• 发现阻碍开发者和AI采用的因素：识别隐藏的低效问题——从入职摩擦到工具链蔓延——并制定路线图，缓解传统开发者障碍，实现企业级原生AI开发。了解更多关于评估的信息。

Block | Dynamic pattern deluxe promo

Component | Band_header

Product trial

Red Hat OpenShift AI on Developer Sandbox | Product Trial

即时访问由Red Hat托管和管理的最小开发者集群，专用于与Red Hat OpenShift AI配合使用。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

Try it

Deluxe mbox

组件 | 卡头

关于作者

子模式 | 演讲者

卡片布局

组件 | 图像嵌入

组件 | 人物

Jonathan Recinos

子模式 | 社交链接

Jonathan Recinos 分享关于开发者生产力的见解。他负责应用程序迁移工具包、Red Hat Developer Hub 以及 Red Hat OpenShift Dev Spaces 的营销工作。

更多该作者的文章

类似内容

动态模式

博客文章

以开源方式构建AI：Red Hat与Linux基金会的研究洞察

边缘AI的MLOps：跨分布式舰队管理AI模型

原始播客

代理AI能否修补互联网？

Red Hat如何为可扩展AI清除IT债务

继续探索 mbox

子模式 | 简单文本

按频道浏览

探索所有频道

模式 | 原始HTML

自动化

关于IT自动化在技术、团队和环境方面的最新动态

人工智能

关于让客户随时随地运行AI工作负载的平台的最新动态

混合云

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

安全

关于我们在不同环境和技术中降低风险的最新动态

边缘计算

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

基础设施

关于世界领先的企业的最新动态Linux平台

应用程序

深入探讨我们解决最复杂应用程序挑战的方案

虚拟化

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