开源杀出重围！OpenAI 亲述：如何把Codex变成谁都能装进产品里的“智能体引擎”
内容提要
OpenAI将Codex开源，核心是可复用的Agent harness（执行框架），而非仅App、CLI、IDE插件三种界面。文章提出三种集成路径：codex exec、SDK和app-server，分别适用于脚本、应用和产品级嵌入。数据显示，优化harness可大幅提升模型性能（ARC-AGI-3得分从13.3%升至38.3%）。GitHub、Cisco等已落地应用，验证了“Agent进产品”的理念。
延伸解读
开源策略的边界
OpenAI 开源的是 Codex 的 harness 与集成层，而非模型本身。模型访问权限和托管服务仍是闭源且独立的。这种策略将可复用的工程部分开放，而将模型作为护城河保留，既扩大生态集成，又不削弱商业模式。开发者需明确，开源不等于完全开放，模型能力仍受制于 OpenAI 的服务。
Harness 优化的实际影响
文章数据显示，仅通过调整 harness 层面的上下文压缩与推理保留，GPT-5.6 Sol 在 ARC-AGI-3 上的得分从 13.3% 提升至 38.3%，同时 token 消耗降至原来的六分之一。这证明 harness 设计对模型表现有显著影响，并非无关紧要的壳。开发者应重视上下文管理与状态维持等工程细节，它们可能成为性能瓶颈。
集成路径的选择指南
OpenAI 提供了三条集成路径：codex exec 适合脚本和 CI 任务，SDK 适合程序化调用，app-server 适合产品级嵌入。选择时需根据场景复杂度：快速试验用 exec，嵌入现有系统用 SDK，构建常驻 Agent 体验用 app-server。示例应用 Relay 展示了如何将 Agent 嵌入业务看板，强调应用层保留控制权，Agent 作为底层引擎。
Q&A
Codex 开源了吗？它的开源协议是什么？
是的，OpenAI 的 Codex 已经开源，代码仓库位于 openai/codex，采用 Apache-2.0 协议。
Codex 的三种集成路径分别是什么？各自适用于什么场景？
三种集成路径是：codex exec（非交互模式），适用于脚本、CI 任务等一次性后台工作；Codex SDK，适用于应用代码需要启动、恢复、流式获取 Codex 任务的场景；Codex app-server，适用于 Agent 本身就是产品一部分的场景，支持长连接、流式事件和审批。
Codex 的 harness 在 ARC-AGI-3 测试中带来了怎样的性能提升？
在 ARC-AGI-3 测试中，仅通过调整 harness 的上下文压缩和推理保留设置，GPT-5.6 Sol 的得分从 13.3% 提升到 38.3%，同时 token 消耗降低到原来的六分之一。
有哪些公司已经将 Codex 集成到自己的产品中？
GitHub、JetBrains、Cisco、Thrive Holdings 等公司已经将 Codex 集成到各自的 IDE、云控制台和报税工作流中。例如，Thrive Holdings 用 Codex 处理了 7000 份报税单，准备时间缩短了约三分之一。
Codex 与 Claude Code、Antigravity 在开源策略上有何不同？
Claude Code 和 Antigravity 都是闭源产品，而 Codex 是唯一开源的编程 Agent。Codex 将底层的 harness 开源，允许开发者审查、修改和集成，而闭源产品只能使用官方提供的界面。
Codex 的 harness 具体负责哪些功能？
Codex harness 负责管理对话状态、流式执行、工具调用、按配置的沙箱和审批策略执行任务，并在多轮对话之间承接上下文。
OpenAI 的示例应用 Relay 是如何展示 Codex 集成模式的？
Relay 是一个虚构的物流运营看板，用户在看板上选中运单并点击业务动作，应用将上下文喂给 Agent，Codex 通过 MCP 工具拉取数据，执行动作前需人工审批，完成后刷新业务视图。这展示了 Agent 嵌入现有产品体验的模式。
开源 Codex 的 harness 对企业和开发者有什么好处？
好处包括：可以审查和调试 harness 的行为；可以根据自己的产品重塑交互，保留已有的界面和审批流；可以掌控运行边界，如沙箱策略和审批规则。
