内容
大多数人是通过 App、命令行界面 或 IDE 扩展 了解 Codex 的。这些体验很重要，但它们只是同一底层系统可用方式中的几种。
开源 Codex harness 为所有这些体验提供支持。它帮助模型收集上下文、推理任务、使用工具、在配置的边界内运行、请求批准，并持续推进工作。
这改变了开发者能够构建的东西。你不必要求每个团队都把工作迁移到通用编码助手里，而是可以把 agent 带入围绕真实工作流程设计的软件中：工程工作流、运维看板、安全调查、客户支持控制台，或为某个专门团队构建的内部应用。
可复用的部分是 agent 循环
一个能力强的 agent 不只是一个提示词和一次模型回复。它需要一种方式来理解任务、随时间维持上下文、检查相关信息、调用工具、展示进度、处理失败、在必要时请求人工批准，并返回有用的结果。
包裹在外的这套执行系统，就是 harness。
harness 的设计会实质性地改变结果：在 ARC-AGI-3 上，保留推理与上下文压缩将 GPT-5.6 Sol 的得分从 13.3% 提升到 38.3%，同时将输出 token 减少了 6 倍。
我们构建 Codex harness 来管理对话状态、流式执行、使用工具、执行已配置的沙箱与批准策略，并跨轮次延续工作。借助 Codex app-server，我们通过一套文档化的客户端协议暴露这些能力：应用可以创建线程、启动轮次、接收事件并处理批准请求。
如果你正在构建需要 agent 的软件，你可以先从 Codex 开始，而不是另造一个运行时，然后再决定外围应用应该负责什么。
开发者可以检查并适配的开源 harness
由于 harness 是开源的，你可以检查应用与模型之间的这一层，理解它的行为，并调整集成方式以适配你的产品。
这让开发者能够掌控那些决定 agent 是否适配产品的部分：
- 界面。团队可以保留现有的看板、编辑器、队列、地图、记录和审批流程，而不是把所有交互都强行塞进一个通用聊天窗口。
- 上下文与工具。应用可以暴露特定工作流所需的系统、文档、数据和操作，包括由应用拥有的 MCP 服务。
- 运行边界。宿主应用可以决定 agent 在哪里运行、可以访问哪些文件或工具、哪些操作需要批准、如何观察工作过程，以及结果如何返回到系统记录中。
我们以开源组件形式发布 Codex CLI、app-server 和 官方 Codex SDK。我们的 开源组件指南 列出了可用内容以及各组件所在位置。
开源层是 harness 和集成接口；模型访问和托管服务则是分开的。
选择合适的集成层
基于 Codex 构建，并不意味着所有用例都要采用同一种集成方式。
- 对于脚本、CI 任务或一次性后台任务，codex exec 可以运行有边界的 agent 工作流并返回结构化输出。
- 对于需要启动、恢复或流式处理 Codex 任务的应用代码，官方 Codex SDK 提供了直接的程序化接口。
如需可运行示例，请参阅 Codex SDK 文档。
当 agent 是产品本身的一部分时，请使用 Codex app-server。它让你的应用能够连接到本地 Codex 进程、保持会话开启、流式传递事件、中断工作、暴露工具，并响应批准请求。SDK 简化了常见的程序化工作流；app-server 则让产品团队直接掌控生命周期和用户体验。
围绕工作流构建软件
最有意思的机会，并不是用一个不同 logo 复刻 Codex 应用，而是构建真正反映某个具体个人或团队现有工作方式的软件：
安全分析师可能需要一个调查队列、最近告警、受影响的服务，以及在开启修复工单前的一个审批步骤。支持工程师可能需要账户历史、产品日志、内部文档和一份草拟回复。产品团队可能希望有一个任务看板，把问题移入 ready 状态时就启动一个限定范围的实现工作流。
在每个例子里，界面都是体验的重要组成部分。它告诉 agent 用户正在查看什么，为它提供正确的工具，也给用户一个地方来审核接下来会发生什么。
图 1。你的应用拥有产品上下文、业务规则和工具；Codex app-server 提供 agent 循环和沙箱化执行。
示例：Relay
我们在 Codex app-server 上构建了 Relay，作为一个示例运维应用。它把一个 agent 放在虚构的货运看板旁边，将其连接到应用拥有的 MCP 工具，并要求在重新预订货运前进行人工批准。
用户不会先从零写提示词。他们先选择一笔货运，然后点击 比较恢复方案 之类的操作。应用提供相关上下文，Codex 检索最新的示例运营数据，agent 解释可用选项，而任何有后果的写操作都需要批准。
随后，Codex 可以使用应用的 MCP 工具先获取当前数据，再推荐——或者在获得批准后执行——某个操作。当工具更改底层记录时，应用会刷新其业务视图。harness 负责 agent 循环、对话状态、流式活动和工具交互；产品则继续拥有自己的看板、记录和控制项。
Relay 使用的是虚构的种子数据，但这种集成模式是通用的。同样的模式也可以为事件响应、账户运维、研究工作流或其他需要 agent 在现有产品体验中工作的应用提供支持。
图 2。Relay 将 Codex 嵌入货运运维看板中，配合应用拥有的 MCP 工具，并在产生后果的操作前进行人工批准。
开发者正在构建什么
这种模式已经出现在公开实现中：
- GitHub 和 JetBrains 将 Codex 带入现有的 IDE 工作流。
- Cisco 在 Cisco Cloud Control 的 App Builder 中使用 Codex SDK。
- Thrive Holdings 和 Crete 在一个包含从业者反馈的报税工作流中使用 Codex。他们的试点处理了 7,000 份申报，并将准备时间缩短了约三分之一。
这些例子并不局限于工程领域：同样的模式也适用于正在调查客户问题的支持团队、协调工作流的运维团队、分诊事件的安全团队、研究客户的销售团队，以及开发营销活动的市场团队。在每一种情况下，应用提供上下文、工具和审批，而 Codex 为底层 agent 循环提供动力。
超越显而易见的方向去构建
对于许多工作而言，关键上下文都依托于看板、时间线、地图、文档或系统记录。这些视图并不是为了好看：它们是人们真正理解正在发生什么、做出决策并保持掌控的方式。
机会不在于用一个通用聊天框取代这些界面，而在于通过给它们配备一个能够理解工作、调查正确上下文、提出下一步建议并执行经批准操作的 agent，让它们变得更强大。
Codex 应用、CLI 和 IDE 扩展展示了 harness 能做什么。通过将 harness 开源，我们为开发者提供了一种方式去检查这些能力、集成这些能力，并将其适配到自己的产品和工作流中。
如果你想基于 Codex harness 开发，请先从 开源 Codex 仓库 开始，然后选择适合你产品的集成方式：codex exec 适用于非交互式任务，Codex SDK 适用于程序化的 agent 工作流，而 Codex app-server 则适用于需要持久会话、流式事件和审批处理的应用。