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

ouyang2008

从编程助手到智能体平台：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. 操作完成后，业务系统刷新自己的记录和界面。
这个例子的重点并非物流，而在于交互模式：业务界面本身就是上下文入口，用户动作就是结构化意图，聊天只是其中一个辅助表现层。

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