技术速递｜GitHub Copilot 和 AI Agent 如何拯救传统系统

作者：Andrea Griffiths

排版：Alan Wang

GitHub Copilot 和 AI Agent 正在使传统的 COBOL 系统对现代开发者变得可访问。

想象一下：你是一名2025年的开发者，你的公司刚刚告诉你，他们需要对一个每天处理数百万次 ATM 交易的主机系统进行现代化改造。我们谈论的是 COBOL，一种已经存在65年的编程语言。它比互联网还要古老。

现在，你的第一反应可能是大笑或者哭泣。但事实是------COBOL 并不会消失。事实上，今天它正在驱动一些世界上最大和最关键的系统。

问题是？寻找了解 COBOL 的开发者就像寻找独角兽一样。最初的开发者们正在退休，而却有2000亿行 COBOL 代码仍在运行我们的银行、保险公司和政府系统。

但这里有个转折点：我们现在有机会支持这些独角兽。我们有 GitHub Copilot 和自主 AI Agent。

认识这位「不会 COBOL 却在革新 COBOL」的开发者

我最近与微软全球黑带 Julia Kordick 交流，她正利用 AI 推动 COBOL 系统现代化。令人惊讶的是------她从未学过 COBOL。

Julia 带来了自己的 AI 专业能力，与拥有数十年领域经验的专家紧密合作。这种合作关系正是关键所在。她无需成为 COBOL 专家，只需专注于自己擅长的领域------设计智能化解决方案，而 COBOL 专家则提供传统系统的知识支持。

当生成式 AI 出现时，我们就在思考------如何用 AI 去解决一个长期未解的问题。 ------Julia Kordick，微软全球黑带

三步走：AI 驱动的传统系统现代化框架

Julia 及其团队提出了一套系统化的框架，不仅适用于 COBOL，也可推广到其他传统系统现代化项目。该框架由 GitHub Copilot 驱动，经过实战验证。

第一步：代码准备（逆向工程）

传统系统最大的难题在于：企业早已不清楚自己的代码到底在做什么。虽然依赖它运行，却难以真正理解。

GitHub Copilot 就像是一把"代码考古工具"，可替代昂贵的顾问分析，通过 AI 实现：

• 从旧文件中提取业务逻辑
• 用 Markdown 生成可读文档
• 自动识别调用链和依赖关系
• 清理冗余注释与历史日志
• 在必要处添加说明性注释

💡 专业提示：AI 分析结果必须经人工审核。AI 擅长识别模式，但业务语境仍需人工判断。

Copilot 生成的示例文档：

# GitHub Copilot 生成的业务逻辑分析
## 文件清单
- listings.cobol：列表管理功能（约100行）
- mainframe-example.cobol：主机程序（约1万行，高复杂度）

## 业务目的
客户账户验证与余额检查  
- 验证账户号是否存在于主文件  
- 计算余额并进行透支保护  
- 生成审计日志  

## 发现的依赖
- 通过 SQLCA 进行的 DB2 数据库连接
- 外部验证服务调用
- 传统打印队列系统

第二步：丰富信息（让 AI "读懂"代码）

通常你需要为代码补充上下文，以帮助 AI 更好地理解它。

具体可以这样做：

翻译处理 ：

如果你的代码中包含丹麦语、德语或其他非英文注释，请将它们翻译成英文。模型在理解英文上下文时效果更好。

结构分析 ：

COBOL 语言具有确定性的结构模式。即使你从未编写过 COBOL，也可以利用这些可预测的规律来分析代码。具体如下：

COBOL 程序始终遵循相同的四区结构：

1. IDENTIFICATION DIVISION ------ 程序的元信息
2. ENVIRONMENT DIVISION ------ 文件与系统配置
3. DATA DIVISION ------ 变量声明与数据结构定义
4. PROCEDURE DIVISION ------ 实际的业务逻辑

你可以让 GitHub Copilot 为你映射这些区段，使用如下提示语：

"识别此 COBOL 文件中的所有区段，并总结每个区段的功能。"
"列出在 DATA DIVISION 中定义的所有数据结构及其用途。"
"从 PROCEDURE DIVISION 中提取主要的业务逻辑流程。"

AI 可以解析这些结构化的区段，并用通俗的英文进行说明。你不需要理解 COBOL 的语法，只需要知道------COBOL 严谨固定的结构，比那些更灵活的语言更容易让 AI 进行分析。

以文档作为"唯一可信源" ：

将所有由 AI 生成的内容保存为 Markdown 文件，使其成为主要的参考依据。Julia 如此解释：

让 Copilot 生成的所有准备性内容都写入 Markdown 文件，这样它在后续分析时就能将这些文件作为唯一可信的参考来源。

💡 专业提示 ：在这里，COBOL 冗长的语法反而是一种优势。
像 ADD TOTAL-SALES TO ANNUAL-REVENUE 这样的语句几乎不需要额外解释即可理解其含义。

你可以让 Copilot 将这些业务规则提取出来，转化为自然语言描述。

第三步：自动化辅助（扩展流程）

一旦你分析并丰富了单个文件，就需要理解它们如何整体组合。这时，你就从交互式使用 Copilot 转向使用 AI Agent 构建自动化工作流。

Julia 的团队使用 Microsoft Semantic Kernel 构建了一个框架，能够协调多个专业化 Agent。每个 Agent 都有特定的任务，它们协作处理单个 AI 调用难以应对的复杂性。

以下是该协作在实际中的表现：

• 调用链映射：生成 Mermaid 图表，展示文件间的交互。一个 Agent 读取你的 COBOL 文件，另一个追踪程序间的 CALL 语句，第三个生成可视化图表。最终，你会得到整个系统的地图，而无需手动追踪依赖关系。
• 测试驱动现代化：提取业务逻辑（Agent 1）、生成验证该逻辑的测试用例（Agent 2）、然后生成通过这些测试的现代代码（Agent 3）。测试在迁移过程中成为你的安全网。
• 依赖优化：识别可以用现代等价物替换的工具类和库。一个 Agent 分析你正在使用的第三方 COBOL 库，检查是否存在现代替代方案，并标记简化迁移的机会。

可以这样理解：在 IDE 中的 Copilot 是一次对话，这个框架则是一条生产线。每个 Agent 各司其职，协作层负责管理它们之间的工作流。

💡 专业提示：在进行任何更改前，使用 Mermaid 图表可视化复杂依赖关系，有助于提前发现边缘情况。你可以让 Copilot 追踪代码库中所有 CALL 语句，并以 Mermaid 语法输出这些图表。Mermaid 图表示例：

实战验证：这不是万能解法

Julia 对局限性直言不讳：

目前所有对你承诺"嘿，我可以只用一键就解决你所有主机问题"的人，都在对你说谎。

现实情况是：

• 人工必须始终参与验证。
• 每个 COBOL 代码库都是独特且复杂的。
• 我们还处于 agentic AI 发展的早期阶段。
• 完全自动化可能至少还需要五年时间。

但这并不意味着我们今天无法取得重大进展。

实操演示：Azure 示例框架

Julia 和她的团队已将整个框架开源。该框架基于 Microsoft Semantic Kernel 构建，用于 Agent 编排，包含以下内容：

• 多个专业化智能体 ：DependencyMapperAgent、COBOLAnalyzerAgent、JavaConverterAgent
• 成本跟踪：准确查看每次 AI 操作的费用（通常分析 1000 行代码约 2--5 美元）
• 人工验证节点：内置专家审核检查点
• doctor.sh：配置与测试脚本，可快速上手

尝试运行 COBOL 现代化框架：

1. Fork 仓库 ：aka.ms/cobol
2. 设置环境：配置 Azure OpenAI 端点（或针对敏感数据使用本地模型）
3. 运行 doctor 脚本 ：./doctor.sh doctor 验证你的环境和依赖
4. 开始现代化 ：./doctor.sh run 启动自动化流程

# Quick setup for the impatient developer

git clone https://github.com/Azure-Samples/Legacy-Modernization-Agents

cd Legacy-Modernization-Agents

./doctor.sh setup

./doctor.sh run

改变一切的商业理由

这不仅仅是技术债的问题。这关乎业务生存。组织在最需要 COBOL 专业知识的时候，正面临严重短缺。

传统做法是聘请昂贵的顾问，花费五年以上进行手动转换，最终得到难以维护的自动生成代码。我在多家机构中见过这种情况。顾问进来，运行自动转换工具，交付数千行生成代码，然后离开。随后，内部团队被迫维护他们不理解的代码，还在学习这门语言。

AI 驱动的方法改变了这一切。你使用 AI 理解业务逻辑，生成可读的现代代码，并保持对知识产权的控制。团队在整个过程中保持参与，他们在实践中学习业务逻辑。生成的代码是开发者真正能够使用的。

Julia 解释了这种转变：

许多客户不再希望将所有知识产权百分之百交给合作伙伴，对吧？他们希望保有掌控权。

从这里开始：成为现代化高手的路径

无论你面对的是 COBOL、古老的 Java，还是任何传统系统，以下是你今天可以开始的方法：

从小处开始

• 识别一个有问题的传统系统（从少于 5,000 行代码开始）
• 使用 GitHub Copilot 分析单个文件
• 用 Markdown 记录你的发现
• 与团队分享发现

构建你的 AI 工具箱

• 试用 Azure 示例框架
• 学习代码分析的提示工程（例如："分析这个 COBOL 程序，并用简单语言说明其业务目的"）
• 练习迭代式现代化技术

超越代码思考

• 考虑云原生设计的非功能性需求
• 规划分布式系统架构
• 记住：大多数 COBOL 程序只是执行简单的 CRUD 操作。它们不需要主机复杂性，而需要现代架构的简洁。

挑战来了：在你的组织中找到一个传统系统。在我们行业中，六个月前的代码也算作传统系统。尝试使用 GitHub Copilot：

• 生成业务逻辑文档
• 识别潜在的现代化机会
• 创建带有人为验证节点的迁移计划

开始的最佳时机就是现在

我与 Julia 交流中获得的最有力洞见是：AI 并不取代开发者的专业知识，它会放大这种能力。

COBOL 专家提供不可替代的领域知识。现代开发者带来架构和最佳实践的新视角。AI 提供大规模的模式识别和翻译能力。

当这三股力量协同工作时，传统系统现代化就会从一个不可能的挑战，变为可实现的项目。

现代化传统代码的最佳时间是十年前，其次就是现在。

特别感谢微软全球黑带 Julia Kordick 分享了她的见解和经验，使这篇博客文章得以成形。

准备深入了解吗？ 请查看关于该项目的完整博客文章：aka.ms/cobol-blog，并在 LinkedIn 上关注 Julia 获取最新动态。

传统代码的年代不必再成为障碍。借助合适的 AI 工具和框架，即便是 65 年历史的 COBOL，也能变得可接近、可维护并现代化。

你下一步会现代化哪个传统系统？立即使用 GitHub Copilot 开始构建吧！