开源模型

Codex 不只是编程助手：开源 Harness 让你把 Agent 嵌进自己的产品

2026 年 8 月 23 日

OpenAI 于 2026 年 8 月 19 日发布 Codex Harness 开源计划，开放的是模型与应用之间的运行时支架（Agent Loop），而非模型本身。核心组件包括 codex exec（命令行非交互模式）、Codex SDK（TypeScript 后端集成）和 Codex App Server（产品级双向事件协议），分别适配脚本自动化、服务化工作流与界面嵌入场景。

提到 Codex，很多人的第一反应还是一个会写代码的聊天框：在终端里输入需求，看它读文件、改代码、跑测试。

2026 年 8 月 19 日，OpenAI Developers 在 X 上发布了一篇题为Codex as a platform的文章，重点却不是再做一个更好看的编程界面，而是把 Codex 背后的Agent Harness作为开放的构建基础，让开发者把同一套 Agent 能力接进自己的脚本、CI、后台服务和业务产品。

这里需要先说清楚：Codex CLI 仓库此前已经开源。这次发布更像一次边界梳理与平台化宣言——官方明确告诉开发者，哪些运行时能力可以复用，哪些组件已经开放，以及应该从 codex exec、Codex SDK 和 App Server 中选择哪一层。

真正的变化不是“大家终于能看到 Codex 的代码”，而是：你不必把用户赶进一个通用聊天框，也能把 Codex 的 Agent Loop 带进现有工作流。

一、开源的不是模型，而是模型周围的运行支架

模型可以理解任务、生成文本和代码，但一个能长时间工作的 Agent 还要处理很多工程问题：

如何维护多轮会话和任务状态；
如何收集、压缩并延续上下文；
如何调用 Shell、文件、MCP 等工具；
如何持续输出进度，而不是长时间没有反馈；
如何限制文件、网络和命令权限；
哪些动作可以直接执行，哪些必须请人批准；
失败后如何中断、恢复或继续下一轮。

把这些能力围在模型外面的执行系统，就是Harness。

用户任务
    ↓
Harness：状态、上下文、工具、事件流、沙箱、审批
    ↓
模型判断下一步
    ↓
执行工具 → 返回结果 → 继续循环

因此，Codex Harness 的可复用部分不是某段神奇的系统提示词，而是完整的Agent Loop（智能体循环）。它管理会话状态、流式执行、工具调用、沙箱和审批，让模型能够“做一步、看结果、再决定下一步”。

官方文章还给出了一个很能说明问题的数据：在 ARC-AGI-3 测试中，为 GPT-5.6 Sol 保留推理并加入上下文压缩后，成绩从 13.3% 提升到 38.3%，同时输出 Token 降到原来的约六分之一。

这不是说任何任务都能获得同样增益，而是说明：模型不变，Harness 如何保留状态、整理上下文，也可能显著改变最终表现。

二、Codex 到底开源了哪些内容？

最核心的代码仍然位于openai/codex仓库，并采用 Apache-2.0 许可证。和“把整个 Codex 产品全部开源”相比，更准确的说法是：OpenAI 开放了 Harness 与集成层，但模型和托管服务仍然是独立部分。

从开发者构建 Agent 产品的角度，最值得关注的是三个组件：

组件	它提供什么	适合什么场景
Codex CLI / `codex exec`	可直接运行的 Agent，以及非交互式任务入口	脚本、CI、定时任务、一次性后台作业
Codex SDK	在 TypeScript 代码中启动、继续和恢复 Codex Thread	后端服务、内部工具、程序化工作流
Codex App Server	完整的会话生命周期、事件流、工具与审批协议	把 Agent 作为产品的一部分，接入自定义界面

官方的开源组件清单还包括 Codex Security CLI 与 TypeScript SDK、Skills、Plugins，以及 Codex Cloud 使用的基础环境 codex-universal。但并不是所有你见过的 Codex 产品界面都在开源范围内：

IDE 扩展没有开源；
Codex Cloud 没有开源；
模型权重和托管服务不属于这次开放的 Harness 层。

所以，这次开源最有价值的地方，不是让开发者复制一个 Codex 云服务，而是提供一套可以检查、调用和适配的 Agent 运行时。

三、三种接法，分别解决什么问题？

很多人看到 CLI、SDK 和 App Server，会以为它们只是同一种能力的三套包装。其实它们对应不同的控制深度。

1. codex exec：把 Agent 当成一条命令

如果需求是“在 CI 失败后分析日志”“每天生成仓库风险摘要”或“在合并前做一次检查”，不需要先开发完整应用，直接使用非交互模式即可：

codex exec "检查当前仓库，列出最需要关注的 5 个风险"

它可以把最终回答输出到标准输出，也可以用 --json 产生 JSONL 事件流，或用 --output-schema 约束最终结构，方便下游脚本继续处理。

codex exec --json "分析测试失败原因" | jq

这一路径的优点是简单、边界清楚。官方文档默认让 codex exec 在只读沙箱中运行；自动化需要写文件时，再显式开放 workspace-write。对于 CI 来说，这比一开始就给 Agent 完整机器权限更合理。

2. Codex SDK：把 Thread 放进后端代码

当应用需要主动发起、继续或恢复任务时，可以使用 TypeScript SDK：

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();

const first = await thread.run("分析 CI 失败并给出修复计划");
const second = await thread.run("按计划实施修复");

这里的关键不是少写几行命令，而是应用拿到了Thread（会话线程）。同一个任务可以继续运行，也可以通过 Thread ID 恢复过去的任务，而不必每次从零拼接全部上下文。

SDK 适合服务器端程序和内部自动化；如果只需要常见的启动、继续、恢复和流式处理，它比直接操作底层协议省事。

3. App Server：把 Agent 变成产品能力

如果你正在做一个真正带界面、权限和业务状态的产品，App Server 才是最值得研究的部分。

它通过双向 JSON-RPC 2.0 协议暴露 Codex 的生命周期。默认 stdio 传输使用逐行 JSON，也支持实验性的 WebSocket 和 Unix Socket。它把一次工作拆成三个核心对象：

Thread：用户与 Agent 的一段持续会话；
Turn：用户的一次请求，以及随后发生的 Agent 工作；
Item：消息、推理、命令执行、文件修改和工具调用等最小事件。

应用可以创建、恢复或分叉 Thread，开始或中断 Turn，持续接收 item/started、item/completed、消息增量和工具进度；当命令或文件修改需要批准时，App Server 还会向客户端发起请求，等待用户接受或拒绝。

这意味着你不必自己重新实现一套“会话状态 + Agent Loop + 流式事件 + 审批回调”，而可以把精力放在真正属于产品的部分。

需要注意的是，App Server 的 WebSocket 传输目前仍被官方标为实验性且不支持生产环境。远程部署也不能只开一个端口就结束，还要处理 TLS、认证、网络隔离和密钥管理。

四、Codex 负责循环，你的应用负责业务

OpenAI 给出的架构边界很清楚：

你的应用
├─ 用户界面：看板、队列、地图、工单、文档
├─ 业务上下文：当前记录、规则、权限、历史
├─ MCP 工具：读取数据、执行业务动作
└─ 人工确认：高风险操作的审批入口
             ↓
Codex App Server
├─ Thread / Turn / Item
├─ Agent Loop 与上下文状态
├─ 流式事件与工具交互
└─ 沙箱执行与审批请求
             ↓
模型与工具执行结果

官方示例 Relay 就采用了这个分工。它是一个虚构的物流运营面板：用户先选中异常货运记录，再点击“比较恢复方案”；应用把当前货运上下文交给 Codex，Agent 通过应用提供的 MCP 工具获取数据、解释可选方案；如果要真正改订货运，则必须先获得人工批准。

在这个过程中：

业务系统仍然拥有货运记录、界面和审批规则；
Codex 负责调查过程、会话状态、事件流和工具循环；
工具修改记录后，原来的业务界面正常刷新。

这和“在右下角加一个聊天机器人”有本质区别。用户不必重新描述自己正在看哪一条记录，也不必在聊天框里复制业务数据。界面本身就是上下文，按钮本身就是经过约束的意图入口。

五、为什么这比再做一个通用聊天框更重要？

通用编程助手要求人迁移到 Agent 的工作方式：打开聊天框、解释背景、粘贴材料，再监督它行动。

平台化的 Codex Harness 则允许 Agent 迁移到人的工作方式：

安全分析师仍然在告警队列里调查事件；
客服仍然在工单页面查看账号历史和产品日志；
产品团队仍然在任务看板里推进需求；
运营人员仍然在熟悉的业务面板里处理异常。

Agent 不再试图替换这些界面，而是读取当前工作现场，在原有权限和审批流程内完成调查、提出建议，必要时执行动作。

这也解释了为什么 OpenAI 把 Codex 称为一个平台：可复用的不是某个聊天 UI，而是 UI 后面那套能够持续工作、调用工具并接受约束的 Agent Loop。

六、开发者应该从哪一层开始？

可以用一个简单的选择顺序：

任务能用一条命令描述清楚：先用 codex exec，适合 CI、脚本和定时任务；
后端需要启动并恢复 Agent 任务：使用 Codex SDK，保留 Thread 与流式结果；
Agent 是产品体验的一部分：使用 App Server，自行设计界面、上下文、工具和审批流程。

无论选哪一层，都建议先做一个小而受限的闭环：

默认只读，只开放完成任务真正需要的权限；
把高风险写操作放到人工审批之后；
保留事件流、工具调用和最终结果，方便排查；
先验证一个具体工作流，再扩展更多工具和自动化；
不要因为 Harness 开源，就把它误当成已经替你解决了全部业务安全问题。

结语：Codex 的下一步，是从工具变成积木

过去，我们把 Codex 看成一个完成编程任务的产品。开源 Harness 展示了另一种用法：把它拆成一块可复用的 Agent 运行时，嵌进脚本、服务、看板、工单和内部系统。

codex exec 提供最短的自动化入口，SDK 让程序管理持续任务，App Server 则把 Thread、Turn、Item、事件流和审批暴露给自定义产品。开发者不必从零发明 Agent Loop，也不必照搬 Codex 的界面。

这次发布最值得记住的不是“Codex 全部开源了”，而是一个更准确的判断：

开放的是模型与应用之间的 Harness 和集成层；真正属于你的，是界面、业务上下文、工具与控制权。

参考资料

OpenAI Developers：Codex Harness 发布推文
https://x.com/OpenAIDevs/status/2090230646497251387
OpenAI：Codex as a platform — build on the open agent harness
https://developers.openai.com/blog/codex-as-a-platform
OpenAI Codex 开源组件清单
https://developers.openai.com/codex/open-source
openai/codex 官方仓库
https://github.com/openai/codex
Codex SDK 文档
https://developers.openai.com/codex/codex-sdk
Codex App Server 文档
https://developers.openai.com/codex/app-server
Codex 非交互模式文档
https://developers.openai.com/codex/non-interactive-mode

JOTO 企业落地观察

企业部署智能体时，Codex Harness 的分层接口（exec/SDK/App Server）意味着可按实际交付阶段渐进引入：初期用 CLI 快速验证工具链可行性，中期借 SDK 将 Agent 融入已有服务，后期以 App Server 实现与业务系统深度耦合。这种演进路径降低了首期投入风险。
这类系统的取舍关键在于「控制权归属」：App Server 虽提供完整事件流与审批回调，但企业需自行承担 TLS、认证与网络隔离等生产级运维责任；而 codex exec 的沙箱机制虽简化安全配置，却牺牲了会话连续性。团队需根据自身 DevOps 能力匹配层级。
对 RAG 知识工程而言，Harness 的上下文压缩与状态管理能力可减少冗余知识注入，但其本身不提供知识切片、向量化或检索逻辑——企业仍需在 MCP 工具层封装自有知识源的接入与过滤策略，Harness 仅保障该策略被稳定、可审计地执行。
AI 安全治理视角下，Harness 明确将「工具调用权限」与「人工审批触发点」作为可配置项，而非默认关闭。这意味着企业无需等待模型层安全升级，即可在运行时强制实施最小权限原则与关键动作双签机制。