OpenAI真的在8月20日开源了Codex“Harness”吗？现有证据与ARC-AGI-3成绩解析

开发者目前可以使用哪些入口？

现有官方资料显示，开发者可以直接通过API调用Codex优化模型，以获得更高的定制自由度；也可以使用Codex SDK，以更简单地把编码智能体集成到自己的应用中。

OpenAI的开发者指南还将完全开源的codex-cli列为参考实现。它可以帮助开发者了解编码智能体如何组织提示、工具和执行流程，但这并不自动等于OpenAI已经在8月20日发布了一个名为“Harness”的Apache 2.0框架。

基于已确认的信息，Codex类应用通常需要以下几类能力：

• 任务规划：把复杂目标拆分成多个可执行步骤；
• 代码操作：读取仓库内容，修改文件并生成补丁；
• 工具执行：运行测试、构建、代码检查等命令；
• 结果反馈：根据工具输出判断下一步行动；
• 迭代修复：发现失败后修改方案并重新执行；
• 状态管理：在长任务中保留有用的中间状态，避免每一轮都从头开始；
• 并行与后台运行：在云端环境中同时推进多个任务。

ARC-AGI-3成绩为何会大幅变化？

这部分有较明确的官方数据支持。OpenAI表示，在Responses API中开启“保留推理”和“上下文压缩”后，GPT-5.6 Sol在ARC-AGI-3公开任务集上的成绩从13.3%升至38.3%，约为原来的3倍；与此同时，输出token减少了6倍。

这里的重点不是模型名称发生了变化，而是同一个模型所处的运行环境发生了变化：

• 保留推理让长期任务能够延续此前的中间推理和已获得的信息，而不是每次API调用都近似重新开始。
• 上下文压缩则在历史信息不断增长时，对已有状态进行压缩，减少需要继续携带的上下文规模，同时保留对后续任务有用的内容。

这也解释了为什么输出token消耗会下降：系统不必反复重建已经掌握的任务状态。不过，这一结果应被理解为一次特定配置下的基准测试表现，并不能直接推导出所有任务都会获得相同幅度的提升。

更广泛地看，实验说明智能体的实际效果不仅取决于基础模型本身，也取决于运行时如何处理记忆、上下文、工具调用和多轮执行。

所谓Harness包含哪些组件？目前不能确定

部分二手报道声称，所谓Harness包括

codex exec

因此，现阶段更稳妥的表述是：

• Codex确实具备多步骤编码执行能力；
• OpenAI确实提供API和Codex SDK等开发入口；
• Responses API中的推理保留和上下文压缩确实显著改善了公开ARC-AGI-3测试结果；
• 但所谓“Harness”开源项目的正式名称、许可证、组件边界、代码仓库和发布日期，仍缺乏足够的官方证据确认。

采用企业与商业成果：现有材料没有给出答案

目前提供的资料没有列出哪些公司采用了这个所谓的Apache许可Harness，也没有说明这些企业运行了哪些非编码工作流，或取得了怎样的量化结果。因而，不能据此补充具体企业名称、部署规模或业务收益。

OpenAI确实表示，企业用户正在更多地使用Codex完成较大规模、可委派的工作；但这属于Codex及企业智能体使用趋势，不能直接证明某个未经充分确认的Harness开源框架已经被特定公司采用。

真正值得关注的战略信号

即便暂不采信“Harness已于8月20日开源”的说法，OpenAI的产品方向仍然清晰：开发者不必局限于ChatGPT或Codex的现成界面，也可以通过API和SDK，把模型的计划、工具调用、代码执行、状态管理与错误修复能力嵌入自己的产品。

这意味着，未来的编码智能体可能不只是一个“回答问题的聊天窗口”，而是能在特定工程流程、内部运营流程或受监管业务流程中持续执行任务的运行系统。只是，关于Apache 2.0 Harness的具体发布事实和组件范围，在出现正式官方公告、代码仓库或许可证文件之前，仍应保持审慎判断。