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

发布日期：2026-08-23 06:37:22 浏览次数： 1919

作者：安於然AIR

微信搜一搜，关注“安於然AIR”

提到 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 工具获取数据、解释可选方案；如果要真正改订货运，则必须先获得人工批准。

在这个过程中：