2026 年 8 月 19 日至 20 日，OpenAI 发布博客《Codex as a platform: build on the open agent harness》，宣布把 Codex 背后的 Agent 执行框架——Harness——以 Apache-2.0 协议全面开源，仓库就是 github.com/openai/codex。

截至 8 月 23 日，这个仓库 11.36 万 star、1.74 万 fork，主体是 Rust（codex-rs/ 下约 60 个 crate），另带 TypeScript 和 Python 两套 SDK。

数字很漂亮，但真正值得琢磨的不是数字，是OpenAI 选择开源哪一层、不开源哪一层。

一、先把「开源了什么」说清楚

仓库本身 2025 年 4 月就建了，那时候放出来的只是 Codex CLI 的前端源码。这次不一样，打开的是运行时本身。

开源的部分（全部 Apache-2.0）：

没开源的部分：

• 模型。推理照样要 ChatGPT 订阅或 API key。官方宣传里那组亮眼数据跑的是 GPT-5.6 Sol，模型本身闭源。
• 系统提示词。Harness 往模型脑子里塞什么、怎么塞，不公开。
• 云端服务。chatgpt.com 上的 Codex Web / Codex Cloud 不开源。
• IDE 扩展内部实现。VS Code、Cursor、Windsurf 那几个插件的内部代码不开源。

所以中文社区那句吐槽是准确的：开源了壳，没开源核。

但「壳」这个说法容易让人低估这件事。因为 OpenAI 这次想论证的恰恰是——壳才是差异化的地方。

二、13.3% → 38.3%：Harness 才是变量

官方公告里最有说服力的是这组数字：

同一个 GPT-5.6 Sol 模型，Harness 层只加了两项优化——保留推理状态（retained reasoning）和上下文压缩（context compaction）——ARC-AGI-3 得分从 13.3% 涨到 38.3%，输出 token 降到原来的约六分之一。

分数接近三倍，成本降到六分之一，模型一行没动。

这组数字是整篇公告的论证核心：决定 Agent 能不能干活的，不是模型有多聪明，是外面这层运行时会不会调度。OpenAI 对「一个能干活的 agent」给的定义也是这个意思——它得能理解任务、跨时间维持上下文、检索信息、调用工具、暴露进度、处理失败、必要时请求人类审批、最后返回有用的结果。

这清单里没有一项是模型单独能做到的，全是 Harness 的活。

那么问题来了：既然 Harness 这么关键，为什么要开源？

三、OpenAI 在赌什么

公告里有一句话把动机说得比较透（转引自 36kr 的报道）：

与其让每个团队把熟悉的工作流硬搬到通用的代码助手上，不如把 agent 直接带进围绕实际工作设计的软件里。

翻译成大白话：别来用我的产品，让我的 agent 循环住进你的产品。

Greg Brockman 在 X 上补了一句更直接的："Codex can power far more than programming tools."

拆开看，至少三层算盘：

第一，抢占执行层这个位置。 模型层已经卷成红海，各家分数咬得很紧。但「模型什么时候被调用、以什么顺序调用、调用失败怎么办」——这个决策权在 Harness 手里。谁的 Harness 被最多产品内嵌，谁就掌握了调用的分发权。这跟当年浏览器内核之争是同一个逻辑。

第二，数据闭环。 一个纯 API 调用，OpenAI 只能看到一次请求和一次响应。但 Harness 跑在你的机器上，它能看到完整的执行链路：任务怎么被拆解、工具怎么被调用、哪一步失败了、人类在哪里介入审批。这份数据对训练下一代模型的价值，远高于孤立的 prompt-completion 对。

第三，标准化即防御。 Claude Code、Gemini CLI、Cursor、DeepSeek Harness 都在抢同一块地。开源是拉拢生态最快的手段——尤其当你的竞争对手里，有人已经开源了。

配套动作也印证了这个判断：OpenAI 同期推了 Codex for OSS 计划，给通过审核的开源维护者发 API 额度和 ChatGPT Pro。这不是慈善，是在给自己的运行时铺装机量。

四、这一层的竞争格局

把主要玩家摆在一起看：

DeepSeek Harness 的发布只比 Codex Harness 早约六天。两家几乎同时把运行时开源，这个时间点上的巧合，本身就说明这条赛道的紧迫感。

国内有个比喻流传得很广，出自腾讯科技的分析：DeepSeek 要做安卓，Codex 要做 iOS。

意思是 DSH 深度开源、连底层都能换，走的是「你自己拼一台」的路子；Codex 则是把核心发动机调校好了给你，外围可以插，但得按它的接口来适配。

这个比喻挺贴切，但也提醒了一件事：iOS 的护城河从来不是开源不开源，是生态和体验。Codex Harness 能不能守住这个位置，取决于 app-server 协议会不会成为事实标准，而不是取决于 star 数。

有意思的是，社区已经有人反过来把 Codex 收编成 DSH 的子代理（dsh-bridges 之类的项目）。运行时之间互相套娃，这大概是开源生态特有的景观。

五、几个真实的质疑

质疑一：开源的价值有多少依赖闭源部分？

Harness 开源了，但你跑它还是得接一个模型。理论上配置里的 model_providers 支持任意 OpenAI 兼容端点，你可以接开源模型、接本地推理、接第三方中转。但 Harness 的调优、prompt 策略、工具调用格式全是围绕 GPT-5.6 Sol 打磨的——换个模型，那个「13.3% → 38.3%」还成不成立，没人保证。

开源的是路，不是车。 车还得从 OpenAI 买，或者你自己造一辆能开上这条路的。

质疑二：安全。

Malwarebytes 的 GM Mark Beare 对当前这批本地 Agent 工具的评价是「有点像西部荒野」。建议很朴素：把密码和敏感凭据隔离出去，别让 Agent 长时间无人值守地跑任务。

这个提醒不是空穴来风。Harness 默认要在你的真实文件系统上执行命令，沙箱和审批机制是唯一的闸门。OpenAI 自己的浏览器团队也在研究「confirmation policies」——在传输数据、删除内容这类动作前强制用户确认。

质疑三：早期开源项目的通病。

Codex Harness 好在已经在生产环境跑了几个月（Cisco、GitHub、JetBrains 都是已接入的客户；Thrive Holdings 用它处理了 7000 份报税，准备时间省了约三分之一）。相比之下 DSH 还是开发者预览版，社区反馈里「速度慢、token 消耗高」的抱怨不少。

但成熟也意味着包袱。Codex 的配置项在过去一年改过好几轮，网上流传的 2025 年教程有相当一部分已经失效——比如 approval_policy 的取值，老文档里的 always / on-failure / untrusted 在当前 schema 里已经完全不存在了。

六、对不同的人，这件事意味着什么

如果你是独立开发者：多了一个不用自己造轮子的选项。沙箱、审批、会话持久化、MCP 集成，这些基础设施自己实现一遍至少几个月，现在 curl | sh 就能装。

如果你在做产品：app-server 那层值得认真看。它的三个原语——Thread（会话）、Turn（轮次）、Item（原子事件）——设计得相当干净，JSON-RPC 协议也稳定。把 Agent 能力嵌进现有产品，这是目前门槛最低的路径之一。

如果你在企业里推 AI：真正的价值在审批和沙箱这两块。sandbox_mode 三档（只读 / 工作区可写 / 完全放行）加上 execpolicy 规则引擎，能让「让 AI 改生产代码」这件事从不可讨论变成可讨论。合规部门要的不是模型多聪明，是出事的时候闸门在哪。

如果你在观察行业：记住这个判断——2026 年下半年，AI 竞争的主战场从模型层搬到了运行时层。三家头部公司在同一个月里做同一件事，不会是巧合。

本文事实核对自 openai/codex 仓库（Apache-2.0，2026-08-23 数据）及官方公告的公开转述。由于 developers.openai.com 在部分网络环境下不可达，公告原文引述参考了 36kr、腾讯科技、七牛云等来源的转引，引用时建议再核对一次原文。