🍃作者介绍：AI 应用负责人/AI产品架构师，阿里云专家博主。专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。
🦅个人主页：@逐梦苍穹
🐼GitHub主页：https://github.com/XZL-CODE
✈ 您的一键三连，是我创作的最大动力🌹

1、前言

最近，一些文章把 OpenAI 的新公告概括成了：“全面开源 Codex Harness”“一口气放出三大组件”“把顶级 Agent 发动机免费送给开发者”。

这些说法不能算凭空捏造，但确实把一场平台化发布，包装成了一次源码大解禁。

因为 Codex CLI 本来就是开源项目，codex exec 早已可以跑脚本和 CI，Codex SDK 早已可以嵌入系统，App Server 也不是公告当天才出现在仓库里。

所以真正值得讨论的问题不是“OpenAI 开没开源”，而是：

当源码早已公开、调用路径早已存在时，这次公告到底新在哪里？

我的结论先放在这里：

OpenAI 不是突然公开了一套过去拿不到的秘密 Harness，而是把已经逐步开放的 Codex 执行体系，正式收口成一套有明确入口、文档和产品定位的 Agent Platform。

这仍然很重要，只是重要的原因和“突然全面开源”不是一回事。

2、30 秒看懂：这次到底发布了什么

2.1 三句话先划清边界

第一，Harness 的代码本体没有突然换地方。 Codex CLI、SDK 和 App Server 的开源部分仍位于 Codex 的公开工程体系中。OpenAI 当前的开源清单也明确列出了这些组件，同时明确标注 IDE Extension 与 Codex Cloud 并不开源。

第二，这次真正强化的是平台定位。 OpenAI 在 2026 年 8 月 19 日发布的官方文章标题就是“Codex as a platform”。重点不是“今天第一次让你看到源码”，而是正式告诉第三方开发者：可以把同一套 Agent Harness 嵌入业务系统、运营看板、安全平台和内部工具。

第三，开源 Harness 不等于免费模型。 官方明确区分：开源的是 Harness 和集成层，模型访问、账号额度与托管服务仍是另一层。源码能改、能商用，不代表模型算力从此免费。

2.2 先别研究概念，直接按场景选入口

你的需求	应选入口	一句话理解
脚本、CI、定时任务、一次性后台任务	codex exec	把 Codex 当命令执行
在 TypeScript / Python 代码里启动、继续或恢复任务	Codex SDK	把 Codex 当编程能力调用
Agent 是产品本身的一部分，需要自定义 UI、事件流和审批	codex app-server	把 Codex 当 Agent Runtime 接入

最轻量的入口仍然是：

codex exec --json "分析当前仓库并输出风险清单"

需要程序化控制时，可以安装 SDK：

npm install @openai/codex-sdk
pip install openai-codex

需要直接控制底层线程、事件和审批时，才考虑：

codex app-server

这三个入口不是三套不同的 Agent，更不是三台刚刚开源的“发动机”。它们只是同一套 Codex Harness 面向不同集成深度的三种入口。

3、Harness 到底是什么

3.1 Agent 不等于“模型 + Prompt”

一个真正能持续工作的 Agent，至少要处理这些问题：

• 如何收集、保留和压缩上下文；
• 如何维持 Agent Loop，让模型持续推进任务；
• 如何发现、调用并观察工具；
• 如何执行命令和修改文件；
• 如何管理 Thread、Turn 与历史状态；
• 如何流式返回进度；
• 如何执行沙箱、权限和人工审批；
• 如何处理中断、恢复、失败与重试。

模型负责推理，Harness 负责让推理在一个可运行、可观察、可约束的系统里发生。

所以把 Harness 叫“外骨骼”不算错；错的是进一步把它说成“模型装上以后通用智能直接提升三倍”。

3.2 “分数提升近三倍”应该怎么读

OpenAI 官方文章给出的数据是：在 ARC-AGI-3 的特定设置中，保留推理与上下文压缩让 GPT-5.6 Sol 的分数从 13.3% 提升到 38.3%，同时输出 Token 减少到原来的约六分之一。

这个结果能证明：Harness 设计会显著影响 Agent 在特定任务上的有效能力和成本。

但它不能直接推出：

• 模型的通用智能提高了三倍；
• 所有任务都会获得同样增益；
• 接入 Codex Harness 就能自动复制该成绩。

把“某个基准、某套配置下的分数约为原来的 2.88 倍”，翻译成“AI 变聪明三倍”，是典型的传播层放大。数字没有造假，结论却被偷偷换了。

4、exec、SDK、App Server 到底有什么区别

4.1 codex exec：一次性、非交互式入口

codex exec 适合边界明确的自动化任务。它可以把最终结果输出到标准输出，也可以通过 --json 返回 JSONL 事件流，方便流水线消费。

典型场景包括：

• CI 检查；
• 发布说明生成；
• 定时巡检；
• 一次性代码审查；
• 结构化结果提取。

它的优势是简单，进程的开始和结束也天然构成任务边界。它不是这次才出现的新组件，只是被官方重新放进了“Codex 平台三层入口”的选择指南里。

4.2 Codex SDK：高级编程封装

SDK 适合在业务代码中启动、继续和恢复 Codex Thread，并接收流式结果。它隐藏了大量进程通信和协议细节，开发成本明显低于自己实现 App Server 客户端。

这里有一个很容易被忽略的细节：“Codex SDK”是接口层概念，不代表所有语言的 SDK 内部实现完全相同。

当前官方 Python SDK 的关系非常明确：

Python 业务系统
      ↓
openai-codex Python SDK
      ↓ JSON-RPC
本地 codex app-server
      ↓
Codex Harness / Core

官方文档说明，Python SDK 会控制本地 App Server，并随稳定版固定一个匹配的 Codex CLI Runtime。也就是说，你使用 Python SDK 时，通常已经间接使用了 App Server，只是不用自己处理底层协议。

4.3 App Server：面向产品的底层协议

App Server 的定位不是“再提供一个发 Prompt 的 API”，而是把 Codex 的运行能力通过双向协议暴露给你的产品。

应用可以：

• 创建、恢复和读取 Thread；
• 启动、中断或追加 Turn；
• 接收消息增量、工具调用和文件修改事件；
• 在自己的界面中显示审批请求；
• 决定哪些动作批准、拒绝或取消；
• 自己管理产品中的认证、状态展示和用户体验。

官方协议采用类似 JSON-RPC 2.0 的双向消息，默认通过 stdio 传输 JSONL，也提供 Unix Socket 与 WebSocket 入口。

但工程上必须看清一行小字：当前官方文档仍把 App Server 命令与 WebSocket 传输标记为 experimental，并说明不支持生产工作负载。 部分方法和字段也需要显式开启 experimentalApi。

这和“零门槛接入、企业最后一公里已经打通”显然不是同一种语气。

4.4 SDK 和 App Server 为什么看起来很像

因为它们本来就是同一技术栈的上下两层，而不是竞争关系。

维度	Codex SDK	codex app-server
抽象层级	高级客户端封装	底层服务进程与协议
主要接口	Thread、Turn、Run、Stream 等对象或方法	请求、响应、通知与审批事件
进程与版本	通常由 SDK 帮你处理	客户端需要自行管理和适配
开发成本	低	高
控制粒度	满足常规嵌入	可控制完整生命周期和交互体验
适合场景	后台自动化、内部工具、常规业务集成	IDE、桌面端、复杂业务前端、多语言客户端

一个直观类比是：

PostgreSQL Server  ↔ psycopg
Docker Engine API ↔ Docker SDK
codex app-server  ↔ Codex SDK

如果 SDK 已经满足需求，没有必要为了“更底层”而手写 JSON-RPC。直接接 App Server 不会让模型突然更聪明，只会让你获得更多控制权，以及与控制权配套的维护成本。

5、所以，这次真正“新”在哪里

5.1 没变的部分

• Harness 仍是 Codex 公开工程体系中的执行核心；
• codex exec 仍是原来的非交互式入口；
• SDK 早已能嵌入应用；
• App Server 也不是公告当天才写出来；
• 本地入口最终仍要访问模型服务；
• 账号、额度、模型与托管服务没有因为开源而免费。

5.2 变化的部分

• 官方定位变了：Codex 不再只被描述为 CLI、IDE 或 Coding Agent，而是一套可以嵌入专业软件的 Agent Platform；
• 集成层次被说清楚了：exec、SDK、App Server 分别对应命令、代码与产品级集成；
• 接口边界更正式了：文档开始系统描述线程、事件、审批、协议和稳定 / 实验能力；
• 分发方式更成熟了：Python SDK 提供稳定 PyPI 包，并固定配套 Runtime；
• 应用边界扩大了：官方主动展示物流、税务、运营和安全等非纯编程场景。

5.3 “代码在 GitHub”与“可以作为平台依赖”不是一回事

这是整件事最容易被忽略、也最值得开发者理解的地方。

源码在公开仓库里，代表你可以阅读、修改和自行构建；但一个第三方产品真正敢依赖它，还需要：

• 可安装的发行包；
• 有文档的调用协议；
• 明确的稳定与实验边界；
• 配套的类型或 Schema；
• 版本组合与兼容性处理；
• 官方认可的第三方集成定位。

所以这次不能简单说成“什么都没发生”。更准确的说法是：

发动机早已放在仓库里，这次补上的，是插头、仪表盘、说明书，以及“允许你把它装进自己产品”的正式产品定位。

6、对几种营销式说法的逐项判断

常见说法	判断	更准确的表达
OpenAI 全面开源了 Codex	不准确	开源的是 Harness 与部分集成层，不包括模型权重、IDE Extension 和 Codex Cloud
OpenAI 突然全面开源 Codex Harness	半真半假	Harness 确实开源，但相关组件此前已持续公开演进；这次重点是平台化发布
一口气放出三大开源组件	明显夸张	exec、SDK、App Server 是同一运行体系的三种入口，也不是公告当天集体诞生
把最强 Agent 发动机免费送给开发者	容易误导	Harness 代码开放，但模型访问、订阅额度与托管服务仍需单独承担
Harness 让 AI 聪明了三倍	过度外推	特定基准分数约为原来的 2.88 倍，不等于通用智能提高三倍
Agent 零门槛时代来了	情绪表达	接入成本下降了，但权限、状态、恢复、审计与业务验收没有消失
Codex 能进入非编程业务软件	基本正确	这正是官方此次平台定位升级的核心

这里不需要否定这次发布的价值，也没有必要把正常的平台演进说成人类文明的又一次奇点。

最有信息量的判断，通常位于“什么都没发生”和“世界彻底改变”之间。

7、这次发布真正重要的产品信号

7.1 业务界面本身就是上下文

官方展示的 Relay 物流看板使用的是虚构数据，但它表达的产品方向非常真实：用户不需要先打开聊天框、重新描述整个业务背景，而是直接在货单、告警、记录或任务卡片上触发 Agent。

界面告诉 Agent 用户正在看什么；业务系统提供事实和工具；Harness 负责循环、流式执行与审批。

这比“给所有系统右下角塞一个聊天机器人”更接近真正的 AI 原生产品。

7.2 产品不能把事实和权力全部交给 Agent

官方架构图里有一句非常关键的话：应用拥有产品上下文、业务规则与工具，App Server 提供 Agent Loop 和沙箱执行。

换成工程语言，就是：

• 模型负责理解、判断和生成；
• Harness 负责循环、上下文、工具调度与审批衔接；
• 业务系统继续负责事实源、状态、权限、审计和最终写入；
• 高风险动作必须经过确定性规则或人工批准。

这才是企业 Agent 的正确边界。Harness 可以帮你少造一套运行时的轮子，但它不应该取代业务系统的事实治理。

7.3 “最后一公里”并没有自动消失

即使直接采用 App Server，产品团队仍然要处理：

• 进程托管与健康检查；
• 协议和版本适配；
• 状态持久化与异常恢复；
• 权限、凭证、审计与数据边界；
• 人工审批的交互设计；
• 失败样本、评测与业务验收；
• 成本、时延与并发控制。

所以更诚实的说法是：

Codex Harness 降低了重建 Agent Runtime 的成本，但没有替你完成产品工程。

8、如果你早就在用 Codex，这次需要改什么

8.1 已经在服务器使用 exec 或 SDK

如果你的现有结构是：

服务器登录 Codex / 配置认证
        ↓
codex exec 跑自动化任务
        或
Codex SDK 嵌入 Python / TypeScript 系统

那么这次没有带来“从不能做到能做到”的质变，也不需要为了追热点重写系统。

你真正获得的是：

• 更明确的官方选型边界；
• 更成熟的 SDK 与 Runtime 配套；
• 更完整的协议和事件文档；
• 更清晰的稳定 / 实验能力标记；
• 更确定的第三方产品集成方向。

8.2 什么时候才值得直接接 App Server

只有当你明确需要下面这些能力时，直接接 App Server 才更有价值：

• 在前端实时展示每一步 Agent 状态；
• 自己实现文件修改、命令执行和工具调用视图；
• 自己设计人工审批、打断与恢复体验；
• 使用 SDK 尚未覆盖的底层协议能力；
• 用非 Python / TypeScript 技术栈开发深度客户端；
• 让一个产品长期管理多个 Thread。

如果 SDK 已经完整满足需求，继续使用 SDK 就是更稳妥的选择。抽象层存在的意义，就是让大多数人不用亲自承担底层自由的全部代价。

9、总结：不是源码发布，而是平台发布

回到最初的问题：Codex Harness 这次到底开源了什么？

严格来说，它不是突然从闭源变开源，也不是把三个全新组件在一天内扔进 GitHub。

这次真正发生的是：

OpenAI 把早已开源、早已可以调用的 Codex 执行体系，完成了平台化定位、接口文档化、分发稳定化和支持边界收口。

对第一次接触 Codex 的开发者，这是一个更清晰、更可靠的入口；对早就在服务器上运行 codex exec、或者已经通过 SDK 嵌入系统的人，更像是官方终于宣布：

你们已经做了一段时间的事情，现在正式成为产品路线了。

这件事依然重要。因为它意味着 Codex 正从“一个你打开来使用的工具”，转向“一个可以被其他软件嵌入和重新设计交互的 Agent Runtime”。

只是下一次再看到“全面开源”“零门槛”“彻底打通最后一公里”，不妨先把发布标题放到一边，去看三样东西：仓库历史、接口文档和开源边界。

情绪负责让你点开文章，工程事实才负责告诉你到底发生了什么。

10、参考资料

• OpenAI 官方博客：Codex as a platform: build on the open agent harness
• OpenAI 官方文档：Codex Open Source
• OpenAI 官方文档：Codex SDK
• OpenAI 官方文档：Codex App Server
• OpenAI 官方文档：Non-interactive mode / codex exec

注：本文依据 2026 年 8 月 21 日可见的官方资料整理。App Server、SDK 与实验能力仍可能快速演进，实际接入前请以最新官方文档为准。