从自动 CI/CD 到自主代理式工作流：借助红帽 OpenShift 实现持续 AI

您被要求采用 AI 工具时，得到的承诺往往是这些工具将帮助您加速投入生产，并提升代码质量。但在使用过程中，您会发现提交的代码变更数量激增，也可能会感受到系统和流程无法跟上节奏的痛苦。开发的内循环正以闪电般的速度推进，而外循环却步履维艰。 

在许多 CI/CD 工作流中，管道故障（通常由安全漏洞或配置错误引起）可能会让开发人员陷入耗时的手动排查任务，费力地搞清楚问题出在哪里。他们需要花费大量时间来调查、调试、研究修复方案并重新提交代码。这会在开发、安全防护和运维团队之间制造摩擦，因为各方会互相推诿，争论该由谁来负责修复问题。 

在今年红帽全球峰会的 OpenShift Commons Gathering 活动中，我们深入审视了红帽 OpenShift 中的工具，并探索了如何通过代理式工作流对故障管道进行故障排除和修复。我们的开发人员倡导者 Natale Vinto 演示了红帽 OpenShift 如何通过以下方式保护并自动化开发管道：

• 定义并实施安全防护措施。 
• 利用 AI 代理加速故障检测和修复。 
• 在重新运行管道之前，通过人工介入监督来修复和验证新代码，确保修复有效且满足所有安全标准。

首先，Natale 带我们进入红帽 OpenShift DevSpaces，他在这里提交了一项用于新 Java 应用的更新，并启动了新的 DevSecOps 管道。红帽 OpenShift 已经预先定义了相关要求，以主动实施安全策略。推送代码时，系统会自动根据这些预设的安全防护策略进行核查。安全团队和运维团队通过红帽 Kubernetes 高级集群安全防护构建了稳健的策略即代码，这意味着安全定义具有一致性、受版本控制，并与红帽 OpenShift 深度集成。当检测到关键漏洞时（例如演示中展示的遭到入侵的基础镜像），管道会在代码进入生产环境之前停止部署，确保存在漏洞的软件不会被部署上线。

图 1：SRE 代理在使用红帽 Kubernetes 高级集群安全防护识别出关键漏洞后，可确定管道中的故障点。时间戳：3:42

通常，测试到了这一步就会戛然而止，开发人员不得不手忙脚乱地试图查明管道为何停止，以及如何修复。但 Natale 构建了一个名为 SRE-Agent 的 AI 代理，它并非被动的检查清单，而是作为智能执行层直接识别问题的根本原因，省去了手动翻阅日志和调试错误的繁琐工作。通过 GitHub 和 Tekton 管道即代码集成，该代理创建了一个包含修复建议的新管道，向 Natale 显示它识别的问题，并给出解决方案。它还利用 Claude 访问并验证红帽 OpenShift 中的问题，并通过 Slack 向安全团队发出问题警报。 

图 2：SRE 代理会分析遇到的问题，并提出修复方案供安全团队审核和批准。时间戳：4:13

此时，安全、运维和开发团队可以全面查看代理审查过的日志及其提出的建议，并能够据此采取行动。通过人工介入机制，团队获得了切实可行的清晰洞察，只需单击一下即可审查、验证并应用修复。这维护了开发人员的自主权和信任度，确保利用人类专业知识来授权变更，同时又能将繁琐、耗时的手动研究和测试工作交给代理去处理。

图 3：安全团队应用 SRE 代理提出的更改建议。时间戳：5:29

在应用代理的建议后，系统会重新运行管道，确保修复有效并满足所有安全防护要求。这一最终验证步骤对于保持零关键漏洞构建至关重要。团队可以通过 GitHub、OpenShift Pipelines、红帽高级集群安全防护和红帽可信配置文件分析器全面了解正在实施的变更。在确认新变更仅存在低风险漏洞后，Natale 可以放心地将新代码合并到生产环境中。 

图 4：新代码合并到管道中，并再次进行漏洞测试。时间戳：7:42

其结果是：一个能够承载大量代码提交，同时不牺牲既定安全、策略和管理协议的 CI/CD 管道。  借助红帽 OpenShift，我们在 OpenShift Pipelines 的外循环中实现了 AI 驱动型任务的自动化，从而化解了内循环中因 AI 辅助代码变更日益增多而引发的瓶颈问题。借助红帽 OpenShift，开发、安全和运维团队可以全面了解已识别的问题、AI 代理提出的修复建议以及完整的变更日志，从而自信地验证更新并将其合并到目标环境中。通过将红帽 OpenShift 的企业级稳定性、Tekton 的灵活性以及现代 AI 模型的智能相结合，我们正助力团队自信、快速地构建并交付更安全的软件。