OpenAI 开源 Codex Harness，将智能体嵌入企业工作流

从编程助手到智能体平台：OpenAI 让 Codex 进入每一种工作流

过去，人们主要通过 App、CLI 和 IDE 插件使用 Codex，本质上是人进入 Codex 提供的交互环境。

现在，OpenAI 将支撑这些产品的开源智能体运行框架 Codex Harness 直接交给开发者，让 Codex 反过来进入企业已有的工程、运营、安全、客服等系统。

开发者继续掌控业务界面、数据、工具、规则和审批权，Codex 则提供上下文延续、任务推理、工具调用、沙箱执行与人工授权等完整智能体循环。

给我们的产品启发：未来优秀的智能体应用，不是把业务搬进 AI，而是把 AI 放进业务。

Codex as a platform: build on the open agent harness https://developers.openai.com/blog/codex-as-a-platform

OpenAI 如何定义 Codex Harness 的职责范围

· 理解任务并持续维护上下文； · 检查文件、数据和系统状态； · 调用工具执行操作； · 流式汇报过程和进度； · 处理失败、中断与多轮续接； · 在敏感操作前申请人工批准； · 最终返回可使用、可审查的结果

Codex 平台的三层架构责任边界

· 业务应用：用户界面、业务上下文、业务规则、数据记录、审批体验 · Codex Harness：会话状态、智能体循环、流式事件、工具协调、沙箱执行、审批请求 · MCP／业务工具：查询内部数据、调用业务系统、执行受控操作

这个边界非常关键： · Codex 不应接管整个产品； · 业务应用仍然拥有系统记录、界面和最终控制权； · Codex 负责理解情况、调查信息、提出方案并在授权后执行； · 产生实际业务后果的操作，应由宿主应用设置审批和权限边界。

三种集成方式（轻 -> 重）

1. codex exec：脚本、CI、一次性后台任务 非交互、任务有明确边界、可返回结构化结果 2. Codex SDK：应用代码中的智能体工作流 可启动、恢复和流式接收任务 3. Codex app-server：智能体成为产品本身的一部分 可保持长期会话、接收事件、中断任务、暴露工具并处理审批

OpenAI 构建了一个虚构的物流运营应用 Relay

1. 用户在异常运输列表中选择一票货物； 2. 点击“比较恢复方案”，而不是从空白聊天框输入提示词； 3. 应用自动提供货物和业务上下文； 4. Codex 通过 MCP 工具查询最新运营数据； 5. 智能体比较方案并解释建议； 6. 如果需要重新订舱，必须取得人工批准； 7. 操作完成后，业务系统刷新自己的记录和界面。 这个例子的重点并非物流，而在于交互模式：业务界面本身就是上下文入口，用户动作就是结构化意图，聊天只是其中一个辅助表现层。

围绕具体岗位已有的工作方式设计产品（重要启发）

· 安全分析师面对告警、受影响服务和处置审批； · 客服工程师面对客户历史、日志、内部文档和回复草稿； · 产品团队通过任务看板触发受限的实现流程； · 运营人员在订单、地图、时间线和业务记录旁调用智能体