For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航
2026年8月19日 Codex

作为平台的 Codex:基于开放的智能体执行框架构建应用

将 Codex 集成到用户熟悉的产品和工作流中。

作者: Nicolas Bonamy, Derrick Choi

作为平台的 Codex:基于开放的智能体执行框架构建应用

大多数人通过 App命令行界面IDE 扩展了解 Codex。这些使用体验很重要,但只是同一套底层系统的几种用法。

这些体验都由开源 Codex 执行框架提供支持。它帮助模型收集上下文、通过推理处理任务、使用工具、在配置的边界内运行、请求审批,并持续推进工作。

这拓展了开发者能够构建的应用。您不必要求每个团队都将工作转移到通用编程助手中,而是可以将智能体引入围绕实际工作设计的软件:工程工作流、运营仪表盘、安全调查工具、客户支持控制台,或为某个专业团队构建的内部应用。

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

一个能胜任工作的智能体,不能只有提示和模型回复。它需要理解任务、持续维护上下文、查看相关信息、调用工具、展示进度、处理故障、在必要时请求人工审批,并返回有用的结果。

提供这些支持的执行系统,就是执行框架。

执行框架的设计可以显著影响结果:在 ARC-AGI-3 上,保留推理内容和压缩上下文将 GPT-5.6 Sol 的得分从 13.3% 提升至 38.3%,同时将输出 Token 数量降至原来的六分之一。

我们构建 Codex 执行框架,是为了管理对话状态、流式传输执行过程、使用工具、执行配置的沙盒和审批策略,并跨轮次推进工作。通过 Codex app-server,我们以有文档说明的客户端协议开放这些能力:应用可以创建会话线程、启动轮次、接收事件并处理审批请求。

如果您正在构建需要智能体的软件,可以从 Codex 入手,无需另行开发运行时,再决定外围应用应负责哪些部分。

开发者可以查看和调整的开放执行框架

由于执行框架是开源的,您可以查看应用与模型之间的这一层,了解它的行为,并调整集成方式以适配您的产品。

这样,开发者就能掌控以下部分,让智能体适配自己的产品:

  • 界面。团队可以保留现有的仪表盘、编辑器、队列、地图、记录和审批流程,而不必强行将所有交互都放进通用聊天窗口。

  • 上下文和工具。应用可以开放与特定工作流相关的系统、文档、数据和操作,包括由应用管理的 MCP 服务

  • 运行边界。宿主应用可以决定智能体在哪里运行、可以访问哪些文件或工具、哪些操作需要审批、如何观察工作过程,以及如何将结果写回权威记录系统。

我们将 Codex CLIapp-server官方 Codex SDK作为开源组件发布。我们的开源组件指南列出了可用组件及其所在位置。

开源的部分是执行框架和集成接口;模型访问和托管服务仍与之分开。

选择合适的集成层

基于 Codex 构建应用时,不必为所有用例采用同一种集成方式。

  • 对于脚本、CI 作业或一次性后台任务,codex exec 可以运行范围明确的智能体工作流,并返回结构化输出。

  • 对于需要启动、恢复 Codex 任务或流式接收其输出的应用代码,官方 Codex SDK 提供了直接的编程接口。

如需可运行的示例,请参阅 Codex SDK 文档

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

围绕工作流构建软件

最值得探索的机会,不是换个标志再做一个 Codex App,而是构建契合特定个人或团队现有工作方式的软件:

安全分析师可能需要调查队列、近期告警、受影响的服务,以及创建修复工单前的审批步骤。支持工程师可能需要账户历史记录、产品日志、内部文档和回复草稿。产品团队可能希望有一个任务看板,将议题移至就绪状态后,就能启动范围明确的实现工作流。

在每个示例中,界面都是体验的重要组成部分。它让智能体知道用户正在查看什么,为智能体提供合适的工具,也为用户提供审查后续操作的地方。

架构图展示了由应用管理的界面、业务上下文和用户同意机制;Codex app-server 的智能体循环和沙盒内执行;以及由应用管理的 MCP 数据和操作。

图 1。您的应用负责产品上下文、业务规则和工具; Codex app-server 提供智能体循环和沙盒内执行能力。

示例:Relay

我们基于 Codex app-server 构建了运营示例应用 Relay。它在虚构的货运仪表盘旁嵌入智能体,将其连接到应用管理的 MCP 工具,并要求在重新预订货运前进行人工审批。

用户无需从头编写提示。他们选择一票货物,然后点击 比较补救方案等操作。应用提供相关上下文,Codex 检索最新的运营示例数据,智能体解释可用方案,任何会产生重要影响的写入操作都需要审批。

随后,Codex 可以使用应用的 MCP 工具获取当前数据,再提出操作建议,或在获得审批后执行操作。当工具更改底层记录时,应用会刷新业务视图。执行框架负责智能体循环、对话状态、活动的流式传输和工具交互;产品则继续管理自己的仪表盘、记录和控制机制。

Relay 使用预先填入的虚构数据,但其集成模式具有通用性。同样的模式可以用于事件响应、账户运营、研究工作流,或其他需要让智能体在现有产品体验中工作的应用。

Relay 货运运营仪表盘,展示异常队列、货运详情,以及正在调查货运延误的 Codex 智能体。

图 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 扩展展示了执行框架的能力。通过将执行框架开源,我们让开发者能够查看这些能力的实现,将它们集成到自己的产品和工作流中,并进行相应调整。

如果您想使用 Codex 执行框架进行开发,可以先查看开源 Codex 代码仓库,再选择适合您产品的集成方式:非交互式作业使用 codex exec,通过编程实现的智能体工作流使用 Codex SDK,需要持久对话、流式事件和审批处理的应用则使用 Codex app-server