OpenAI 推进低资源编程语言编码能力：MultiLangBench 与 COBOL 迁移评测解析
事件概述
OpenAI 于 2026 年 10 月 19 日发布文章，介绍其最新模型在低资源编程语言（low-resource programming languages）上的编码能力进展。所谓低资源，是指相比 Python、JavaScript 这类语料丰富的语言，模型可学习的代码与文档明显更少，但这些语言却支撑着大量关键基础设施与核心服务。
原文给出的典型例子包括：
- COBOL：支撑超过 40% 的在线银行系统、80% 的柜面信用卡交易以及 95% 的 ATM 交易；
- Fortran：用于天气预报与核反应堆安全分析；
- 此外还涉及 OCaml 与 Visual Basic。
OpenAI 表示，这项工作受到开发者与企业客户反馈的驱动——他们反映编码模型在这些语言上经常表现不佳。遗留系统的维护与现代化改造本身就很困难：文档可能不完整、原始开发者可能已经离开公司、重要业务规则可能只存在于代码之中。无论是修 bug 还是迁移到其他语言，团队都需要保持系统所依赖的行为不变。
为衡量进展，OpenAI 构建了两个评测，分别考察两项互补能力：从零构建新软件，以及保持既有软件行为不变。
关键技术点
评测一：MultiLangBench（从零构建 SQLite 兼容引擎）
MultiLangBench 要求模型用指定编程语言从零构建一个与 SQLite 兼容的数据库引擎。模型需要组织代码库、管理状态、处理错误，并在保持既有功能的前提下添加新特性。
评测设计上有一个值得注意的工程技巧：以数据库文件作为跨语言的共享接口。候选程序接收一个初始数据库和一条 SQL 查询，产出修改后的数据库；再用参考的 SQLite 实现校验结果数据库内容是否符合预期。这样同一套测试可以适用于任意实现语言。测试用例改编自 SQLite 现有的测试套件，最终同时报告测试通过率和 API 成本，衡量模型在长时间编码会话中能构建出多少可用功能。
原文公布的结果（最高推理强度下）：
| 模型 | 20 种语言平均通过率 | 备注 |
|---|---|---|
| GPT‑6 Astra | 87.4% | GPT‑5.6 Sol 为 26.8% |
| GPT‑6 Luna | 40.3% | 平均 API 成本约 $0.77/样本，GPT‑5.6 Sol 为 $3.48，约低 78% |
分语言看，Astra 在全部 20 种语言上均有提升，其中 COBOL 从 10.9% 提升到 72.1%，OCaml 从 25.6% 到 85.8%，Fortran 从 21.4% 到 83.5%，Visual Basic 从 27.5% 到 89.4%。Astra 在 20 种语言中有 19 种超过 83%，COBOL 仍是最难的一种，停留在 72%。Luna 在每种语言上也都优于 GPT‑5.6 Sol，例如 COBOL 10.9%→17.1%、OCaml 25.6%→34.1%、Fortran 21.4%→31.4%、Visual Basic 27.5%→41.6%。
OpenAI 同时表示会在 GitHub 上发布 MultiLangBench 的评测设置与测试套件，以及各语言的结果，方便开发者检查评测内容、查看自己所用语言的表现并识别差距。
评测二：COBOL 代码库迁移
第二个评测要求模型把 COBOL 程序迁移到 C++、Java、Kotlin、Python 或 Rust，同时保持程序原有行为。成功的迁移需要同时理解程序的业务逻辑和 COBOL 的语言特性。COBOL 程序常处理金融交易与业务记录，其中舍入规则、缺失记录处理等细节直接反映业务需求。原文举了一个很典型的坑：COBOL 的定点运算在未显式要求舍入时会丢弃多余小数位；如果重写时改成四舍五入，程序可以正常跑通，却会产出不同的财务结果。
为验证行为是否被保留，OpenAI 使用隐藏测试，要求可观测输出达到逐字节一致，且只有全部测试通过才算迁移成功。原文也明确提示：这类行为保持能力对维护和改造老系统的团队很有价值，但应用到生产软件仍需专家评审，并针对系统的业务规则与依赖进行测试。
结果方面，GPT‑6.1 Sol 在低推理强度下达到 86.6% 准确率（GPT‑5.6 Sol 在同一设置下为 5.4%），成本仅为后者的 61%（即便宜 39%）；提高推理强度后准确率达到 97.9%，评测已接近饱和。
目标能力画像
OpenAI 将目标描述为：让模型在更多语言上运用软件工程技能——理解不熟悉的代码仓库、规划变更、使用构建工具、运行测试、调试失败。
对数据科学或 AI Agent 落地的意义
第一，评测接口的设计思路值得借鉴。以数据库文件这种语言无关的产物作为判定依据，绕开了”不同语言如何公平比较”的难题，也避免了脆弱的静态检查。对内部做 Agent 评测的团队来说，这是一种低成本、高可复现的任务封装方式：固定输入与输出契约，用参考实现做裁判。
第二，“行为保持”是 Agent 进入生产系统的门槛能力。企业遗留系统的改造不是”写出能跑的代码”，而是”写出结果完全一致的代码”。字节级对齐、定点数截断这类细节，恰恰是通用代码生成模型最容易忽略、也最容易造成财务级事故的地方。把这类约束显式写进评测，比单纯追求 pass@k 更贴近真实交付。
第三，成本曲线决定了 Agent 能否规模化。原文反复强调”更高准确率、更低成本”：Luna 以约 78% 的成本降幅换来对上一代模型的全面超越；迁移任务在低推理强度下即可达到 86.6%。对于需要在 CI 中批量跑代码迁移、修复与测试的流水线，单位任务成本往往比峰值准确率更关键。
第四，COBOL 仍是短板，而这正是价值所在。Astra 在 19/20 种语言上超过 83%，唯独 COBOL 停在 72%。这意味着在银行、保险等 COBOL 密集行业，模型更适合作为”理解与辅助”角色，而非无人值守的自动迁移器。
需要说明的是，原文未说明这些模型的参数规模、训练数据构成、低资源语言的具体数据配比，也未说明 MultiLangBench 全部 20 种语言的完整清单与开源许可证细节。
我的技术点评
这篇发布最值得关注的不是榜单数字，而是评测方法论的两次转身。
第一次转身是 MultiLangBench 的”以产物为接口”。很多代码基准依赖单元测试或人工评分，跨语言时极难对齐。用 SQLite 数据库文件作为中间态，等价于把”是否正确”压缩成一个可 diff 的二进制对象，判定完全客观、可自动化、可复现——这是典型的把模糊能力转化为可测量量的工程做法。同时它测的是长会话中的工程组织能力（组织代码库、管理状态、增量加特性），比单函数补全更接近 Agent 的真实工作形态。
第二次转身是 COBOL 迁移评测对”逐字节一致”的坚持。这是刻意设高的门槛，也是我认为最有产业价值的一点。它把”语义等价”从一句口号变成了可执行的验收标准，并且精准命中了 COBOL 定点算术这类”看起来对、算出来错”的陷阱。原文主动承认生产落地仍需专家评审，这个边界划得比较诚实。
有两处需要保持审慎。其一，97.9% 已经接近饱和，说明该评测作为进步标尺的寿命不长；如果后续不提升难度（例如更长的程序、更复杂的文件与报表结构、跨程序调用链），很快就无法区分模型优劣。其二，COBOL 在 MultiLangBench 上仅 72%，与”迁移任务 97.9%”形成了有趣的张力：写一个 COBOL 数据库引擎，和把 COBOL 读懂并翻译出去，是两种不同的难度结构。前者要求模型主动生成符合 COBOL 风格与约束的新代码，后者更依赖理解与映射。这个差距提示我们，低资源语言的能力提升可能更多来自”翻译侧的推理能力”，而非”生成侧的语言熟练度”。
对做 Agent 落地的团队，一个可直接借鉴的动作是：把关键业务不变量写成隐藏的字节级/数值级回归测试，再让 Agent 在这套约束下工作。这比在提示词里写十句”请注意精度”有用得多。
