企业过去常在两种高风险选择之间摇摆：继续维护大型机，把现代化问题留给未来；或者启动一次“大爆炸”式迁移，同时改写应用、数据和基础设施。更现实的路线，是把现代化拆成可验证、可回退的连续过程，用 AI 理解遗留系统，用云平台承载新系统，再用真实生产流量证明两边行为一致。
这套思路的关键不是让模型生成更多代码，而是先解决大型机系统中真正棘手的问题：隐藏依赖、专有数据格式、事务边界、批处理控制流，以及几十年积累下来的业务规则。
难点不在语法，而在系统行为
把一段独立 COBOL 程序改写成 Java，并不能代表完成了大型机现代化。真实企业环境通常还包含以下约束：
- 应用逻辑直接绑定 DB2、VSAM、IMS 层次结构或固定长度文件。
- CICS、IMS TM 等事务监控器同时承担会话、事务和资源协调职责。
- JCL 批处理由大量顺序步骤、条件分支和前后置依赖组成。
- CTG、IMS Connect、MQ、LU 6.2 Socket 等协议定义了系统边界。
- 一次业务交易可能穿过多个应用、数据集和数百万行代码。
- 专有运维工具、调度系统和主机实用程序形成额外锁定。
因此，迁移的验收对象不能只是“新代码能够编译”，而应该是一个可观测的行为契约：同样的输入是否产生同样的消息、数据库变更、文件记录和错误状态。
AI 在这里最适合承担的是大规模理解和关联工作。模型可以辅助解释程序，但它需要完整的应用上下文，不能只看到某个源文件。Google Cloud 提出的 Mainframe Assessment Tool（MAT）正是从评估层补齐这些上下文，包括依赖关系可视化、业务规则提取、自动文档生成，以及业务域和应用边界识别。
这些产物还可以通过 MCP 接入智能体工作流，让后续代码转换使用经过整理的应用专属知识，而不是仅依赖通用模型对 COBOL 语法的理解。
两种改造路径，不必押注一种答案
大型机资产不适合采用统一迁移策略。可以根据业务价值和变更容忍度，在两个主要模式之间选择。
确定性现代化：结构改变，行为不变
这种方式适合稳定、高吞吐且规则敏感的工作负载，例如夜间账单、总账处理和监管报表。目标是替换内部技术结构、降低 MIPS 消耗或迁移数据平台，同时保持外部接口和业务结果不变。
这里的核心约束是契约保真：对于任意给定输入，新旧系统都必须产生一致结果。AI 可以帮助转换代码，但测试基准、比较规则和差异审批流程必须由工程团队明确控制。
重写或重新构想：保留规则，重做产品
当遗留应用本身限制了业务创新时，可以先用 MAT 提取业务规则，再由专用现代化智能体完成目标规格、架构设计、用户故事、待办列表和编码计划。人工审批可以插入每个关键阶段。
例如，稳定的批处理可以走确定性迁移；核心总账可以保留监管规则，同时把数据结构迁移到 Cloud SQL；面向客户的贷款申请系统则可以重新设计成实时审批服务。这样的混合策略比按语言、部门或代码量“一刀切”更符合实际风险分布。
上线前先让新旧系统同时接受生产检验
Google Cloud Dual Run 的定位是迁移安全网：捕获真实大型机交易，把同一工作负载同时送入遗留系统和云端新系统，再比较协议消息、业务输出和数据变化。
这一步解决了传统测试环境难以覆盖的问题。历史测试用例通常只包含已知场景，而生产流量会暴露罕见字段组合、时间边界、重试行为和跨系统依赖。新系统只有在持续满足逻辑和数据等价要求后，才进入切换阶段。
团队需要提前定义“等价”的含义。时间戳、随机标识、排序方式和格式化空格未必要求逐字节一致；余额、状态码、会计分录和下游消息则通常需要严格匹配。没有字段级规则，双轨运行会制造大量无法判断的噪声。
可以这样实践：建立一个最小双轨比较器
下面是一个可运行的 Python 示例，用来演示双轨验证的基本结构。它不是 Google Cloud Dual Run 的真实 API，也不能替代生产级交易捕获；假设团队已经把新旧系统输出保存为 JSON 文件。示例忽略 processed_at 和 trace_id 两个非确定字段，同时严格比较其他字段。
把以下内容保存为 compare_outputs.py，使用 Python 3.10 或更高版本运行：
#!/usr/bin/env python3
import argparse
import json
import sys
from pathlib import Path
IGNORED_FIELDS = {"processed_at", "trace_id"}
def normalize(value):
if isinstance(value, dict):
return {
key: normalize(item)
for key, item in sorted(value.items())
if key not in IGNORED_FIELDS
}
if isinstance(value, list):
return [normalize(item) for item in value]
return value
def load_json(path):
return json.loads(Path(path).read_text(encoding="utf-8"))
def main():
parser = argparse.ArgumentParser()
parser.add_argument("legacy", help="Legacy system JSON output")
parser.add_argument("modern", help="Modern system JSON output")
args = parser.parse_args()
legacy = normalize(load_json(args.legacy))
modern = normalize(load_json(args.modern))
if legacy == modern:
print("MATCH: observable outputs are equivalent")
return 0
print("MISMATCH", file=sys.stderr)
print("legacy:", json.dumps(legacy, indent=2, ensure_ascii=False))
print("modern:", json.dumps(modern, indent=2, ensure_ascii=False))
return 1
if __name__ == "__main__":
raise SystemExit(main())
创建两份测试输出：
cat > legacy.json <<'JSON'
{
"account_id": "A-1001",
"status": "APPROVED",
"balance": "1280.50",
"processed_at": "2025-01-10T10:00:01Z",
"trace_id": "legacy-42"
}
JSON
cat > modern.json <<'JSON'
{
"account_id": "A-1001",
"status": "APPROVED",
"balance": "1280.50",
"processed_at": "2025-01-10T10:00:03Z",
"trace_id": "cloud-99"
}
JSON
python3 compare_outputs.py legacy.json modern.json
预期输出为：
MATCH: observable outputs are equivalent
生产化时，应把这个思路扩展为字段级契约：金额使用明确精度，列表声明是否允许重排，敏感字段先脱敏，差异写入审计存储，并设置阻断发布的阈值。比较器还要覆盖数据库变更、MQ 消息、文件记录和错误响应，而不只是 HTTP 返回值。
数据迁移也要保持增量
代码改造无法绕开数据问题。Google Cloud Mainframe Connector 可以把大型机数据复制到 BigQuery、Spanner、Cloud SQL、Cloud Storage 等服务，并处理代码页和数据类型转换。它还可以接入现有 ETL 流程，让企业逐步迁移数据或先把分析负载卸载到云端，从而减少大型机计算消耗。
数据迁移期间需要持续检查记录数、主键唯一性、金额汇总、字符编码和增量水位。尤其是 packed decimal、EBCDIC、REDEFINES 和可变长度记录，不能只根据表面字段名称推断转换规则。AI 可以解释格式，但最终映射仍应通过样本数据、业务规则和可重复的对账作业验证。
从一个有边界的试点开始
合理的起点不是先确定“全量迁移需要几年”，而是选择一个边界清楚、生产价值真实、依赖数量可管理的应用开展试点：
- 用 MAT 扫描代码库，确认调用关系、数据存储和外部接口。
- 提取业务规则，并让业务负责人确认规则而非只确认代码。
- 根据工作负载选择确定性现代化或重写路线。
- 建立字段级等价契约和差异审批机制。
- 迁移一部分数据，持续执行数量、金额和编码对账。
- 用生产流量进行双轨验证，达到门槛后再逐步切换。
- 保留回退路径，直到新系统通过完整业务周期，例如月末或年末结算。
AI 能显著加快理解和实施，却不会自动消除大型机中隐含的业务语义。真正可扩展的现代化方案，需要把评估、代码改造、双轨验证和数据迁移连成闭环。这样做的价值不是追求一次完美转换，而是让每个迁移步骤都有证据、有边界，也有退路。