GPT-6.1 Sol 在 COBOL 上：86.6% 对 5.4%，且两项测试中仅一项可重跑

在2026年10月19日，O​penAI 发布了两项面向低资源语言的编程评测，最受关注的数字属于GPT-6.1 Sol：在低推理强度下，86.6% 的 COBOL 迁移任务通过，而在相同设置下仅为 5.4% 的是GPT-5.6 Sol；当推理强度提高时，前一数字升至 97.9%。第二项评测 MultiLangBench 讲的则是另一个模型的故事——GPT-6 Astra 在最高推理强度下于二十种语言中平均达到 87.4%——但它是此次发布中更有用的那一半，因为 O​penAI 将其评测框架按 Apache-2.0 许可证发布在 GitHub 上，你今天下午就能自己运行它。承载 86.6% 这一数字的 COBOL 迁移评测则另当别论：它的测试是隐藏的，其通过标准是：针对 O​penAI 外部无人见过的用例，输出必须逐字节一致，而且尚无第三方复现过它。这种不对称正是事情的全貌，值得在任一数字被引用进迁移业务案例之前明确说明。像此次发布这样的版本背后，有记录的 AI 故障和智能体事件都收录在 OrcaRouter AI 事件档案中，每条记录都带有自己的来源、严重程度、置信等级和争议标记。

有一个日期需要厘清。GPT-6.1 Sol 本身来自 2026年9月29日——这不是一次发布，这里也没有任何内容会改变该模型的权重、价格或费率表。10月19日发生的事，是 OpenAI 发布了关于该模型在一个此前未曾记录过的类别中能力的证据，并发布了一个任何人都可以重新运行的基准测试。这才是本文所谈论的事件。

实际发布出来的是什么，以及每一半分别是做什么用的

这两项评估回答的是不同的问题，而 OpenAI 自己的表述也将二者区分开来。MultiLangBench 问的是，模型能否构建某个东西——用一种没人训练过的语言：用二十种编程语言之一从零实现 SQLite 3.40.1，然后通过数据库一致性测试套件。COBOL 迁移评估问的是，模型能否迁移某个东西：将 COBOL 程序翻译成 C++、Java、Kotlin、Python 或 Rust，同时精确保留可观察行为。

第一个是能力下限测试。第二个才是企业真正关心的，因为 COBOL 并非基准测试里供人猎奇的对象——IBM 长期以来的估算显示，超过 40% 的网上银行系统和约 95% 的 ATM 交易背后都是 COBOL，而维护这些代码的劳动力队伍正面临青黄不接、无人接替的处境。

• MultiLangBench，最大努力 — GPT-6 Astra 87.4%，GPT-6 Luna 40.3%，GPT-5.6 Sol 26.8%。Astra 在 20 种语言中的 19 种里达到了 83% 以上；COBOL 是它表现最弱的一项，为 72.1%，而 GPT-5.6 Sol 为 10.9%，这说明该集合中最难的语言仍然是工具链最古老的那一个。

• COBOL 迁移，低工作量 — GPT-6.1 Sol 86.6%，GPT-5.6 Sol 5.4%，估计为较旧模型评估运行 API 成本的 61%，即低 39%。

• COBOL 迁移，投入更高——GPT-6.1 Sol 97.9%，OpenAI 称其接近饱和。

• OpenAI 确实公布的分语言详情——Astra 在 Fortran 上为 83.5%，而 GPT-5.6 Sol 为 21.4%；Visual Basic 上为 89.4%，而后者为 27.5%；OCaml 上为 85.8%，而后者为 25.6%；GPT-6 Luna 在 COBOL 上为 17.1%，在 Fortran 上为 31.4%，在 OCaml 上为 34.1%，在 Visual Basic 上为 41.6%。

• MultiLangBench 上每个样本的成本 — GPT-6 Luna 估计为 $0.77，而 GPT-5.6 Sol 为 $3.48，低约 78%，正是这个数字让榜单上最弱的模型成为构建生成流水线中值得关注的那个。

你可以重新运行的评测：MultiLangBench 真正要求的是什么

该仓库位于 github.com/openai/MultiLangBench，采用 Apache-2.0 许可证，阅读测试框架比阅读排行榜更有信息量。任务足够具体，模型无法蒙混过关：生成一个可执行文件，它接收数据库路径作为命令行参数，从 stdin 读取 SQL 查询，并表现得像 SQLite 3.40.1。测试来自 SQLite 自带的 TCL 测试套件——总共约 51,000 个测试，其中约 24,000 个被转换为测试框架所使用的三元组：初始数据库、用户查询和验证查询。测试名称是这些组成部分的 SHA-256 哈希值，因此无法按名称记住整个测试套件。

难点就藏在规则里，每一条都堵死了一条捷径：

• 没有互联网，环境中也完全没有 SQLite。 测试框架要求先清除 SQLite 的一切痕迹。模型无法通过 shell 调用真实引擎，也无法获取实现。

• 验证针对真实的 SQLite 3.40.1 运行。你的实现会修改数据库；测试框架会将其提取出来，并用真实版本进行检查。近似行为会失败。

• 每项测试六十秒，语言错误的答案得零分。混用语言会失败，而测试框架指出，可能会用另一个模型来检查你实际用哪种语言作答。最后这条规则之所以存在，是因为显而易见的作弊手法——用 Python 写出来再包装一下——正是有能力的模型最先尝试的做法。

• 快速运行包含 272 个测试，而不是 24,000 个。README 建议只运行名称以 00、01或 02 开头的测试，前提是你想要可比较的数字。在将自己的分数与 OpenAI 的分数进行比较之前，需要注意这个细节：完整套件运行和快速运行不是同一种测量，README 也说明了这一点。

这是一个真实且可核验的基准测试。它还揭示了媒体报道没有告诉你的一点：87.4% 这个头条数字是在一个你可以直接拿自己的模型去跑的测试套件上测得的，这种情况足够罕见，值得下载。

无法重跑的评测，以及为什么这并不必然构成丑闻

COBOL 迁移评估由 OpenAI 设计、运行和评分，其测试用例未公开。通过标准被精确地陈述——只有每个隐藏测试都产生逐字节完全相同的可观察输出，迁移才算通过——而正是这种精确性使得结果无法从外部验证：86.6% 是 OpenAI 针对 OpenAI 自己的隐藏用例所做的测量。发布中的两项评估里，只有一项是读者可以复现的。

不公开迁移测试并非毫无道理。该语料库想必取自真实的遗留程序，一旦公开，可能泄露客户代码，或者相当于给未来的模型送上一份训练集。逐字节一致本身也是一个真正保守的标准，比大多数厂商的评测更严格：它不会奖励仅仅是“接近”的翻译。

但这一标准也正是实际麻烦的起点，而 OpenAI 自己的提醒正指向这一点。迁移输出在上线前仍需专家评审，并针对业务规则和系统依赖进行测试。而字节级一致性恰好在 COBOL 最棘手的地方难以做到：该语言对定点运算的截断和舍入方式，是大多数目标语言所没有的，因此一份译文可能看起来正确，能通过一套只检查“足够接近”的测试，却仍让某个余额差出一分钱。一套要求完全相等的隐藏测试集能处理这一点；你自己的评审流程也必须处理这一点，因为模型的得分并不等同于对你这些程序的判断。

成本数字同样需要谨慎对待。39% 的节省是对评估运行——也就是基准测试中输入和输出的 token——的估算，而不是替换生产系统的成本；后者的成本主要来自梳理发现、专家评审、集成测试，以及多年来未被记录、任何评估都无法抽样覆盖的行为。

在决策中，86.6% 和 97.9% 应该改变什么？

更诚实的解读比新闻标题更狭窄，也比它们更有用。5.4% 的基线并不意味着一个模型只做对了一半；它意味着这个模型几乎从不产出保持行为不变的翻译，因此上一代模型从来就不是这项工作的候选对象。GPT-6.1 Sol 的 86.6% 则处在经济账发生反转的区间：一个能起草大部分翻译、再留给审校检查的工具，与一个产不出任何可用内容的工具，是两种不同的产品。

更高努力程度下的 97.9% 才是值得怀疑的数字，不是因为它是错的，而是因为它已经饱和。一旦某个基准接近其上限，它就不再能区分模型，而开始衡量测试套件本身，O​penAI 也这么说过。做规划时，把低努力程度下的 86.6% 视为低成本运行点，把 97.9% 视为该评估所能展示的上限——而不是对你代码库的准确率承诺。

还有一项值得做的交叉验证，而它与炒作相悖。在构建测试中，COBOL 仍是 GPT-6 Astra 最弱的语言，得分 72.1%，尽管 Astra 整体更强，平均得分为 87.4%。这门语言无论哪个方向都很难。一个模型能在隐藏评测中很好地迁移 COBOL，并不因此就擅长 COBOL；它只是擅长评测所采样的那种模式。

本周发生的另一件事：关于推理轨迹的说法

10 月 21 日一篇被广泛分享的帖子称，GPT-6.1 Sol 的推理轨迹“完全可读，没什么可担心的。”O​penAI 10 月 19 日的发布内容中没有任何东西，模型自己的文档页上也没有任何东西，能支持这构成 API 返回内容的变化。O​penAI 的推理指南明确表示，原始推理 token 不会暴露——推理项仍然不透明——而且你能请求的是摘要，也就是通过summary参数获取的推理概要，加密的推理内容会在多轮之间重放。GPT-6.1 Sol 支持该重放的all_turns形式。摘要通道并不是可读的推理轨迹，把两者当作同一回事，正是靠截图提出安全声明的做法。

可衡量的内容就在近旁，而且对任何审计智能体的人来说更有意思。Sonar 于 10 月 9 日对 GPT-6.1 Sol 进行了评估，在 4,444 个 Java 任务上以中等努力程度与 GPT-6 Sol 对比运行，结果发现推理 token 减少了 51.4%——从 2.64M 降至 1.28M——与此同时，推理在输出中的占比从 41.8% 降至 19.5%，输出量上升，功能通过率从 83.09% 提升至 85.29%。同一次运行还发现漏洞密度下降了 32.4%，但严重级别的可靠性发现项从 21 个增加到 46 个，其中并发缺陷是最大类别，共 196 项发现。这是审查者可以据以采取行动的权衡。“轨迹可读”则不是，因为返回的内容并不是轨迹。

对迁移项目来说，这一点在一个具体层面上至关重要：你的审计线索是 diff 和测试输出，而不是模型的叙述。请据此为评审能力做预算——Sonar 的发现是：多生成 39.4% 的代码，总发现数便从 9,859 增至 12,982，而这正是隐藏在基准分数背后的成本形态。

自行运行两个试验组

像这样进行比较的实际问题在于，基线组和新组通常意味着两份合同、两个密钥和两套计费关系，摩擦大到没人愿意跑基线。openai/gpt-6.1-sol 和 openai/gpt-5.6-sol这两个模型都放在我们的目录中，共用一个密钥，按 O​penAI 的标价、0% 加价提供，因此每百万 token 的输入和输出价格与你直接向厂商支付的一致：输入 $2.00、输出 $10.00，缓存输入 $0.10、缓存写入 $2.50，超过 272K 的档位则按 $4.00、$0.20、$5.00 和 $15.00 原样传导。厂商费率变更在发布当天就在这里生效，而不是等到下一次合同评审。

这种直通让你能以很低的成本运行当日基准测试：把 MultiLangBench 快速套件同时指向两个模型，分别按标价付费，你得到的就是关于自己工具链的数字，而不是 OpenAI 的数字。自动故障转移是这一论点的另一半——如果较新的模型在运行中途性能下降，或者某条路由被限流，请求不会随之失败，这正是让你能在拥有自己的证据之前，把一个未经检验的模型放到迁移流水线前面的原因。

MultiLangBench 测试框架是公开的，而 COBOL 迁移案例并不公开，因此对 86.6% 唯一诚实的检验，就是你自己构建的那个：抽取几百个你自己的 COBOL 程序作为样本，翻译它们，然后把输出与原始行为逐字节比对。那需要一周的工作量，但它比厂商表格更有价值。

接下来看什么

有三件事会改变这一局面，但目前一件都还没有发生。O​penAI 公布 COBOL 迁移案例，或者由独立实验室重新运行这些案例，就会把一个供应商数字变成一次实际测量。第三方复现 MultiLangBench 的分语言表格，将告诉我们 COBOL 的 72.1% 是该语言本身的属性，还是该测试套件的属性。而该模型的独立基准记录——Artificial Analysis 目前将 GPT-6.1 Sol 的 Intelligence Index 定为 52，在 214 个模型中排第十二，输出速度为每秒 55.2 个 token，每项索引任务 0.72 美元——是完全不依赖 O​penAI 自身评测的那项检查。

在此之前，有用的总结很简短。GPT-6.1 Sol 是 9 月 29 日发布的一款模型，其遗留代码能力在 10 月 19 日被记录在两项评测中：一项你可以运行，另一项你无法运行。可运行的那项评测表明，新一代模型在低资源语言上处于另一个层级。无法运行的那项评测表明，COBOL 迁移现在值得开展试点。只有你自己的代码库才能把其中任何一项转化为决策。