OpenAI 把 Codex“发动机”开源了：以后最强的 AI 软件，可能根本没有聊天框

先说结论

OpenAI 真的把驱动 Codex Agent 的核心 Harness 开源了。

CLI、官方 SDK 和 app-server 都可以检查、修改并嵌进自己的产品，openai/codex 仓库采用 Apache-2.0 许可证。开发者可以把 Codex 的任务循环、工具调用、审批和流式进度塞进业务看板，而不是再做一个换皮聊天框。

但先踩住“全面开源”的油门：OpenAI 开源的是 Agent Harness 和集成层，不是 Codex 模型权重，也不是完整的 Codex Cloud。IDE 扩展和云端托管服务仍未开源，模型访问仍然是另一回事。

更准确的标题应该是：

OpenAI 把 Codex 的发动机拆出来给你了，但没有把整辆车和油田一起送你。

天下苦“万能聊天框”久矣

过去一年，AI 产品越来越像。

左边是一列历史记录，中间一个聊天框，底部一行“有什么可以帮忙的？”

写代码是聊天框。

查数据是聊天框。

客服、报税、运营、供应链，最后也被硬塞进聊天框。

问题是，真正工作的人通常不是靠聊天理解业务。

安全人员看告警队列，物流人员看货单，客服看账户历史，财务人员看报表和凭证。界面不只是装饰，它本身就是上下文，也是审批和责任边界。

OpenAI 这次给出的方向很直接：别再把所有人赶进 Codex，让 Codex 进入他们原本就在用的软件。

Harness 到底是什么？

一个能干活的 Agent，不等于“模型 + 一段神奇 Prompt”。

它还需要一套执行系统：

• 理解并拆分任务；
• 保留跨轮次上下文；
• 读取文件和业务数据；
• 调用终端、MCP 和其他工具；
• 把进度实时发给用户；
• 遇到失败后重试或换路径；
• 危险操作前请求批准；
• 最后把结果写回原来的系统。

包住模型、让这些动作持续运转的循环，就是 Harness。

模型像大脑，Harness 更像神经、手脚、记忆和刹车。脑子很聪明，但没有这些东西，它仍然只能坐在聊天框里回答问题。

最炸裂的数据：只改 Harness，分数就翻了近三倍

OpenAI 官方举了一个很能说明问题的例子。

在 ARC-AGI-3 测试中，GPT-5.6 Sol 最初每执行一步就丢掉之前的私有推理，而且旧上下文会被滚动截断。模型看起来像一个每走一步就短暂失忆的人。

OpenAI 只调整了两处 Harness 设置：

• 保留上一轮推理；
• 用上下文压缩代替简单截断。

结果，得分从 13.3% 升到 38.3%，输出 Token 反而减少约六倍。

这不能被翻译成“所有任务都会变强三倍”，也不是新模型跑分。它说明的是：同一个模型，被怎样管理，可能比换一个更贵的模型还重要。

OpenAI 这次到底开了哪三扇门？

第一层：codex exec

适合脚本、CI 和一次性后台任务。

你可以让 Codex 在明确边界内完成任务，然后返回结构化输出。它不需要一个完整产品界面，更像可以塞进自动化流水线的 Agent 工人。

第二层：Codex SDK

适合应用程序直接启动、恢复和流式传输 Codex 任务。

如果开发者需要用 TypeScript 或 Python 管理线程、任务和事件，SDK 是较直接的编程入口。

第三层：Codex app-server

这是最值得关注的部分。

应用可以连接本地 Codex 进程，保持对话状态、接收事件、打断任务、暴露自己的工具，并处理人类审批请求。

业务软件继续负责界面、权限和数据；Codex 在底层负责 Agent 循环和受控执行。

这意味着你可以拥有一个“会自己干活”的物流看板，而不需要在看板旁边再贴一个聊天窗口。

官方演示 Relay：聊天框真的消失了

OpenAI 做了一个虚构物流应用 Relay。

用户选中延误货单，点击“比较恢复方案”。应用自动把货单和运营数据提供给 Codex，Agent 再通过应用自己的 MCP 工具获取最新信息。

如果只是分析，它可以直接给出方案；如果要真正修改订舱记录，就必须弹出审批。用户批准以后，工具执行写入，看板同步刷新。

整个过程不要求用户从零写 Prompt。

Agent 不是产品主角，而是藏在按钮后面的执行能力。

这才是这次开源真正可能改变软件设计的地方。

报税案例比“做个 Demo”更有说服力

OpenAI 公布的 Thrive Holdings 与 Crete 试点，将 Codex 放进税务准备流程。

该系统在试点中处理了约 7,000 份报税表，并让准备时间减少约三分之一。税务从业者的修正还会被记录下来，转成新的评测和工程任务，让系统继续改进。

这不是“Codex 自己成为税务师”。专业人员仍然负责审查、判断和上线，Codex 负责调查失败、提出修改、运行测试并提交候选方案。

这个边界非常重要：

不是让 AI 独立报税，而是把 AI 接进一个有数据、有规则、有专家审批的税务系统。

Cisco 也开始把 Codex 塞进云控制台

OpenAI 官方文章还列出 Cisco 的 App Builder：它使用 Codex SDK，让用户在 Cisco Cloud Control 里通过自然语言创建应用。

这里的重点不是“Cisco 做了聊天机器人”，而是 Codex 被放进已有的云控制产品里。用户仍然面对熟悉的业务环境，Agent 只在背后承担生成和执行任务。

如果这种模式扩散，未来很多软件可能不会出现明显的“AI 页面”。

你只会发现，原来的按钮突然能完成过去需要五个人来回沟通的事情。

反转来了：这不是模型开源，也不是免费午餐

OpenAI 官方文档明确区分了开源范围：

• Codex CLI：开源；
• Codex SDK：开源；
• Codex app-server：开源；
• Codex Security CLI/SDK：有开源组件；
• IDE 扩展：未开源；
• Codex Cloud：未开源；
• 模型访问和托管服务：与开源 Harness 分开。

所以你可以检查和修改“模型怎样工作”的执行层，却仍然需要解决模型调用、部署成本、认证和云服务问题。

Apache-2.0 允许修改和商业使用，不代表调用 OpenAI 模型不要钱，也不代表所有 Codex 产品代码都已经公开。

DeepSeek 最尴尬，也可能最高兴

这件事还有一条很有戏的支线。

DeepSeek 官方已经提供把自己的模型接入 Codex 的教程。如今 Codex Harness 被更明确地当作开放平台推广，理论上开发者更容易把 OpenAI 的 Agent 壳、自己的业务界面和其他模型组合起来。

于是可能出现一个很抽象的产品：

界面是你的，Harness 来自 OpenAI，模型却是 DeepSeek。

这对 OpenAI 不一定是坏事。只要 Codex Harness 成为开发者默认的 Agent 运行层，哪怕部分人换掉模型，OpenAI 仍然可能定义整个生态的接口和工作方式。

真正的竞争，开始从“谁的模型分最高”转向：

谁能成为所有模型都愿意住进去的 Agent 操作系统。

我的判断：这不是零门槛，而是“少造一遍轮子”

原稿里最容易夸大的词，是“Agent 零门槛时代”。

把 Agent 嵌进企业软件，仍然需要权限设计、MCP 工具、日志、评测、错误恢复、成本控制和人工审批。Harness 开源不会让这些问题自动消失。

但它确实减少了一大块重复劳动：每个团队不再需要从头实现会话状态、事件流、工具调用、沙盒和审批协议。

过去开发者做 AI 产品，常常先做一个聊天框；接下来，开发者可能先问：

用户原本在哪个界面工作？Agent 应该藏在哪个动作后面？

这是一种比“再套一个壳”更健康的产品方向。

仍然要观察

• 社区会不会围绕 app-server 建立新的前端和垂直行业产品。
• 非 OpenAI 模型接入 Codex Harness 后，兼容性和效果如何。
• Apache-2.0 开源组件与闭源 Codex Cloud 的功能差距会不会扩大。
• 企业是否愿意把高权限工具交给本地 Codex 进程。
• Harness 生态最终由 OpenAI、Claude Code、DeepSeek 还是独立开源项目主导。

最后一句：

以前所有软件都想加一个聊天框；以后最好的 AI 软件，可能根本看不到聊天框。

Codex Harness 常见问题

OpenAI 把 Codex 模型开源了吗？

没有。开源的是 Codex Harness 和相关集成组件，包括 CLI、SDK 与 app-server。模型权重、模型访问和托管服务并没有因此开源。

Codex Harness 可以商用吗？

openai/codex 仓库采用 Apache-2.0 许可证，通常允许修改、分发和商业使用，但仍需遵守许可证、第三方组件条款及所调用模型服务的使用规则。

Codex app-server 有什么用？

它让应用连接到本地 Codex 进程，管理线程和任务、流式接收事件、调用应用工具，并在危险操作前处理人类审批。

开源后使用 Codex 就免费了吗？

不是。开源代码可以免费获取，但模型 API、计算资源、托管服务和实际部署仍可能产生费用。