OpenAI 推出 Codex 平台，让 Codex 进入各种工作流

从编程助手到智能体平台：OpenAI 让 Codex 进入每一种工作流 过去，人们主要通过 App、CLI 和 IDE 插件使用 Codex，本质上是人进入 Codex 提供的交互环境。 现在，O...

从编程助手到智能体平台：OpenAI 让 Codex 进入每一种工作流 过去，人们主要通过 App、CLI 和 IDE 插件使用 Codex，本质上是人进入 Codex 提供的交互环境。 现在，OpenAI 将支撑这些产品的开源智能体运行框架 Codex Harness 直接交给开发者，让 Codex 反过来进入企业已有的工程、运营、安全、客服等系统。 开发者继续掌控业务界面、数据、工具、规则和审批权，Codex 则提供上下文延续、任务推理、工具调用、沙箱执行与人工授权等完整智能体循环。 给我们的产品启发：未来优秀的智能体应用，不是把业务搬进 AI，而是把 AI 放进业务。 Codex as a platform: build on the open agent harness developers.openai.com/blog/codex-as-… # 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. 操作完成后，业务系统刷新自己的记录和界面。 这个例子的重点并非物流，而在于交互模式：业务界面本身就是上下文入口，用户动作就是结构化意图，聊天只是其中一个辅助表现层。 # 围绕具体岗位已有的工作方式设计产品（重要启发） · 安全分析师面对告警、受影响服务和处置审批； · 客服工程师面对客户历史、日志、内部文档和回复草稿； · 产品团队通过任务看板触发受限的实现流程； · 运营人员在订单、地图、时间线和业务记录旁调用智能体 OpenAI Developers @OpenAIDevs Teams are using the open-source Codex harness to bring agents into the tools they already use, from internal apps to operations dashboards. Their applications control the interface, context, tools, and approvals while the harness handles the agent loop. developers.openai.com/blog/codex-as-… 🔗 View Quoted Tweet 💬 1 🔄 1 ❤️ 1 👀 707 📊 1 ⚡