以任务所需的速度进行重构：借助红帽 AI 实现传统系统现代化的“代理网格”方法

传统软件不会自行淘汰。它驻留在生产环境中，不断累积技术债务，抗拒变更，并悄然演变为一种风险——原因不在于它做了什么，而在于它已无力支撑什么。

这正是领先系统集成商（SI）在为政府和行业提供支持时所面临的挑战。在涵盖多个任务关键型应用的产品组合中，系统集成商和航空航天公司正在管理日益老化的 Python 和 Java 代码库，这些代码库需要迁移到一个安全至上且具备可支持性的现代化基础平台，具体来说，就是红帽企业 Linux 10（RHEL 10）。

目标不仅仅是进行软件升级，而是要维持软件交付速度、AI 运行速度，以及政府数据中心、前沿部署任务区域或机载移动系统所依赖的安全态势。

这对于美国联邦政府而言，并非纸上谈兵。 美国总务管理局（GSA）的 AI 治理框架和美国战争部（DoW）现已明确要求各机构和服务部门，不仅要采用负责任的 AI，更要将其投入实际运行。对于国防和任务利益相关者而言，该指令并非一项可以敷衍了事的政策要求，而是一种关键驱动力，要求必须先把软件工厂打造好，其中的代理才能被委以重任。 

在最近的一次合作中，其中一项硬性要求就是系统必须具备完整的离线兼容能力。支持国家安全防护的环境，通常被设计为无法访问互联网。对外部服务（GitHub、云 API、远程软件包注册表）的任何依赖项，都可能成为漏洞、故障点，或导致系统严重不合规。 

虽然从技术层面来讲，手动进行系统现代化改造是可行的，但预估工程量需耗费数年人力，面对如此规模，这条路根本行不通。另一种选择是维持现状，继续运行日益老化的系统，承受不断加剧的运营风险。接下来的问题是，是否存在第三条路径——我们能否利用代理式自动化构建更高效的流程，让工程师得以监督大规模的现代化改造，而非亲自执行每一个步骤？

事实证明这是可行的，我们利用红帽 AI 和红帽 OpenShift AI 构建了一个代理式平台。

大规模实现传统系统现代化面临的问题

棕地迁移——即迁移真实的生产代码（而非绿地概念验证（POC））——与构建新系统有着本质区别。您不能只是给 AI 提示，就宣称大功告成。

传统代码库通常具有以下特征：

• 架构过时： 系统的设计基于反映早期工程规范的假设、框架和基础架构。
• 测试覆盖范围有限或不均衡：代码库中的大部分代码是在自动化测试成为标准规范之前编写的。
• 隐性行为契约： 模块与服务之间实际存在，但从未被正式记录或实施的依赖关系。
• 累计的技术债务：层层叠加的临时解决方案、已弃用的库和兼容性修复程序，已逐渐成为生产系统的一部分。

对于国家安全防护任务而言，一旦出错，后果绝非抽象的、理论上的，而是极其具体和严重的。如果迁移失败，不仅会导致应用崩溃，还可能使整个工作流程停摆、导致任务延误，或者在保护人民安全的基础架构中引入安全漏洞。

在这种环境中，无法采用在云 API 后端运行的大型通用前沿模型。您无法将敏感代码发送到外部端点，也无法承受大规模推理过程中不可预测行为所带来的后果。即便您能够连接到云端前沿模型，当请求扩展到跨越大规模参数空间的长推理链时，由此产生的词元量和计算开销也是根本无法接受的。在这种系统包含数百万行代码的迁移规模下，前面提到的问题会迅速转化为延迟、基础架构成本和更高的运营风险。

为什么小型高效模型才是理想之选

在大多数 AI 应用中，人们往往本能地倾向于选用现有的最大模型。参数越多、上下文信息越丰富，答案就越准确。在非联网、任务关键型和资源有限的环境中，这套逻辑很快就会行不通。大型前沿模型往往会带来过高的延迟、不可预测的推理循环，以及巨大的 GPU 内存需求，而这些在受控基础架构中难以得到满足。

小语言模型（SLM）非常适合代理式工作流，因为这些系统需要可靠、可重复的执行能力以及低延迟响应，而不仅仅是一味追求模型规模。较小的模型能够提供快速、确定性的行为，非常适合工具调用、编排和结构化推理等自动化任务。它们也更容易在本地进行微调和运维，使团队能够在不依赖外部端点的情况下，部署大量特定领域的代理。换句话说，当模型只对某个领域“精通”时，概率分布就会变得更加集中，并且往往会更频繁地生成相同的答案。

话虽如此，我们的测试表明，模型能力仍与上下文长度和参数数量密切相关，尤其是对于需要了解大型软件系统的代码迁移任务。在早期测试中，表现出色的模型是 Llama 4 系列变体和 Claude 系列模型，这主要得益于它们超大的上下文窗口（超过 25.6 万个词元）和强大的推理能力。但反过来，我们发现 Claude 有时会对简单的工程任务过度思考，产生不必要的冗长推理链，从而增加词元消耗和延迟。在涉及数百万行代码的迁移规模下，这种行为很快会导致计算成本显著增加。

因此，鉴于大型模型对 GPU 内存的需求，我们目前正在本地运行 Meta Maverick，并同时使用 Mistral 模型进行测试。此外，我们也在重新评估 Llama 4 Scout，该模型虽然表现优异，但在当前环境下同样面临计算资源的瓶颈。

作为一种实用的变通方案，我们实施了一种混合模型策略：在重构工作流的同时使用较小的模型，以便在出现上下文限制时予以缓解。

我们当前为代理编排框架选定的模型：

• mistralai/Devstral-Small-2-24B-Instruct：专为编码代理而设计。拥有 25.6 万个词元的上下文窗口，在编码基准测试中表现优异，针对软件分析和重构任务进行了优化。
• mistralai/Ministral-3-14B-Reasoning：专为非编码代理而设计。拥有 25.6 万个词元的上下文窗口，在跨迁移工作流的结构化推理、依赖项分析以及编排方面表现出色。

除代理模型外，系统还使用专用模型进行知识索引和检索：

• gpt-oss-120B：用于构建 GraphRAG 知识图谱，以呈现代码库的全局结构。
• intfloat/e5-mistral-7B-instruct：用于 GraphRAG 索引和向量检索的嵌入模型。

这些并非妥协之选，而是基于现有计算环境、针对特定目的所做出的工程决策。我们之所以面临上下文限制，根源在于 GPU 容量有限，而非架构本身存在局限。随着基础架构不断扩展，代理利用和模型选择策略也可以随之扩展。

代理网格架构：基于 OpenShift AI 构建的代理式“高级编排框架”

该平台的核心是一个代理框架，即一个模块化的编排框架，负责协调多个专用的 AI 代理，每个代理负责迁移工作流中的特定环节。该编排框架在 OpenShift AI 上运行，利用 vLLM 实现高效、低延迟的模型推理。随着时间的推移，这种模式逐渐演变成我们所说的代理网格，即一种“高级编排框架”架构，使多个代理工作流能够在复杂的现代化项目中相互协作、协调任务并共享状态。

以下是该架构目前所做的工作：

编码代理：由 Devstral 提供支持，可分析传统 Python 2 或 Java 源代码，识别已弃用的 API，生成重构后的等效代码，并创建特性测试，以在进行任何更改之前捕获原始行为。它们不只是翻译语法，更致力于保留行为意图。

非编码代理：由 Ministral 提供支持，在更广泛的工作流中执行推理任务，包括依赖关系映射、迁移规划和进度跟踪。确定性编排逻辑控制着执行流，因此代理会围绕已迁移、已验证、已阻止以及后续待处理的内容进行协调。

自定义跟踪管理代理：负责处理与 GitLab 的集成（在非联网环境中可以完全被替换）。该组件采用完全可审查的代码，而非“黑箱”模式，使企业组织能够将整个编排框架与现有的开发和治理体系相集成。

此编排框架本身的设计遵循模块化与可替换原则，将定制代理与 OpenCode 等开源代理相结合。当企业组织询问该系统是否为“黑箱”时，坦率地讲，答案需分情况而论：LLM 推理层与任何神经网络一样，本质上是不透明的。然而，编排逻辑、代理代码、输出和决策路径都是完全可追溯、可审计和可检查的，这对于在美国战争部（DoW）安全与保障要求下运营的企业组织而言至关重要。

作为 OpenShift AI 中的推理引擎，vLLM 是一项关键的赋能技术。高效推理不仅仅是一种性能优化，在 GPU 资源有限的环境中，它也是确保多代理工作流切实可行的决定性因素。vLLM 经过优化的服务使平台能够处理迁移工作流所需的迭代式多步骤推理循环，而不会在单个任务上耗尽计算资源。

随着针对测试、安全审查、文档生成或部署验证等关联任务的代理编排框架不断涌现，这些框架可通过更广泛的代理网格相互连接，从而在整个现代化管道中实现协同自动化。

迁移工作流：先 Python，后 Java

本次合作的初始阶段目标是从 Python 2 迁移到 Python 3，这既是真正的可交付成果，也是对框架的验证。Python 2 已于 2020 年终止生命周期，仍在运行该版本的系统面临着漏洞未修补且无上游支持的局面。对政府和企业系统而言，这是实实在在的隐患。

我们的假设是，迁移成本会随外部依赖关系的复杂度成比例增加，这点已在测试中得到验证。与已弃用的第三方软件包紧密耦合的应用，需要进行更多轮的代理迭代才能实现干净的迁移。这一发现反过来影响了模型设计：减少每个流程中的代理子任务数量，缩小每次迭代的范围，并在各次迭代之间增设更具确定性的验证步骤。

30 天目标：达到 80% 的测试覆盖率，消除对 GitLab 的依赖，并验证 Python 2 与 Python 3 版本之间的功能等效性。

图 1：基于 OpenShift AI 的代理式软件工厂工作流，涵盖编码代理、非编码代理及工具。

随后，30/60/90 天路线图将转向 Java 迁移，目标版本为 OpenJDK 和 Corretto（7、8、11、17、21），最终迈向 Java 25。具体迁移路径将根据目标环境是 RHEL 8 还是 RHEL 9/10 而有所不同。需要明确指出的是，这并非万能的灵药，也不是一套放之四海而皆准的方案。代理框架是一个起点，其中的每个代理都是为迁移工作流中的特定任务而构建的，正因如此，它能够扩展到 Java 平台，而无需从头开始重建。

衡量真正重要的指标：棕地开发 KPI

许多代理式和传统软件开发 KPI，都是针对绿地开发制定的。它们假设您了解架构、可以访问文档，并且正在构建新的内容。这些指标侧重于开发速度。

在棕地传统系统迁移中，光有速度而缺乏正确性，根本不叫成功，那不过是以 AI 的速度制造技术债务罢了。

我们为本次合作定义的 KPI 框架，围绕以下三个问题分层展开：

能否正常运行？功能等效率、集成测试通过率、变更失败率。这些是决定项目成败的关键指标。如果在给定相同输入的情况下，重构后的代码无法生成与原始代码相同的输出，那其他一切都毫无意义。

我们是否了解其运作方式？开发人员接受率、测试覆盖率增量、迁移完成率。代码能运行，并不意味着迁移完成。只有当负责维护这些代码的开发人员能够读懂它、信任它和维护它时，迁移才算真正完成。

团队能否长期维护它？开发人员信心评分、首次贡献耗时、开发人员产能增益。最终的投资回报率（ROI）指标，并非每项任务的词元成本，而是工程团队从重复性的迁移工作中节省出多少时间，从而专注于价值更高的任务贡献。

速度指标（吞吐量、迭代延迟、每分钟代理操作次数）应出现在工程信息面板中，用于系统调优；而不应出现在项目评审中，作为衡量成功的标准。

红帽 AI 和 OpenShift AI 使这一切成为可能

如果没有能够真正提供支持的平台，这一切都无法实现。 OpenShift AI 为本文所述的一切提供了基础层：

• 基于 vLLM 的模型服务：为赋能代理编排框架的编码和推理模型，提供高效且可扩展的推理能力。
• 模型自定义工作流：支持针对需要在资源受限环境中运行的模型进行微调、LoRA 和量化。
• 非联网集群支持：该平台专为在没有互联网访问权限的环境中运行而设计，而这正是此处的基本要求。
• 审计日志记录和可观测性：任务利益相关者所需的可追溯性和可说明性，内置于平台中，而非事后附加到平台上。
• 模块化、容器化架构：代理采用容器化设计，可替换，并可通过系统集成商、航空航天公司及联邦政府已熟悉的现有 OpenShift 基础架构进行部署。

图 2：  利用红帽 AI 构建代理所需的组件和功能。

采用 RHEL 10 作为目标运行时环境并非偶然。RHEL 10 带来了安全强化措施、针对现代 Python 和 Java 的更新运行时支持，以及政府系统所需的运营可靠性。迁移到 IT，这不仅仅是一项软件生命周期决策，更是一项关乎安全防护与任务就绪度的决策。

更大的模式：跨多个任务区域的代理网格

这次合作只是一个单点实例，我们预计它将在国防工业基地、联邦政府以及更广泛的行业中反复上演。传统软件资产规模十分庞大，而手动迁移这些系统所需的工程资源，在当前问题所要求的规模下根本无法满足。与此同时，运行不受支持软件的安全窗口期即将关闭。

基于 OpenShift AI 等平台的代理式 AI，可为技术娴熟的工程团队赋能，使他们能够监督代码库的迁移工作，这些代码库原本靠人工需要数年时间才能完成现代化改造，而借助此项技术，可将时间缩短至原来的几分之一，同时满足任务关键型环境所需的严谨性和可追溯性。

在此模型中，代理式编排框架协调专门的代理来执行离散的现代化任务。随着这些编排框架扩展到相关功能（例如测试、安全审查、部署验证），它们开始形成一个代理网格，即一种“高级编排框架”架构，可在庞大的软件资产中协调复杂的工程工作流。

代理执行重复性工作。工程师负责架构、监督、代理评估和异常处理。这种分工，正是该模式的核心。

小模型。高效推理。模块化代理。非联网运营。与任务目标相契合的系统现代化。

结语

前沿模型是卓越的推理引擎。专为特定目的构建的代理式平台，则是执行任务的工具。

对政府机构而言，这并非采用最新的 AI 技术，而是在于拥有基础架构和 AI 能力，以确保关键系统安全、现代化，且服务于任务目标。

我们正在借助红帽 AI 来实现这一目标。

了解更多

• 红帽 AI
• 红帽 OpenShift AI