你真的了解Codex吗？

你真的了解Codex吗？

多数人通过 App、命令行或 IDE 插件认识 Codex。这些体验很重要，也只是同一套底层系统的几种使用方式。

驱动这些体验的是开源 Codex 执行框架。它帮助模型收集上下文、分析任务、调用工具、遵守设定好的边界，在需要时请求批准，并把工作继续推进下去。原文使用的词是harness，这里译为“Agent 执行框架”。

开发者因此可以把 Agent 带进围绕实际工作设计的软件，例如工程流程、运营看板、安全调查、客服控制台，或某个团队使用的内部应用，而不必要求所有人先转到通用编程助手里工作。

可复用的是Agent循环

一个可用 Agent 的工作量远超一次模型回复。Agent 进入工作流后，系统要持续理解任务，保留跨轮次上下文，查找相关信息，调用工具，展示进度，处理失败，在必要时请求人工批准，最后把结果送回用户正在使用的产品。原文把这些工作统称为执行框架。

OpenAI 在文章里给了一个很醒目的数字。在 ARC-AGI-3 这项特定基准测试中，保留推理信息并进行上下文压缩后，GPT-5.6 Sol 的分数从13.3% 提升到 38.3%，输出 token 同时降到大约原来的六分之一。

这组数字说明，模型没有更换时，怎样保留上下文、怎样组织执行循环，也会明显影响结果。它只代表这项测试，不能直接外推成“Codex 整体能力翻了三倍”。

Codex 执行框架负责管理对话状态、流式执行、工具调用、沙箱和审批策略。到了 app-server 这一层，应用可以通过有文档的协议创建线程、启动轮次、接收事件，并处理审批请求。需要在软件中加入 Agent 时，开发者可以从 Codex 开始，再决定周围的应用应该负责哪些部分。

一套可以检查和改造的开放执行框架

执行框架开源后，开发者能检查应用与模型之间发生了什么，也能按照自己的产品调整三件事。

保留原来的界面。看板、编辑器、队列、地图、业务记录和审批流都可以继续用，没必要把所有工作塞进一个通用聊天框。

提供准确的上下文和工具。应用把当前记录、内部文档、业务数据和可执行动作交给 Agent，也可以通过应用自有的 MCP 服务提供权威数据。

设定运行边界。Agent 在哪里运行、能访问哪些文件和工具、哪些动作必须审批、执行过程如何被观察、结果怎样写回业务系统，都由宿主应用决定。

目前开源层包括 Codex CLI、app-server 和官方 Codex SDK。开源范围止于执行框架与集成层，模型访问和托管服务仍然独立。

三种接入方式，怎么选

不同场景需要不同的接入方式，差别主要在于应用要控制多少任务生命周期。

codex exec适合一次性任务。脚本、CI 作业、后台批处理，输入和结束条件都比较明确，用它跑一个受约束的 Agent 流程，再接收结构化结果。

Codex SDK 适合写进应用代码。当程序需要启动、恢复或流式读取 Codex 任务时，SDK 提供了更直接的编程接口。

Codex app-server 适合把 Agent 做成产品的一部分。应用可以连接本地 Codex 进程，保持长期对话，接收实时事件，中断任务，暴露工具，并处理审批。产品团队对交互和生命周期的控制也更细。

只想跑完一项后台工作，可以先看exec；需要在代码里编排任务，选择 SDK；需要让用户在现有产品里持续查看进度、审核结果和批准操作，再进入 app-server。

围绕现有工作流构建软件

OpenAI 在文章里反复强调现有工作界面的价值。安全分析师需要调查队列、近期告警、受影响服务，以及创建修复工单前的审批步骤；客服工程师需要账号历史、产品日志、内部文档和一份回复草稿；产品团队可以在任务进入就绪状态时，启动一项范围明确的开发工作。用户正是通过这些界面理解现场、作出判断。

应用继续掌握产品界面、业务上下文、规则和授权，Codex app-server 提供 Agent 循环与沙箱执行，应用自有 MCP 提供实时数据和获批后的业务动作。工具修改底层记录后，产品再刷新自己的业务视图。

示例：Relay

Relay 是 OpenAI 为这篇文章准备的示例运营应用，数据全部是预置的虚构货运数据。

用户先在看板里选中一票延误货物，再点击“比较补救方案”。应用自动提供这条记录的上下文，Codex 通过应用自有 MCP 读取最新示例数据，解释可选方案。重新订舱之类的重要写操作，必须由人批准后才能执行。

用户不用从空白输入框重新描述整件事。产品已经知道他在看哪条记录，也知道哪些工具可用。Agent 处理调查和方案比较，业务系统继续保管记录、规则与控制权。

开发者正在构建什么

原文列了三组公开实践：GitHub 和 JetBrains 把 Codex 带进已有的 IDE 工作流；Cisco 在 Cisco Cloud Control 的 App Builder 中使用 Codex SDK；Thrive Holdings 与 Crete 把 Codex 用进报税准备流程，并吸收从业者反馈。

按照 OpenAI 文章披露，最后这项试点处理了7,000 份报税申报或税表，准备时间缩短约三分之一。这是一次试点结果，不能写成 7,000 名客户，也不代表所有生产环境都会得到相同比例的提升。

三组案例分别落在 IDE、云控制和报税准备，但应用承担的职责一致。它们先提供现场、数据、工具和审批，再让 Codex 持续执行任务。

走出最显眼的用法

很多工作的关键信息都在看板、时间线、地图、文档或业务记录里。这些界面帮助人理解正在发生什么，作出决定，并保持控制。

OpenAI 给出的方向，是让 Agent 进入这些既有界面。它可以理解当前工作，调查相关信息，提出下一步方案，并在得到批准后执行动作。Codex App、CLI 和 IDE 扩展展示了执行框架能做什么；框架开源后，开发者可以检查这些能力，把它们接进自己的产品和工作流。

开始构建时，可以按照产品需要选择接入层：非交互式任务使用codex exec，程序化 Agent 工作流使用 Codex SDK，需要持续对话、流式事件和审批处理的应用使用 Codex app-server。

如果你平时用 Codex 跑长任务，还需要留意额度和下一次重置信号，可以打开：

打开「重置雷达」