《Codex as a platform: build on the open agent harness》

直译过来就是：

“把Codex当作平台：基于开放的Agent Harness构建产品。”

这篇文章释放的信号，其实比“Codex又更新了一个功能”重要得多。

因为OpenAI这一次明确告诉开发者：

不要只把Codex当成一个App、CLI 或 IDE插件。真正值得复用的是它下面那套Agent Harness。

OpenAI甚至直接把Codex Harness称为open-source Codex harness，并表示Codex App、CLI、IDE等产品底层都是由同一套Harness驱动。

这意味着AI Agent正在发生一个很明显的变化。

过去大家竞争的是：

谁的模型更聪明。

接下来可能越来越变成：

谁能把聪明的模型真正组织起来干活。

而负责这件事的，就是Harness。

一、先不要管术语：Harness 到底是什么？

很多人第一次看到Harness，会误以为它是：

一个新模型。

或者一个新的Agent框架。

其实都不完全准确。

最简单的理解方式是：

模型是Agent的大脑，Harness是让这个大脑真正工作起来的运行系统。

一个普通的大模型，本质流程非常简单：

用户 ↓Prompt ↓LLM ↓生成答案

比如：

帮我分析一下这份简历。

模型读取内容，然后生成一段回答。

到这里就结束了。

但如果要求AI：

帮我分析简历、搜索适合的岗位、针对不同岗位调整简历、填写申请，并在真正投递前让我确认。

事情就完全不一样了。

系统需要运行：

用户提出目标       ↓理解任务       ↓读取简历       ↓调用岗位搜索工具       ↓获取搜索结果       ↓分析岗位要求       ↓决定下一步       ↓修改简历       ↓调用浏览器       ↓填写申请       ↓请求用户确认       ↓执行投递

这已经不是一次Prompt可以完成的事情。

模型必须不断经历：

思考↓行动↓观察结果↓继续思考↓再次行动

而负责维持这个循环的东西，就是 Harness。

OpenAI 在8月19日的文章里给出了非常清楚的定义：

一个真正有能力的Agent，不只是Prompt加模型响应。它还需要维持上下文、检查信息、调用工具、展示执行进度、处理失败、请求人工审批，并最终返回结果。

包围模型的这一整套执行系统，就是Harness。

二、为什么Harness突然重要起来？

因为模型已经开始从：

“回答问题”

走向：

“完成任务”。

两者对基础设施的要求完全不同。

ChatGPT 时代，一个回答可能几十秒结束。

Agent 时代，一个任务可能运行：

5 分钟、30 分钟，甚至几个小时。

过程中可能：

读取几十个文件；

执行几十次命令；

调用多个 API；

失败并重试；

等待用户确认；

暂停之后继续；

甚至在用户关闭浏览器以后仍然运行。

这时候真正困难的问题就不再只是：

Prompt 应该怎么写？

而是：

Agent 做到一半断了怎么办？

怎么知道现在执行到了第几步？

怎么避免重复操作？

哪些工具可以调用？

哪些操作必须得到用户批准？

Agent 如何保存上下文？

上下文太长以后怎么办？

这些都是 Harness 要解决的问题。

三、一个数据，能直观看出 Harness 有多重要

OpenAI 在8月19日这篇文章里放了一个非常有意思的数据。

在ARC-AGI-3测试中，仅仅通过改进 Harness 中的：

retained reasoning（保留推理状态）

以及：

context compaction（上下文压缩）

GPT-5.6 Sol 的成绩就从：

13.3%

提升到了：

38.3%。

与此同时，输出 Token 数量降低到了原来的大约六分之一。

注意这里发生了什么。

模型没有换。

还是同一个模型。

变化的是：

模型外面的 Harness。

但最终成绩接近原来的三倍。

这说明一个越来越重要的问题：

同一个模型，放进不同的 Harness 里，最终表现可能完全不同。

所以以后评价 Agent，不能只问：

“你用的是什么模型？”

还要问：

“你给这个模型搭了什么运行环境？”

四、Codex Harness 具体管什么？

Codex Harness 现在负责的事情已经远远不只是 Agent Loop。

OpenAI 在今年 2 月第一次系统公开 Codex Harness 架构时，就介绍了它几个重要组成部分。

其中之一是：

Conversation State

Agent需要知道：

之前做过什么；

现在做到哪里；

下一步应该干什么。

Codex内部使用类似：

Thread ↓Turn ↓Item

这样的结构维护任务。

一个 Thread，可以理解成一个持续存在的 Agent 工作会话。

例如：

Thread：帮我开发招聘系统

里面可能持续很多轮：

分析项目↓修改数据库↓开发简历解析↓运行测试↓修复Bug↓继续开发

即使客户端断开，任务状态仍然能够被保存和恢复。

这对于真正的 Agent 产品至关重要。

五、还有一个非常重要的能力：Approval

假设你的 Agent 可以帮助用户投简历。

Agent找到了一个岗位：

某 AI 公司职位：AI Agent Engineer地点：上海薪资：30K-50K

Agent填好了所有信息。

接下来要执行：

submit_application()

如果没有 Harness，模型可能直接调用工具。

但真正的生产系统不能这么设计。

因为：

“查看岗位”和“正式提交申请”不是一个风险等级的行为。

于是 Harness 可以规定：

读取岗位→ 自动允许分析简历→ 自动允许生成修改建议→ 自动允许真正投递→ 必须人工确认

于是用户看到：

即将向 XX 公司提交申请使用：resume_ai_agent_v3.pdf是否确认？[确认投递][取消]

用户确认后，Agent才能真正执行。

Codex App Server 本身就支持这种双向 Approval 流程：Agent 可以暂停 Turn，向客户端请求批准，然后等待用户返回结果。

这其实是 Harness 和普通“LLM 调工具”之间非常大的区别。

六、8 月 19 日真正的新东西是什么？

这也是这次消息最值得关注的地方。

以前我们使用 Codex，大多数情况下是：

开发者 ↓Codex App ↓Harness ↓模型

或者：

开发者 ↓Codex CLI ↓Harness ↓模型

也就是说：

Harness 是藏在 Codex 产品里面的。

但 OpenAI 现在明显开始强调另一个方向：

你的产品 ↓Codex Harness ↓模型

官方甚至直接写道：

与其让所有团队把工作搬进一个通用 Coding Assistant，不如把 Agent 放进用户原本就在使用的软件里。

这个区别非常大。

七、还是拿简历投递系统举例

以前做 AI 简历系统，我们可能会设计：

用户 ↓网页 ↓后端API ↓GPT

用户上传简历。

GPT分析。

然后输出：

你的简历建议如下……

这实际上还是一个 AI 功能。

不是真正的 Agent。

如果基于 Harness 做，系统可能变成：

简历投递系统                    ↓              Resume Agent                    ↓              Codex Harness         ┌──────────┼──────────┐         ↓          ↓          ↓      简历工具    岗位工具    Browser         ↓          ↓          ↓       PDF       Job API     招聘网站         └──────────┼──────────┘                    ↓                 Agent Loop

用户只需要说：

帮我找上海适合我的 AI Agent 岗位。

接下来 Agent 自己判断：

先读取简历。

然后抽取：

PythonPyTorchLLMRAGAgentDocker

接着搜索岗位。

假设搜索到 120 个职位。

Agent继续调用工具筛选。

最后发现：

岗位A：91%岗位B：88%岗位C：84%

然后针对岗位A分析 JD。

发现招聘要求里强调：

AgentMCPTool CallingDocker

Agent再回头检查简历。

发现：

Docker经验写得不明显。

于是建议重新组织项目描述。

然后生成：

resume_company_A.pdf

接下来填写申请。

到了最终提交之前：

Harness触发 Approval。

用户确认。

然后才真正投递。

这就是：

Agent 产品。

八、这也回答了一个很常见的问题：为什么不直接在 Codex 里做？

答案其实已经非常明显了。

如果你的目标是：

帮我开发一个简历投递网站。

直接用 Codex。

完全没问题。

Codex 是你的程序员。

但是如果你的目标是：

我要做一个给 10 万用户使用的 AI 简历投递产品。

情况就不同了。

你不能要求用户：

下载Codex↓打开Terminal↓clone你的repo↓输入prompt

用户需要看到的是：

我的简历推荐岗位投递记录待确认面试进度

Agent应该藏在产品后面。

所以最终结构变成：

你的UI+你的业务逻辑+你的数据库+你的工具+你的审批规则        ↓Codex Harness        ↓Agent Loop        ↓Model

这正是 OpenAI 8 月 19 日强调的架构。

OpenAI给出的原则非常清楚：

你的应用负责产品上下文、业务规则和工具；Codex App Server负责 Agent Loop 和沙箱执行。

这句话基本就是 Harness 这件事情的核心。

九、现在开发者有三种方式使用 Codex Harness

OpenAI 在最新文章里实际上已经把路线划得比较清楚了。

如果只是跑一个一次性的自动任务，可以使用：

codex exec

例如：

检查这个仓库里的安全漏洞

运行结束就退出。

如果需要在自己的后端程序里启动、恢复或者流式获取 Codex 任务，可以使用：

Codex SDK

如果你的 Agent 本身就是产品的一部分，需要：

长期会话；

事件流；

中断；

工具调用；

用户审批；

状态管理；

那么 OpenAI推荐使用：

Codex App Server

App Server给开发者更完整地暴露 Harness 生命周期。

这也是为什么这次 OpenAI 使用了：

Codex as a platform

而不仅仅是：

Codex as a coding assistant。

十、这已经不只是 Coding 了

文章里还有一个很值得注意的变化。

OpenAI举的场景已经明显不只是：

写代码。

他们直接举出了：

安全调查；

运维；

客户支持；

内部业务系统；

研究工作流；

账号运营；

销售；

营销。

甚至 OpenAI 还做了一个叫Relay的 Demo。

Relay 是一个虚构的物流运营系统。

Agent被直接嵌在物流 Dashboard 里。

当某个货运任务出现异常时，它可以查看数据、比较解决方案，然后提出重新安排运输的建议。

如果涉及真正修改运输记录，就必须获得人工批准。

注意这里已经几乎看不到“Coding Assistant”的影子了。

它更像：

企业业务 Agent Runtime。

十一、已经有人开始这么用了

OpenAI 在文章里披露了一个真实案例。

Thrive Holdings 和 Crete 将 Codex 集成进报税工作流。

这个试点一共处理了：

7000 份税务申报。

结果是：

准备时间减少了大约三分之一。

这个案例很有意思。

因为它证明 Codex 正在从：

写代码

开始走向：

处理实际业务流程

这也是 Harness 开放以后真正值得关注的方向。

十二、为什么 OpenAI 会在现在开放这一层？

因为模型能力正在越来越快地商品化。

今天最强的是模型A。

半年以后可能变成模型B。

但是企业真正难以复制的东西其实是：

企业数据业务规则工作流程工具权限体系评价体系用户界面异常处理机制

这些东西组合起来，就是一个业务 Harness。

所以未来 Agent 产品可能会越来越像：

企业应用                   ↓                Harness      ┌────────────┼────────────┐      ↓            ↓            ↓   Context       Tools       Permission      ↓            ↓            ↓   Memory       Workflow      Evals      └────────────┼────────────┘                   ↓                  LLM

模型会变。

Harness 却可能成为企业长期积累的资产。

十三、Prompt Engineering 之后，可能是 Harness Engineering

过去几年 AI 工程经历了几个明显阶段。

最开始大家研究的是：

Prompt Engineering。

然后 RAG 出现以后，大家开始研究：

Context Engineering。

现在 Agent 开始真正执行任务以后，又出现了一个新的工程问题：

Harness Engineering。

它关注的已经不是：

怎么问模型一个好问题？

而是：

怎么给模型设计一个能够稳定工作的世界？

包括：

工具；

环境；

权限；

状态；

反馈；

测试；

评估；

恢复机制；

人工确认机制。

OpenAI 在 2026 年 2 月 11 日公开的一项内部实验，很好地说明了这个趋势。

他们从 2025 年 8 月底的一个空 Git 仓库开始，让 Codex 完成全部代码工作。

五个月后：

代码规模约100 万行；

约1500 个 Pull Request被合并；

最初只有3 名工程师负责驱动 Agent；

平均每名工程师每天约3.5 个 PR。

OpenAI估计，这个项目的开发速度大约是传统人工编码方式的10 倍。

但最后他们得到的最大经验并不是：

Codex 写代码特别快。

而是：

工程师越来越需要设计 Agent 能够成功工作的环境、约束和反馈循环。

这正是 Harness Engineering。

结语

2026 年 8 月 19 日这篇文章真正值得关注的地方，不是 OpenAI 又发布了一个开发组件。

而是 Codex 的定位正在发生变化。

以前：

Codex=AI程序员

现在：

Codex=可以嵌入其他产品的Agent Runtime

而其中真正被复用的核心，就是：

Harness。

所以如果只记住一句话：

模型决定 Agent 有多聪明，Harness 决定这个聪明的 Agent 能不能真正进入业务系统干活。

当 AI 只是回答问题时，我们最关心的是模型。

当 AI 开始操作电脑、调用系统、修改数据、执行任务之后，我们真正需要解决的问题就变成：

它能做什么？

它什么时候做？

它做到哪里了？

失败以后怎么办？

谁来批准？

怎样验证结果？

这些问题的答案，不在模型里。

而在 Harness 里。

这也可能是为什么，在 2026 年这个时间点，OpenAI 开始明确把 Codex 从一个 Coding Agent，推向一个open agent harness platform。

AI Agent 下一阶段真正的竞争，或许才刚刚开始。