文章摘要
近期，受DeepSeek的Harness项目影响，OpenAI开源CodexHarness并介绍搭建Codex平台方法。该框架为智能体提供执行闭环，优化执行框架能大幅提升性能。开源组件可在GitHub查看改造，开发者获三层面控制权。Codex提供分层接入方案，OpenAI推出示例应用Relay。此模式已在多场景落地，推动智能体赛道发展。

近期，DeepSeek推出的Harness项目凭借出色表现收获了18.4万星标，彻底带火了智能体执行框架赛道。受此影响，相关厂商纷纷跟进，OpenAI也正式开源了自家的Codex Harness，并在官方博客中详细介绍了如何基于这个开放的智能体执行框架搭建Codex平台。

很多用户对Codex的认知还停留在APP、命令行工具或者IDE插件层面，但OpenAI明确表示，这些都只是Codex系统的不同入口，真正具备复用价值的核心资产是底层的开源Harness框架。这套框架的核心作用是为智能体提供完整的执行闭环：收集上下文信息、推进任务进度、调用外部工具、在预设边界内执行操作，以及在需要时请求人工审批。

智能体的能力上限并不只取决于模型本身，这一点在实际测试中得到了充分验证。在ARC-AGI-3基准测试中，仅仅通过两项Harness层的设置——保留推理过程和上下文压缩，就让GPT-5.6 Sol的测试得分从13.3%提升到了38.3%，同时输出的Token数量还减少了约六倍。也就是说，在模型本身没有任何改动的情况下，仅通过优化执行框架就让性能提升了近三倍，足以证明Harness这类执行系统的重要性。

本次OpenAI开源的组件包括Codex CLI、app-server以及官方SDK，所有代码都可以在GitHub平台上查看并进行自定义改造。不过OpenAI也明确了开源的边界：仅开放Harness框架和集成层，模型的访问与托管服务并不在开源范围内。

通过这套开源框架，开发者可以获得三个层面的控制权：首先是界面层面，可以保留原有的仪表盘、编辑器、工单队列和审批流程，无需将所有交互强制整合到通用聊天窗口中；其次是上下文与工具层面，可以将业务专属的系统、文档、数据和操作接口暴露给智能体，比如集成应用自有MCP服务；最后是运营边界层面，智能体的运行位置、可访问的资源范围、需要审批的操作类型、工作监控方式以及结果数据回流规则，都由宿主应用自主决定。

针对不同的使用场景，Codex提供了分层的接入方案：

  • 针对脚本、CI任务等有明确边界的后台作业，可以使用codex exec工具
  • 如果需要在应用代码中启动、恢复或流式调用Codex任务，推荐使用Codex SDK
  • 如果将智能体作为产品核心功能，需要持久会话、流式事件处理和人工审批流程，则可以使用Codex app-server

为了让开发者更直观地理解这套框架的使用方式，OpenAI推出了示例应用Relay。这款应用将智能体嵌入虚构的货运运营仪表盘，集成了应用自有MCP工具，并明确规定所有涉及数据修改的操作都必须经过人工审批。运营人员无需手动编写提示词，只需选中延误的货运订单，点击“Compare recovery”按钮，应用就会自动提供相关上下文信息，Codex拉取最新的运营数据，智能体分析并给出可选的恢复方案，经过审批后再执行具体操作。当工具修改底层数据后，仪表盘的视图会自动刷新，整个过程中，Harness负责管理智能体循环、会话状态和流式活动，而产品团队则保留了对界面、数据和控件的完全控制权。

目前这套模式已经在多个场景中实现了落地：GitHub和JetBrains将Codex集成到了各自的IDE工作流中；Cisco在Cloud Control的App Builder中通过Codex SDK搭建应用；两家会计师事务所Thrive Holdings和Crete将其应用在报税流程中，试点处理了7000份申报，准备时间缩短了约三分之一。OpenAI特别强调，这种模式并不局限于工程团队，客服问题排查、运营流程协调、安全事件响应、客户调研等场景都可以适配这套智能体框架。

当前大模型的技术竞赛仍在持续，但OpenAI的这次开源举动，将智能体应用开发中最核心的运行时框架开放给了社区。这意味着开发者无需从零搭建复杂的智能体执行系统，只需要基于开源的Harness框架，就能快速构建具备完整能力的智能体应用，进一步推动了智能体赛道的发展。

https://developers.openai.com/blog/codex-as-a-platform
https://github.com/openai/codex
以上内容不代表本平台立场，仅供读者参考