开源的 Codex Harness 正是驱动所有这些体验的核心。它帮助模型收集上下文、推理任务、使用工具、在配置的边界内运行、请求批准，并持续推进工作。

大家好，我是玄姐。

大多数人通过 App、命令行工具（CLI）或 IDE 扩展认识 Codex。这些体验固然重要，但它们只是同一套底层系统的几种使用方式。

开源的 Codex Harness正是驱动所有这些体验的核心。

https://github.com/openai/codex

它帮助模型收集上下文、推理任务、使用工具、在配置的边界内运行、请求批准，并持续推进工作。

这改变了开发者可以构建的东西。你不再需要让每个团队都把工作搬进一个通用的编程助手，而是可以把智能体带入围绕实际工作设计的软件中：一套工程工作流、一个运维仪表盘、一次安全调查、一个客服控制台，或是一个为专门团队打造的内部应用。

一、可复用的部分是智能体循环（Agent Loop）

一个有能力的智能体，远不止一个提示词加一次模型响应。它需要一种方式来理解任务、长期维护上下文、检查相关信息、调用工具、展示进度、处理失败、在必要时请求人工批准，并返回有用的结果。

这套外围的执行系统就是Harness。

Harness 的设计能实质性地改变结果：在 ARC-AGI-3 基准上，保留推理（retained reasoning）和上下文压缩（context compaction）将 GPT-5.6 Sol 的得分从 13.3% 提升到 38.3%，同时输出 token 减少了六倍。

我们构建的Codex Harness 负责管理对话状态、流式执行、工具使用、强制执行配置的沙箱与审批策略，并在多轮交互中持续推进工作。通过 Codex app-server，我们以一个文档化的客户端协议开放这些能力：应用可以创建线程、启动轮次、接收事件并处理审批请求。

如果你在构建需要智能体的软件，可以从 Codex 开始，而不必重新发明一套运行时，然后再决定外围应用应该拥有哪些部分。

二、一个开发者可以检视和改造的开放 Harness

因为 Harness 是开源的，你可以检视应用与模型之间的这一层，理解它的行为方式，并调整集成以适配你的产品。

这让开发者能够掌控那些让智能体契合自身产品的部分：

界面。团队可以保留现有的仪表盘、编辑器、队列、地图、记录和审批流程，而不是把每一次交互都塞进一个通用聊天窗口。上下文与工具。应用可以开放对特定工作流重要的系统、文档、数据和操作，包括应用自有的 MCP 服务。运行边界。宿主应用可以决定智能体在哪里运行、可以访问哪些文件或工具、哪些操作需要审批、工作如何被观察，以及结果如何回流到记录系统。

我们以开源组件的形式发布了 Codex CLI、app-server 和最新 Codex SDK。我们的开源组件指南列出了可用的内容以及每个组件的位置。

开源层是 Harness 和集成接口；模型访问和托管服务仍然是独立的部分。

三、选择合适的集成层

基于 Codex 构建，并不意味着所有场景都用同一种集成方式。

对于脚本、CI 任务或一次性的后台任务，codex exec可以运行一个有边界的智能体工作流并返回结构化输出。对于需要启动、恢复或流式处理 Codex 任务的应用代码，最新 Codex SDK 提供了直接的编程接口。

可运行的示例请参见 Codex SDK 文档。

当智能体本身就是产品的一部分时，使用 Codex app-server。它让你的应用连接到本地 Codex 进程、保持对话开启、流式接收事件、中断工作、开放工具，并响应审批请求。SDK 简化了常见的编程工作流；app-server 则让产品团队直接掌控生命周期和用户体验。

四、围绕工作流构建软件

最有意思的机会，不是换个 Logo 复制一个 Codex 应用，而是构建反映特定人员或团队既有工作方式的软件：

安全分析师可能需要一个调查队列、最近的告警、受影响的服务，以及在开具修复工单前的审批步骤。支持工程师可能需要账户历史、产品日志、内部文档和一份回复草稿。产品团队可能想要一个任务看板：当某个 issue 被移入"就绪"状态时，便启动一个有范围的实现工作流。

在每个例子中，界面都是体验的重要组成部分。它告诉智能体用户正在看什么，为它提供合适的工具，并给用户一个审视后续动作的地方。

图 1：你的应用拥有产品上下文、业务规则和工具；Codex app-server 提供智能体循环和沙箱化执行。

五、示例：Relay

我们基于 Codex app-server 构建了 Relay，一个示例运维应用。它在一个虚构的货运仪表盘旁放置了一个智能体，将其连接到应用自有的 MCP 工具，并要求在重新预订货运前获得人工批准。

用户无需从零开始编写提示词。他们选择一批货物，点击诸如Compare recovery（比较恢复方案）的操作。应用提供相关上下文，Codex 检索最新的示例运营数据，智能体解释可用选项，而任何有实际影响的写入操作都需要审批。

随后，Codex 可以使用应用的 MCP 工具获取当前数据，再提出建议，或在获得批准后执行操作。当工具改变了底层记录，应用会刷新其业务视图。Harness 负责智能体循环、对话状态、流式活动和工具交互；产品则继续拥有自己的仪表盘、记录和控制权。

Relay 使用的是虚构的种子数据，但这种集成模式是通用的。同样的模式可以驱动事件响应、账户运营、研究工作流，或其他任何需要智能体在既有产品体验中工作的应用。

图 2：Relay 将 Codex 嵌入货运运营仪表盘中，配备应用自有的 MCP 工具，并对重大操作要求人工审批。

六、开发者们正在构建什么

这种模式已经出现在公开的实现中：

GitHub和JetBrains将 Codex 带入现有的 IDE 工作流。Cisco（思科）在 Cisco Cloud Control 的 App Builder 中使用了 Codex SDK。Thrive Holdings 和 Crete在一个融入从业者反馈的税务申报工作流中使用 Codex。他们的试点处理了 7,000 份申报，并将准备时间缩短了约三分之一。

这些例子并不局限于工程领域：同样的模式适用于调查客户问题的支持团队、协调工作流的运营团队、分诊事件的安全团队、研究客户的销售团队，以及策划营销活动的营销团队。在每种情况下，应用提供上下文、工具和审批，而 Codex 驱动底层的智能体循环。

七、超越显而易见的构建

对许多工作而言，关键上下文扎根于一个仪表盘、一条时间线、一张地图、一份文档或一条系统记录中。这些视图的存在不是为了好看：它们是人们真正理解正在发生什么、做出决策并保持掌控的方式。

机会不在于用一个万能聊天框取代这些界面，而在于通过赋予它们一个能理解工作、调查正确上下文、提出下一步建议并执行已批准操作的智能体，让这些界面变得更强大。

Codex App、CLI 和 IDE 扩展展示了 Harness 的能力。通过将 Harness 开源，我们让开发者能够检视这些能力、集成它们，并将其适配到自己的产品和工作流中。

如果你想基于 Codex Harness 构建，请从开源的 Codex 仓库开始，然后选择适合你产品的集成方式：codex exec用于非交互式任务，Codex SDK 用于编程式智能体工作流，Codex app-server 用于需要持久对话、流式事件和审批处理的应用。