本文根据 OpenAI Developers 的文章编译整理，非逐字翻译；文中观点均属于原作者。
原文：Codex as a platform: build on the open agent harness 全文字符数：2697
大多数人认识 Codex，是通过 Codex App、命令行工具 或 IDE 扩展。这些体验很重要，但它们只是同一个底层系统的几种用法。
真正支撑所有这些体验的，是开源的 Codex Harness（Agent 运行框架）。它帮助模型收集上下文、推理任务、使用工具、在配置好的边界内运行、请求审批，并跨回合持续推进工作。
这改变了开发者能构建的东西。你不必要求每个团队把工作搬进一个通用编码助手，而是可以把 Agent 带进真正围绕实际工作设计的软件：工程工作流、运营看板、安全调查、客服控制台，或者某个专门团队使用的内部应用。
可复用的是 Agent 循环
一个能用的 Agent，远不止“一段提示词加一次模型回复”。它需要理解任务、跨时间维持上下文、检索相关信息、调用工具、展示进展、处理失败、在必要时请求人工审批，并返回有用的结果。
环绕其上的这套执行系统，就是 Harness。
Harness 的设计能显著改变结果：在 ARC-AGI-3 上，“保留推理”和“上下文压缩”两项设置把 GPT-5.6 Sol 的成绩从 13.3% 提升到 38.3%，同时把输出 token 量降到原来的约六分之一。
我们构建 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 则让产品团队直接掌控生命周期与用户体验。
围绕工作流构建软件
最有趣的机会，不是给 Codex app 换一个 logo 再复制一遍，而是构建能反映某个具体的人或团队现有工作方式的软件：
安全分析师可能需要一个调查队列、最近的告警、受影响的服务，以及打开补救工单前的审批步骤；客服工程师可能需要账户历史、产品日志、内部文档和一份草拟好的回复；产品团队可能想要一个任务看板，把任务拖到“就绪”状态就开始一个范围明确的实现工作流。
在每一个例子里，界面都是体验的重要部分：它告诉 Agent 用户正在看什么，给它合适的工具，也给用户一个审阅后续动作的地方。
示例：Relay
我们构建了 Relay，作为运行在 Codex app-server 上的示例运营应用。它把一个 Agent 放在虚构的货运看板旁边，连接到应用拥有的 MCP 工具，并且在重新预订一次货运之前要求人工审批。
用户不是从零开始写提示词。他们选中一次货运，点击“比较恢复方案”之类的动作。应用提供相关上下文，Codex 拉取最新的示例运营数据，Agent 解释可用选项，任何有实际后果的写入都需要审批。
Codex 随后可以调用应用的 MCP 工具，先获取最新数据，再给出建议——或在审批通过后执行操作。当某个工具改变了底层记录，应用会刷新自己的业务视图。Harness 负责 Agent 循环、对话状态、流式活动和工具交互；产品继续拥有自己的看板、记录和控制。
Relay 使用虚构的示例数据，但集成模式是通用的。同样的模式可以支撑事件响应、账户运营、研究流程，以及其他希望 Agent 在既有产品体验内部工作的应用。
开发者正在构建什么
这种模式已经出现在公开实现中：
- GitHub 和 JetBrains 把 Codex 带入现有 IDE 工作流。
- Cisco 在 Cisco Cloud Control 的 App Builder 中使用 Codex SDK。
- Thrive Holdings 和 Crete 在税务申报工作流中使用 Codex，并纳入了从业者反馈；试点处理了 7,000 份申报，准备时间缩短了约三分之一。
这些例子并不局限于工程：同样的模式也适用于排查客户问题的支持团队、协调工作流的运营团队、分类事件的安全团队、研究客户的销售团队，以及策划活动的营销团队。无论哪种场景，都是应用提供上下文、工具和审批，Codex 驱动底层的 Agent 循环。
超越显而易见的方向
对很多工作来说，关键上下文都扎根在看板、时间线、地图、文档或系统记录里。这些视图不是为了好看：人们正是通过它们理解正在发生什么、做决定，并保持掌控。
机会不在于用通用聊天框取代这些界面，而在于给它们配上 Agent，让它理解工作、调查正确的上下文、提出下一步建议，并执行经过审批的动作。
Codex app、CLI 和 IDE 扩展展示了 Harness 的能力。把 Harness 开源，是给开发者一条检查这些能力、集成它们并适配到自己产品和流程的路径。
如果你想用 Codex Harness 构建，先从开源 Codex 仓库开始，再选择适合自己产品的集成方式：非交互任务用 codex exec，程序化 Agent 工作流用 Codex SDK，需要持久对话、流式事件和审批处理的应用用 Codex app-server。