技术速递｜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 developergit clone https://github.com/Azure-Samples/Legacy-Modernization-Agentscd 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 开始构建吧！