OpenAI 发布 Codex 开放智能体平台，开源 harness 支持应用内集成

大多数人通过 App、命令行界面 或 IDE 扩展 了解 Codex。这些体验很重要，但它们只是同一底层系统可被使用的少数几种方式。

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

这改变了开发者能够构建的东西。与其要求每个团队把工作迁移到通用编程助手中，你可以把智能体带入围绕实际工作设计的软件中：一个工程工作流、一个运维仪表盘、一次安全调查、一个客户支持控制台，或一个为某个专门团队构建的内部应用。

可复用的部分是智能体循环

一个强大的智能体不仅仅是一个提示词和一次模型响应。它需要一种方式来理解任务、随时间保持上下文、检查相关信息、调用工具、暴露进度、处理失败、在必要时请求人工批准，并返回有用的结果。

这个围绕模型的执行系统就是 harness。

Harness 的设计可以显著改变结果：在 ARC-AGI-3 上，保留推理和上下文压缩将 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 则让产品团队直接控制生命周期和用户体验。

围绕工作流构建软件

最有趣的机会不是用不同的标志复刻 Codex 应用，而是构建能够反映特定个人或团队已有工作方式的软件：

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

在每个示例中，界面都是体验的重要组成部分。它告诉智能体用户正在看什么，为它提供合适的工具，并给用户一个地方来审查接下来发生的事情。

示例：Relay

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

用户不是从零开始编写提示词。他们选择一批货运，然后点击诸如比较恢复方案之类的操作。应用程序提供相关上下文，Codex 检索最新的示例运营数据，智能体解释可用的选项，任何有后果的写入都需要审批。

然后 Codex 可以使用应用程序的 MCP 工具获取当前数据，再给出建议——或者在获得审批后采取行动。当工具更改底层记录时，应用程序会刷新其业务视图。框架负责处理智能体循环、对话状态、流式活动和工具交互；产品则继续拥有其仪表盘、记录和控制权。

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

开发者正在构建什么

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

• GitHub 和 JetBrains

  将 Codex 引入现有的 IDE 工作流。

• Cisco

  在 Cisco Cloud Control 内的 App Builder 中使用 Codex SDK。

• Thrive Holdings 和 Crete

  在税务准备工作流中使用 Codex，并融入从业者的 反馈。他们的试点处理了 7,000 份申报表，并将准备时间减少了 约三分之一。

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

超越显而易见之处

对于许多类型的工作而言，关键上下文都植根于仪表盘、时间线、地图、文档或系统记录之中。这些视图的存在并非为了美观：它们正是人们真正理解正在发生的事情、做出决策并保持掌控的方式。

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

Codex 应用、CLI 和 IDE 扩展展示了该 harness 的能力。通过将 harness 开源，我们为开发者提供了一种方式来检查这些能力、将它们集成，并使其适配自己的产品和工作流程。

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