让COBOL长出AI大脑：不迁移、不桥接的第三条路

一、凌晨两点的批处理：AI进场前，先把行为定义清楚

凌晨两点，一家银行的夜间批处理仍在运转。作业调度、对账、总账、报表——这条链路也许已经稳定跑了二十年：每一环都有明确的责任人，每一步都有审计记录可查，每次变更都要排队等窗口。它谈不上时髦，但它承载着真金白银的账务事实。

假设现在要让一个Agent参与这条链路。在讨论任何架构之前，先把期望的行为写清楚，它大概率长这样：

1. 读取一笔对账异常；
2. 调用一个查询工具，取回相关明细；
3. 形成初步判断后暂停，等待人工审批；
4. 审批通过后写入检查点，保证作业可恢复、可重放；
5. 全程发出审计事件，事后可完整追溯。

注意，这五步里没有一步是“聊天”。真正的诉求是让Agent作为交易链路的一等公民进入工作流。难点也随之浮现：主流Agent框架几乎都默认你从一门现代语言起步，在一个干净的仓库里写一个全新的应用。这个假设对创业公司成立，对这家银行不成立。

二、路线一：迁移——故事最顺，账最难算

行业面对“COBOL + AI”的第一反应，往往是迁移：用Agent辅助把老代码翻译成另一种现代语言，再把业务整体搬进新运行时。叙事非常顺滑——旧系统是负债，新系统是未来，Agent是翻译器。

对某些企业，这确实是正确答案，但它几乎从来不是小工程。核心账务、理赔批处理、福利系统、机票预订这类系统，从来不只是代码。它们是交易、对账、审计轨迹与变更控制的复合体。它们能活几十年，恰恰因为它们真的在工作。

迁移的真实成本也不在翻译本身，而在验证：

• 每一笔交易的语义都要在新栈里重新证明等价；
• 每一个对账口径都要重新对齐并经得起抽查；
• 每一条审计路径都要在新系统里重建，并被审计与监管认可；
• 并行运行期、回切预案、双轨对账，每一项都消耗真实预算与人力。

换句话说，迁移可能因为平台战略、人才结构、生态演进等原因而是对的，但它不该成为“使用Agent”的前提。没人会为了给车间装一条机械臂，先把整座厂房推倒重建。

三、路线二：桥接——隔离了风险，也拉长了治理链

第二个常见答案是桥接：COBOL侧暴露若干工具或API，由一个外部服务持有Agent循环，负责调度模型、解析工具调用、维护上下文。

在相当多的场景下，这是正确的选择：它把新运行时与脆弱的老代码隔离开，Agent侧的故障不会直接冲击核心程序，迭代节奏也快。

但要警惕一个结构性问题：治理边界会随Agent循环的位置而移动。循环在哪里，策略执行、工具授权、检查点、审计事件与人工审批就要在哪里落地。一旦循环位于外部进程，这些治理动作都必须跨进程、跨网络重建：

• 身份与授权需要跨系统传递，权限模型要做两套映射；
• 审计事件需要在两侧对齐时间戳、序号与关联ID，否则追溯链条会断；
• 检查点在Agent侧，事务边界却在核心程序侧，两者难以原子对齐；
• 网络抖动、超时与部分失败成为新的故障面，重试与幂等逻辑成倍增加。

桥接每覆盖一个新场景，就要多维护一段横跨两个世界的治理路径。它隔离了技术风险，却放大了治理面积。

四、路线三：把Agent循环放回交易所在的运行时

于是有了第三条路：不做翻译器，也不架桥，而是把Agent循环原生放进交易已经所在的COBOL运行时。

形态上它非常朴素：COBOL业务程序通过标准的CALL语句调用一个本地Agent运行器子程序，把Prompt与选项传进去，拿回结果。运行器在本地完成模型回调调度、工具分发、策略检查与审计事件发出。没有第二套运行时，没有跨进程的治理链。

调用形态可以示意如下（示意性伪代码，仅表达结构，不对应任何具体实现）：

IDENTIFICATION DIVISION.
PROGRAM-ID. RECON-AGENT-STEP.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-PROMPT               PIC X(2048).
01 WS-OPTIONS.
   05 OPT-MODEL-ENDPOINT   PIC X(256).
   05 OPT-MAX-TURNS        PIC 9(4)  VALUE 8.
   05 OPT-TOOLSET          PIC X(32) VALUE 'RECON-TOOLS'.
   05 OPT-AUDIT-TOPIC      PIC X(64).
01 WS-RESULT.
   05 RES-STATUS           PIC X(16).
   05 RES-TEXT             PIC X(4096).
   05 RES-CHECKPOINT-ID    PIC X(64).
PROCEDURE DIVISION.
    STRING '读取对账异常表,对每笔差异调用明细查询工具,'
          '给出初步判断,超过阈值时转人工审批.' INTO WS-PROMPT
    CALL 'AGENT-RUN' USING WS-PROMPT, WS-OPTIONS, WS-RESULT
    EVALUATE RES-STATUS
      WHEN 'APPROVED'
        PERFORM WRITE-CHECKPOINT
      WHEN 'PENDING-APPROVAL'
        PERFORM SUSPEND-JOB-STEP
      WHEN OTHER
        PERFORM LOG-AND-ESCALATE
    END-EVALUATE.

内部结构大致是：

COBOL 业务程序
    │ CALL（Prompt + 选项）
    ▼
Agent 运行器（原生 COBOL 子程序）
    ├── 模型回调：经标准 HTTPS 通道调用大模型推理服务
    ├── 工具分发：CALL 本地工具子程序 / 读取数据副本
    ├── 策略程序：工具白名单、金额阈值、审批触发
    ├── 事件程序：审计事件与作业日志同源落盘
    └── 检查点：状态信封，支持中断后恢复

这条路线的收益可以压缩成一句话：策略与事件回调都落在拥有交易的那个运行时里，治理链更短，集成边界更小——对外的依赖被收敛为“模型回调”一条出网通道。

需要特别强调：这条路线的重点不是“用COBOL写新应用”，而是让Agent下沉到系统真正运行的地方。

五、原生实现需要补齐的八个零件

“原生”不是口号，它意味着Agent循环所需的全部零件都以COBOL子程序、副本文件与标准CALL接口的形式存在，而不是把另一门语言的SDK包一层薄桥。这套零件至少包括：

1. Agent循环本体：计划—执行—观察的迭代控制，含最大轮次、超时与中断恢复；
2. JSON解析与校验：模型回包的解析、schema校验与容错降级；
3. 工具调用解析与分发器：把模型给出的工具调用映射到本地子程序CALL；
4. 上下文估算与裁剪：估算对话上下文的规模，避免越过程序内存与模型窗口限制；
5. 检查点信封：把轮次、状态与待审批项封装成可持久化、可恢复的信封结构；
6. 会话内存与中间件：跨CALL的会话状态、消息历史，以及可插拔的前后处理钩子；
7. 策略程序：工具白名单、参数约束、金额阈值与审批规则的本地执行；
8. 事件程序：把每一次模型调用、工具执行与审批动作，转成结构化的审计事件。

这些零件之所以必须原生，是因为它们每一环都触碰治理面：任何一环留在外部，都会把“桥接问题”重新引回来——要么治理链变长，要么审计无法同源。原生实现的本质，是把这些治理动作折叠回交易所在的进程之内。

工程上，这类组件应当构建在主流开源COBOL编译器与运行时之上，以子程序与副本文件交付，从而直接复用企业既有的编译、回归测试与发布纪律。

六、落地路径：从一个异常处理场景开始

不要试图一步到位“Agent化”整条批处理链。推荐的最小闭环，正是开头那五步。展开成可执行的实施顺序：

第一步，选场景。优先选择高重复、低风险、判断边界清晰的环节，例如对账差异初判、报表数据一致性核查，避开资金写操作。

第二步，定义工具面。只读工具先行：明细查询、余额核对、历史记录检索。一切写操作必须经过策略程序与人工审批双重闸门。

第三步，把人工审批做成工作流的一等公民。轮次执行到审批节点时写入检查点并暂停作业步；审批动作回流后从检查点恢复执行。审批不是异常分支，而是正常路径的一部分。

第四步，审计事件与作业日志同源。事件由本地事件程序发出，与作业日志落在同一套基础设施上，运维与审计团队不需要学习第二套系统。

第五步，沿用既有工程纪律。COBOL世界最被低估的资产，是成熟到刻板的变更控制：变更窗口、编译回归、发布审批。把Agent能力当作一个子程序引入，就让它像其他任何程序变更一样走完整流程——这是优势，不是包袱。

模型侧不必被运行时绑架。运行器只需一条标准HTTPS通道对接推理服务即可——既可以接入百度智能云等厂商提供的大模型服务，也可以对接企业内网自建的推理集群。运行时与模型解耦，模型升级就无需重新触碰核心程序的治理流程。

七、三条路线的决策清单

• 选迁移：当系统本身已有明确退场计划，或平台战略决定更换技术栈，且预算覆盖多年期的重新验证与并行运行；
• 选桥接：当Agent场景集中在外围——智能问答、门户查询、报表解读——不触碰核心交易与资金操作；
• 选原生：当Agent需要真正参与交易链路本身——读异常、调工具、走审批、写检查点、发审计——此时治理链的长度直接决定方案成败。

三条路并不互斥。更现实的图景是：外围用桥接快速见效，核心链路用原生缩短治理，迁移留给真正到达生命终点的系统。

八、结语：让智能长在系统运行的地方

核心系统不需要为了获得智能而搬家。让COBOL长出AI大脑，不是把老代码翻译成新语言，也不是在旁边架一座桥，而是把Agent循环放回交易所在的地方：策略在本地执行，检查点与事务同界，审计与作业日志同源。尊重系统真实运行的位置，让智能长在那里——这才是对二十年批处理链路最负责任的现代化方式。