Codex 的引擎不在聊天框里：拆解那个可复用的智能体循环

Mon, 24 Aug 2026 09:00:00 +0800

说起 Codex，大多数人脑子里浮现的是三个东西：终端里的 CLI、桌面上的 App、编辑器里的插件。我们用它写代码、跑测试、改 bug，然后关掉窗口，很少去想它背后是什么。

但 OpenAI 最近发了一篇文章，标题叫《Codex as a platform》，把这件事讲清楚了：这些界面都只是表象，真正支撑它们的，是同一个开源的可执行引擎，官方叫它 harness。文章由 Nicolas Bonamy 和 Derrick Choi 撰写，信息量不小，而且透露出一个信号，Codex 正在从"一个编程工具"转向"一个可以被嵌入任何产品的平台"。

我想聊聊这个被大多数人忽略的底层，以及它对我们意味着什么。

智能体的真正难点，从来不是"回答"而是"执行"

一个能用的智能体，绝不是"提示词加模型回复"这么简单。它需要理解任务、在多次往返中保持上下文、检索相关信息、调用工具、报告进度、处理失败、在必要时请求人类批准，最后返回一个有用的结果。

这一整套环绕在模型外面的执行系统，就是 harness，也就是智能体循环（agent loop）。它是 Codex 最核心、也最容易被忽视的部分。

文章给出了一个很有说服力的数据点。在 ARC-AGI-3 基准上，仅仅是加入了"保留推理"和"上下文压缩"这两个执行层面的能力，GPT-5.6 Sol 的分数就从 13.3% 提升到了 38.3%，几乎是原来的三倍，而输出 token 反而减少了六倍。

这个数字值得细品。模型本身没有变，变的是它周围的执行机制。这说明在当下的智能体竞赛里，模型能力固然重要，但"如何调度、如何记忆、如何压缩、如何收尾"这些工程问题，往往才是决定实际效果的分水岭。

开源的是执行层，不是模型

Codex 的 harness 是开源的。这意味着你可以拆开应用和模型之间的这层"夹心"，看清楚它到底怎么运作，再按你的产品需求去改造它。

文章把开发者能掌控的部分分成了三层，每一层对应一个决策。

第一是界面。团队可以保留自己现有的仪表盘、编辑器、队列、地图、审批流，而不是把所有人都赶进一个通用聊天窗口。第二是上下文和工具。应用可以暴露自己真正关心的系统、文档、数据和动作，包括应用自己维护的 MCP 服务。第三是运行边界。宿主应用可以决定智能体在哪里运行、能碰哪些文件、哪些动作需要审批、如何观察它的工作、结果如何回流到业务系统。

这句话其实点破了一个很关键的产品立场：开源的是执行层和集成面，模型访问和托管服务是分开的。换句话说，你拿到的是一个可以自由组合的"引擎"，而不是把整个平台都送给你。

三种接入方式，对应三种场景

文章给出了非常实用的分层，不同场景用不同接口，不必一刀切。

对于脚本、CI 任务或一次性后台任务，用 codex exec，跑一个有边界的智能体工作流，拿到结构化输出即可。对于需要在应用代码里启动、恢复、流式处理 Codex 任务的场景，用官方 Codex SDK，走程序化接口。而当智能体本身就是产品的一部分时，用 Codex app-server，它让你的应用连接到一个本地 Codex 进程，保持会话打开、流式收发事件、中断任务、暴露工具、响应审批请求。

这里的逻辑很清晰：SDK 帮你简化常见的程序化工作流，app-server 则把生命周期和用户体验的掌控权交给产品团队。选哪一层，取决于你离"产品"有多近。

别再造一个"换个 logo 的 Codex"

文章里最有意思的一句话是：最诱人的机会，不是把 Codex App 换个 logo 重新做一遍，而是打造真正贴合某个团队工作方式的软件。

Agent Harness on Codexer

Codex 的引擎不在聊天框里：拆解那个可复用的智能体循环

智能体的真正难点，从来不是"回答"而是"执行"

开源的是执行层，不是模型

三种接入方式，对应三种场景

别再造一个"换个 logo 的 Codex"