让 COBOL 长出 AI 大脑：原生 Agent 核心框架 praxo-core 深度剖析

在生成式 AI 与多智能体技术快速发展的今天，主流视野大多集中在 Python、TypeScript、Go 这些现代语言生态。

但承载金融、保险、政府、航空等核心业务的 COBOL 系统，仍然大量运行在批处理和事务环境里。行业此前的常见做法是"迁移"：用 AI 把 COBOL 翻译成 Java 或 C#，再把业务搬走。

迁移有它的合理性。但对很多核心系统来说，迁移不是一个代码问题，而是一个多年工程、监管审查和变更控制问题。

PRAXO-CORE 提供了第三条路：不重写 COBOL，不架设 Python 桥接服务，而是在 COBOL 运行时里放一个受治理的 Agent 循环。

这不是"用 COBOL 写新应用"，也不是"让大型机变成 AGI"。它是一个更窄、更工程的声明：让 Agent 下沉到系统真正运行的地方。

一、核心结论

PRAXO-CORE 的 COBOL SDK 是一个原生 GnuCOBOL 实现，不是桥接，也不是迁移翻译器。

它让 COBOL 程序可以通过标准 CALL 语句直接驱动 Agent 循环：传入 Prompt 和选项，调度模型回调、工具分发器、策略程序和事件程序，拿回结果。

当前公开的验证结果：

62 条规范向量，分布在 11 组；
原生 agent、JSON、契约边界、工具和 API 声明检查；
远程 cobol-conformance CI 通过；
源码 tag cobol/v0.1.0；
SDK 源码 MIT 许可；GnuCOBOL 及其运行时是单独许可的外部工具链依赖。

但必须同时说清楚：这不是完整 Go parity。 parity 清单里仍有多行 partial，tool.Registry 仍是 planned。COBOL API 是 wire 形状的，不是完整 Go 模型表面。

二、为什么不是桥接，也不是迁移器

桥接的思路是：COBOL 暴露一个工具或 API，Python/Java 服务拥有 Agent 循环。

这经常是正确选择。它隔离了新运行时，避免碰脆弱的 COBOL 代码，AI 团队也能快速迭代。

但治理边界会跟着 Agent 走。策略、工具授权、检查点、审计事件、人工审批，现在都在桥接服务里。每一条控制都要跨进程或网络重新建立。

迁移的思路是：把 COBOL 翻译成 Java/C#，把业务搬走。这可能是正确的长期决策，但成本不只是翻译，还包括每一笔交易、每一个对账、每一条审计路径的重新验证。

原生 Agent 循环是第三条路：循环就在拥有交易的运行时里。COBOL 程序调用它，策略和事件回调也在本地。集成边界更小，治理链更短。

三、架构拆解

1. `praxo-run`：Agent 循环

核心入口是：

复制代码

call "praxo-run" using px-options px-session px-prompt
    px-result px-user-data

px-options 指定模型、工具分发器、策略和事件程序。px-user-data 是调用方持有的 4096 字节回调上下文。

行为约定：

空回调状态表示成功；
模型/工具状态会传播；
非空策略状态表示拒绝；
输入 session 不会被修改；
每次 run 使用本地历史；
px-max-steps 为零或负数时选择 8 步；
token budget 非正数时表示不限制。

这不是"把大模型 API 包一层"。它是一个有状态机、有工具分发、有策略检查、有事件回调的循环。

2. 原生 JSON 与 UTF-8

COBOL 生态里没有现代 JSON 标准库。PRAXO-CORE 实现了：

praxo-json-parse
praxo-json-generate
praxo-json-string
praxo-json-quote
praxo-json-slice
praxo-utf8

这些程序使用 language/cobol/copy/json.cpy 里的有界记录。它们处理的不是"任意 JSON"，而是有明确容量和失败状态的 JSON。

3. JSON Schema 校验

praxo-jsonschema 负责对象/数组 schema 校验，内部使用 praxo-schema-scalar 和 praxo-schema-visit。

它覆盖向量定义的对象、数组、字符串、数字、整数、布尔、枚举、长度、模式、数值边界等行为。

注意：它校验的是声明的 JSON Schema 子集，不是任意 COBOL DATA DIVISION 定义。不要把它说成"AI 返回的 JSON 完全符合 COBOL 数据节"。

4. 工具调用解析

praxo-toolcall 支持多种格式：

JSON
XML 风格
点号标签（dotted-tag）
纯文本

它还包括 ParseInputJSON 和 StripToolCallMarkup 对应的操作。模型返回的工具调用可以是不同形状，COBOL 侧需要能解析、清洗、分发。

5. 中间件

praxo-middleware 提供：

调用步数限制（防止循环耗尽 token）；
工具选择；
fallback；
structured output；
邮箱抹除（email redaction）。

这里要特别精确：邮箱抹除只覆盖邮箱地址，不是通用 PII 控制。 它不能替代合规脱敏、数据分类或审计策略。

6. 内存内会话记忆

praxo-memory 在 COBOL 固定内存缓冲区内实现会话记录和检索。

它使用 ASCII 大小写折叠和规范 UTC 时间戳的词法排序来做 search。

注意：这是内存内存储，不是持久化数据库。不要把它说成 durable memory。

7. 其他核心程序

程序	作用
`praxo-checkpoint`	注册 payload 类型的 JSON 信封
`praxo-context`	token 估算和上下文压缩
`praxo-event`	filter 和多 sink 事件投递
`praxo-policy`	词法路径授权
`praxo-path-normalize`	词法路径规范化
`praxo-stream`	stream-kind 常量
`praxo-plugin`	严格 manifest 解析和校验
`praxo-pattern-check`	有界 ASCII 模式匹配

四、物理边界：为什么 32KB 是设计，不是缺陷

在静态内存的 COBOL 环境里，边界不是可选项。

当前公开限制：

JSON 输入最大 32,768 字节；
最多 512 个节点；
最多 64 层嵌套；
生成的 JSON 最大 16,384 字节；
非法 UTF-8、孤立代理项、畸形数字、尾随数据会被拒绝；
重复对象键保留，查找使用最后一个值；
模式匹配只支持有界 ASCII 子集：字面量、点、字符类/范围、锚点、*、+、?；
分组、交替、计数重复、Unicode 模式匹配和不支持的转义会返回 SCHEMA_PATTERN_UNSUPPORTED，不会静默接受；
路径策略是词法规范化，不是操作系统级隔离；它不解析符号链接、reparse point、文件系统大小写规则或竞态；
插件解析只校验声明，不执行插件、不验证签名；
事件和流程序是同步契约行为，不是异步高吞吐运行时。

对现代 Agent 来说，32KB 很小。对固定记录的 COBOL 批处理来说，硬边界才是安全线。它让失败模式可预测，避免模型生成的 payload 悄悄变成无界内存问题。

五、和 IBM z/OS 的关系

必须单独说这一段。

当前验证目标是 GnuCOBOL 2.0+。COBOL SDK 是原生 GnuCOBOL 实现，不是 IBM z/OS 实现。

我们不宣称 IBM z/OS 支持。 z/OS 的编译器方言、record layout、CALL linkage、LE runtime、CICS/IMS、DB2、安全模型，都需要单独验证。把 GnuCOBOL 的实现直接说成"大型机支持"，是不严谨的。

如果你有 z/OS 环境，欢迎讨论移植评估；但在有证据之前，公开材料只写 GnuCOBOL。

六、就地赋能：一个批处理场景

假设某银行的批量结算脚本在夜间运行，遇到无法核对的异常账目时，传统做法是挂起并抛出异常，等待人工排查。

现在，COBOL 程序员可以在特定 PROCEDURE DIVISION 中调用 praxo-run，让 Agent：

读取异常摘要；
调用一个受策略控制的查询工具；
等待人工审批；
写入检查点；
发出审计事件；
返回处理建议。

整个过程不需要重写核心账务系统。但也不是"零集成"：调用方需要提供 options、session、模型回调、工具分发器、策略程序和事件程序，并完成编译和链接。

这就是"no rewrite, but not no integration work"。

七、我们不宣称什么

不宣称完整 Go parity；parity 清单仍有多行 partial，tool.Registry 是 planned；
不宣称 provider adapter（OpenAI、Anthropic、Gemini 等）；
不宣称完整 assistant 工具调用历史、stream parts、事件 session/run ID；
不宣称异步高吞吐运行时；
不宣称任意精度数字；
不宣称完整 RE2/Unicode 正则；
不宣称操作系统级沙箱；
不宣称通用 PII 脱敏；
不宣称插件执行或签名验证；
不宣称 IBM z/OS；
不宣称生产可用或安全认证；
不宣称"迁移已经过时"。迁移对很多场景仍然是正确选择。

八、如何验证

复制代码

python language/cobol/run-tests.py

需要 GnuCOBOL 2.0+ 和 Python 3.10+。COBC 或 --compiler 可以指定编译器路径。Python 只用于生成和启动原生测试；编译后的 SDK 消费者不需要 Python。

然后：

读 spec/languages.md 的 COBOL 行；
读 language/cobol/README.md 的 Scope and Limits；
读 spec/parity/cobol.md 的 partial/planned 行；
检查 32KB/512/64 限制是否适合你的场景；
测试你真正依赖的安全行为：路径处理、策略顺序、取消、回调失败；
再决定原生循环、桥接还是 sidecar。

仓库：https://github.com/axisvela/praxo-core COBOL 文档：https://axisvela.github.io/praxo-core/languages/cobol/ COBOL 源码：https://github.com/axisvela/praxo-core/tree/main/language/cobol 语言矩阵：https://github.com/axisvela/praxo-core/blob/main/spec/languages.md

九、结语

PRAXO-CORE 的 COBOL SDK 不是"AGI 上大型机"的浪漫故事，也不是"迁移已经过时"的口号。

它是一个更具体的工程实验：在固定记录、无动态内存、无异步运行时的语言里，能不能实现一个受治理的 Agent 循环，并且把边界说清楚。

62 条向量、32KB 限制、同步事件、词法路径策略、只抹邮箱的中间件------这些限制不是缺点清单，而是可信度的一部分。

对于不愿冒巨大迁移风险、但又需要 Agent 能力的企业，这是一条值得评估的第三条路。