Codex Harness 全面开源：思考、使用与竞品对比

OpenAI 把驱动自家顶级 AI 智能体的「发动机」免费送给了所有人。

2026年8月20日，OpenAI 正式宣布将 Codex 底层核心框架 Codex Harness 作为平台全面开源，采用 Apache-2.0 许可证，代码托管在 GitHub 的 openai/codex 仓库。OpenAI 总裁 Greg Brockman 在 X 上转发称：「Codex 能驱动的远不止编程工具！」

如果说两周前 DeepSeek Harness 的开源（MIT 许可）是国产厂商的「抢跑」，那么 OpenAI 这次的全面开放，则标志着 Harness 层正式成为 AI 行业的新战场。

一、为什么这次开源值得重视？

1.1 天下苦「通用聊天框」久矣

回想一下我们现在使用 AI 的方式：打开一个网页或侧边栏，面对一个单调的聊天输入框，敲下一段背景说明，然后期待 AI 给出完美答案。如果不对，就继续在聊天框里「拉扯」。

OpenAI 在官方博客中一针见血地指出：

与其要求每一个团队都把熟悉的工作流程强行搬进通用代码助手，不如把 Agent 直接带入围绕实际工作设计的软件里。

• 安全分析师看的是预警队列和受影响的服务状态；
• 客服工程师看的是账户历史和产品日志；
• 运营人员看的是业务看板和实时指标。

对这些真实的「打工人」来说，重要的不是聊天框，而是眼前的业务界面。界面本身就是最重要的上下文。

1.2 Harness 设计即性能：一组震撼的数据

很多人误以为：强大的 AI Agent = 好模型 + 好 Prompt。大错特错。

OpenAI 给出了极具说服力的数据：在难度极高的 ARC-AGI-3 基准测试中，仅对 Harness 做了两项关键调整——保留推理与上下文压缩，零模型权重变化：

也就是说：好的 Harness 不仅让模型「聪明了三倍」，还帮你省下了海量 API 成本。当各家旗舰模型能力趋于接近时，竞争的焦点已经从「谁的模型更强」转移到「谁的 Harness 更好」——这与我们在 DeepSeek Harness 系列中的判断完全一致。

1.3 一个会干活的 Agent 需要什么？

一个真正能在业务中跑起来的智能体，需要一套极其复杂的底层执行系统：

1
2
3
4
5
6
7

┌─────────────────────  Codex Harness 执行循环  ─────────────────────┐
│                                                                    │
│   理解任务 → 保持记忆 → 审查上下文 → 调用工具 → 展示进度            │
│      ↑                                                    ↓        │
│   返回结果 ← 人类审批 ← 请求确认 ← 处理失败 ← 沙箱执行              │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

这个包揽了所有「脏活累活」的执行系统和智能体循环，就是 Harness。

二、三大开源组件：我们应该怎么使用？

OpenAI 这次一口气放出了完整的三件套，全部在 Apache-2.0 许可下，任何人可修改、可商用。

2.1 组件一览与选型指南

2.2 第一层：CLI 快速上手

适合跑脚本、CI 任务或后台批处理。它能运行一个有边界的 Agent 工作流，并返回结构化输出：

1
2
3
4
5
6
7

# 安装
npm install -g @openai/codex

# 执行一个有边界的自动化任务
codex exec "检查本仓库的安全依赖漏洞并生成修复补丁" \
  --sandbox workspace-write \
  --output-format json

2.3 第二层：SDK 编程集成

适合在应用中用代码精准控制线程与任务的生命周期：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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

const codex = new CodexClient({ apiKey: process.env.OPENAI_API_KEY });

// 启动任务并流式监听执行过程
const thread = await codex.threads.create({
  workspace: "./my-project",
});

for await (const event of thread.run("重构支付模块并补全单元测试")) {
  console.log(event.type, event.summary);  // 实时看到 AI 在干嘛
}

2.4 第三层：app-server 产品级嵌入

这是本次开源中最耀眼的明星。当 Agent 需要成为你产品的一部分时，app-server 通过 JSON-RPC 协议让你的应用连接本地 Codex 进程：

1
2
3
4
5
6
7
8

┌──────────────────────────────┐        JSON-RPC        ┌──────────────────────────┐
│      你的应用（前端）          │ ◄────────────────────► │    Codex app-server      │
│                              │                          │                          │
│  · 业务看板 / 仪表盘          │   Context in ────────►  │  · Agent 循环            │
│  · 业务上下文注入             │                          │  · 记忆与上下文压缩       │
│  · MCP 工具暴露              │   Events out ◄────────  │  · 沙箱执行              │
│  · 审批界面（HITL）           │                          │  · 流式事件推送           │
└──────────────────────────────┘                          └──────────────────────────┘

它提供的核心能力：

• ✅ 持久对话状态：跨会话保存和恢复线程与任务生命周期；
• ✅ 流式事件：实时向前端推送 AI 的思考过程与执行进度；
• ✅ 中途打断：随时叫停 AI 的工作；
• ✅ 自定义工具：把你应用的 API、数据库通过 MCP 暴露给 AI；
• ✅ 人类审批（Human-in-the-Loop）：关键操作前自动暂停，等待人类确认后才执行。

2.5 官方示范：物流看板「Relay」

OpenAI 官方展示了一个名为 Relay 的物流运营看板应用，全程没有任何聊天框：

1. 交互：用户无需手写 Prompt，只需选中一个延误货单，点击「比较恢复方案」；
2. 上下文：应用自动将当前界面的货单详情、物流数据喂给 AI；
3. MCP 集成：Codex 自动调用应用自有的 MCP 工具获取实时运营数据；
4. 人类把关：Agent 给出最优方案后弹出审批框，业务员点击「同意」才执行写入；
5. 状态同步：操作完成后业务看板自动刷新。

Harness 包揽 Agent 循环、记忆、工具交互和实时反馈；你的产品依然掌控仪表盘、数据和控制权。这才是真正的「人机协同」。

三、竞品对比：Codex Harness vs DeepSeek Harness vs Claude Code

结合本系列前文对 DeepSeek Harness 的分析，更新后的竞品格局如下：

3.1 主要玩家全景

3.2 开源策略对比

3.3 与通用编排框架（LangGraph）的差异

值得注意的是，Codex Harness 的定位与 LangGraph 这类编排框架并不相同：

一句话总结：LangGraph 给你积木，Codex Harness 给你发动机。

3.4 不同用户该怎么选？

四、深度思考：OpenAI 为什么开源？意味着什么？

4.1 从「卖模型」到「卖平台」

这次开源的本质，是 OpenAI 把竞争维度从模型层上移到 Agent 基础设施层。三大控制权被交还给开发者：

• 界面控制权：不再强迫用户适应聊天框，AI 成为隐形的帮手；
• 上下文与工具控制权：通过 MCP 把企业核心系统、内部 API 开放给 Agent；
• 运营边界与安全控制权：宿主应用决定 Agent 在哪运行、能访问什么、哪些危险动作必须人工审批。

「前端业务规则归你，底层 Agent 循环归 OpenAI」——这是典型的平台化打法：用开源的 Harness 换取模型 API 的消耗量。

4.2 已有落地案例证明价值

• 税务申报：Thrive Holdings 和 Crete 将 Harness 嵌入税务准备工作流，试点处理了 7,000 份申报表，准备时间缩短约三分之一；
• 企业云平台：Cisco 用 Codex SDK 构建 App Builder，客户以自然语言创建自定义应用；
• 物流调度：Relay 看板中，Agent 自动分析延误原因，改单操作全部走人工审批。

这些案例的共同点：没有一个用了聊天框。

4.3 风险与冷思考

1. 模型默认绑定：Harness 架构上模型无关，但官方实现默认对接 OpenAI API，替换为其他模型需自行适配模型调用层；
2. Apache-2.0 vs MIT：Apache-2.0 附带专利条款与修改声明义务，二次商用需注意合规细节；
3. 协议尚在演进：app-server 的 JSON-RPC 客户端协议刚开源，API 稳定性需要时间验证，生产环境建议锁定版本；
4. 「反套壳」的考验：真正的难题不是技术，而是有多少开发者愿意放弃舒适的聊天框，把智能体拆成零件装进自己的产品。

4.4 对行业的三个判断

1. Harness 成为新的护城河之争：继 DeepSeek 之后，OpenAI 跟进开源，说明头部厂商已形成共识——编排层的开放程度决定生态粘性；
2. 闭源阵营压力陡增：Claude Code 目前是主要玩家中唯一闭源的，若 Anthropic 不开放 SDK 级嵌入能力，企业级市场可能被分流；
3. 垂直行业 Agent 应用将迎来爆发：当「把 Agent 嵌入产品」的成本降到接近零，财税、物流、安全运维等容错率低但规则明确的行业，反而是最先受益的场景——因为 HITL 审批机制天然适配它们。

五、总结

Codex Harness 的开源，宣告了「通用聊天框」时代的退潮：

我们要做的，绝不是用一个万能的聊天框去干掉所有专业界面，而是给这些界面装上一个聪明的大脑。

对开发者的行动建议：

1. 先试水：用 codex exec 跑通一个 CI 自动化任务，感受有边界 Agent 的执行模式；
2. 再集成：用 SDK 把任务生命周期纳入你的应用逻辑；
3. 终局是产品：通过 app-server + MCP，把 Agent 循环嵌入你最有价值的业务界面。

当通用聊天框消失，原生 AI 应用才会真正蓬勃发展。AI Agent 的零门槛时代，已经来临。

参考资料：

• OpenAI 官方博客：Codex as a platform
• GitHub 仓库：openai/codex
• 本系列前文：DeepSeek Harness 深度解析（上） · （中）竞品对比 · （下）实战