把 Codex 当作平台：基于开放的 Agent Harness 构建应用

Agent 进入真实系统的工程挑战

多数人是通过 Codex App、命令行界面或 IDE 扩展认识 Codex 的。这些产品体验很重要，却只展示了同一套底层系统的几种使用方式。

为这些体验提供动力的，是开源 Codex Harness。它帮助模型收集上下文、推理任务、使用工具，在预先配置的边界内运行，需要时请求批准，并把工作持续推进下去。

这改变了开发者能够构建的软件。团队不必把工作全部搬进一个通用编程助手，而是可以把 Agent 放进围绕真实任务设计的软件：工程工作流、运营面板、安全调查、客户支持控制台，或者为某个专业团队打造的内部应用。

最近很多团队都在讨论模型能力。可当 Agent 进入真实产品，问题很快落到一连串工程细节上。它怎样拿到上下文，怎样调用工具，谁来批准高风险动作，任务中断后又怎样继续。

OpenAI 这篇文章让我关注的是 Codex App、CLI 和 IDE 扩展背后的同一层，也就是 Harness。读完后我留下的判断，是未来大量 Agent 产品的差异，会落在模型之外的这套执行系统上。

可复用的是 Agent 循环

一个有能力的 Agent，不能只有一段 Prompt 和模型响应。它需要理解任务，长期维护上下文，检查相关信息，调用工具，展示进度，处理失败，在必要时请求人工批准，最后返回有用的结果。

围绕模型运行的这套执行系统，就是 Harness。

Harness 的设计会直接改变结果。在 ARC-AGI-3 上，保留推理过程与上下文压缩把 GPT-5.6 Sol 的得分从 13.3% 提高到 38.3%，同时将输出 Token 减少了六倍。

Codex Harness 负责管理会话状态、流式传递执行过程、使用工具、执行已配置的沙箱与审批策略，并让工作跨轮次延续。借助 Codex app-server，这些能力通过一套有文档说明的客户端协议对外开放：应用可以创建 Thread、启动 Turn、接收事件并处理审批请求。

如果你正在构建一款需要 Agent 的软件，可以从 Codex 起步，省去重新发明 Runtime 的工作，再决定外围应用应该负责哪些部分。

开放、可检查、可适配的 Harness

Harness 开源后，开发者可以检查应用与模型之间的这一层，理解它的行为，再按自己的产品需要调整集成方式。

因此，开发者可以控制真正决定 Agent 能否融入产品的几个部分：

• 界面。 团队可以继续使用已有的面板、编辑器、队列、地图、记录与审批流程，不必把所有交互都塞进一个通用聊天窗口。
• 上下文和工具。 应用可以开放特定工作流需要的系统、文档、数据与操作，包括由应用自己拥有的 MCP 服务。
• 运行边界。 宿主应用可以决定 Agent 在哪里运行，能够访问哪些文件或工具，哪些操作必须审批，工作过程如何被观察，以及结果怎样回到业务记录系统。

OpenAI 将 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 用户正在查看什么，为 Agent 提供合适的工具，也给用户留下审核下一步操作的位置。

示例：Relay

OpenAI 构建了 Relay，作为一个基于 Codex app-server 的运营应用示例。它把 Agent 放在一个虚构的货运面板旁边，连接到应用自有的 MCP 工具，并规定重新订舱前必须获得人工批准。

用户不需要从一段空白 Prompt 开始。他们选择一票货运，再点击“比较恢复方案”之类的操作。应用提供相关上下文，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。

JOTO 企业落地观察

• 企业部署 Agent 系统时，不应默认将模型推理层与执行层耦合。Harness 的开源意味着团队可将已有业务系统（如工单、CRM、监控平台）作为天然的 Agent 上下文容器，降低迁移成本。
• 这类系统的关键取舍不在模型能力，而在运行边界的定义粒度：是按操作级（如“更新客户字段”）审批，还是按任务级（如“处理客诉”）审批？前者利于审计，后者利于效率。
• RAG 知识工程需与 Harness 协同设计——不是简单注入文档，而是将知识检索封装为 MCP 工具，由 Harness 统一调度、限流与审计，确保知识调用可追溯。
• AI 安全治理必须前置到 Harness 层：沙箱策略、工具白名单、审批钩子、执行日志回传，这些能力若依赖上层应用自行实现，极易出现治理盲区。