先说结论：这不是一次普通的"CLI工具开源"。
8月19日，OpenAI 把驱动 Codex App、Codex CLI 和 VS Code 插件的底层执行框架------Codex Agent Harness------以 Apache-2.0 协议完整开源。截至今天（8月24日），仓库已经冲到 115K+ Star，最新稳定版 v0.149.0 是三天前发的。 Codex CLI 用起来就是个终端编程工具，但这次开源的其实是引擎盖下面的东西：对话状态管理、工具调用编排、沙箱执行、流式输出、人工审批------一整套 Agent 运行时基础设施。 OpenAI 官方对它的定位说得很直白：
"你的产品拥有业务上下文、业务规则和工具；Codex app-server 提供 Agent 循环（agent loop）。"
翻译一下：你不用自己造轮子了，Agent 循环这一块 OpenAI 帮你做好了，而且和 Codex 商业产品用的是同一套。
为什么非要从 TypeScript 重写为 Rust
这件事其实挺戏剧性的。 去年 Codex CLI 刚出来的时候，整个前端是 TypeScript 写的，跑在 Node.js 上。OpenAI 工程师 Fouad Matin 还在 Reddit 上说"TypeScript 是终端 UI 开发的最佳选择"。结果不到三周，团队就宣布了用 Rust 全面重写的决定。 我当时看到这个历史消息的第一反应是：这不是打自己脸吗？ 但仔细想了想，场景变了。CLI 工具阶段，TypeScript 确实够用------启动快、迭代快、生态好。可一旦要把它做成一个"运行时基础设施"，给第三方产品嵌入使用，问题就来了：
冷启动：Node.js 环境下 CLI 冷启动大概 150ms 左右，听起来不多，但如果你要把它嵌进 IDE 插件或者桌面应用里，用户每次触发都等 150ms 只是初始化，体验很差。Rust 编译成原生二进制后，这个数字降到了 50ms 以下。
内存占用：闲置状态下内存降低了约 60%。这个在 IDE 插件场景尤其关键------用户不会想因为装了一个 AI 插件，VS Code 内存占用就多了好几百 MB。
并发会话：这是最关键的。当你用 SDK 同时跑多个 Agent 会话时，Node.js 的事件循环模型在 CPU 密集场景（比如沙箱执行、文件 diff 计算）下会成为瓶颈。Rust 的线程模型天然适合这种场景。
说白了，不是 TypeScript 不行，是场景从"一个 CLI 工具"升级到了"一个嵌入式运行时"，对性能和资源占用的要求完全不是一个量级的。 现在仓库里的结构也很清楚：codex-rs/ 是 Rust 核心，负责所有性能敏感路径（调度、沙箱、TUI 渲染、传输层）；codex-cli/ 保留了 TypeScript 前端作为上层接口。
三层架构：从脚本到产品的完整连续体
这是我觉得 Codex Harness 最值得关注的设计------它不是只提供了一个接口，而是按使用场景分了三层，每层的复杂度、能力和适用对象都不同。
第一层：codex exec------给脚本和 CI/CD 用的
最轻量的一层，一行命令执行完就退出：
arduino
codex exec --approval-policy auto "检查代码规范并自动修复"后台启动 exec-server，任务结束自动退出，特别适合放进 GitHub Actions。说实话这个层级没什么技术含量，但解决了一个实际问题：你不用为了"让 AI 帮我跑个一次性任务"去初始化完整的会话、管理上下文、处理鉴权。
第二层：@openai/codex-sdk------给程序化编排用的
这一层开始有意思了。TypeScript SDK，支持线程创建/分叉/恢复、流式事件消费、中断控制。
csharp
import { CodexAgent } from '@openai/codex-sdk'
const agent = new CodexAgent({
model: 'gpt-5.6',
cwd: '/path/to/project',
approvalPolicy: 'suggest', // 自动执行但需要人工确认危险操作
})
// 创建一个新线程
const thread = await agent.thread.start({
input: '分析仓库中的性能瓶颈并提出优化方案',
})
// 流式消费事件
for await (const event of agent.stream(thread.id)) {
if (event.type === 'message') {
console.log('[Agent]', event.content)
} else if (event.type === 'tool_call') {
console.log(`[Tool] ${event.tool}: ${event.input}`)
}
}
// 可以 fork 一个线程，探索不同方向
const forkedThread = await agent.thread.fork(thread.id, {
input: '换个方向，重点看数据库查询层',
})v0.149.0 还新增了 reasoningEffort 参数，可以选 max 或 ultra 来调节推理强度。简单任务用默认就够了，复杂的架构分析可以开到 ultra，当然 token 消耗也更高。 这一层最让我觉得实用的地方是 fork 机制。比如你的 Agent 正在分析一个性能问题，分析到一半你突然想到"如果换一种方案呢"------直接 fork 当前线程，两条路并行探索，互不干扰。这在以前需要自己管理对话状态和历史，现在 SDK 帮你搞定了。
第三层：app-server------给产品级嵌入用的
这一层面向的是要 codex 到自己的桌面应用、IDE 插件或者 Web 产品里的开发者。基于 JSON-RPC 2.0 协议，支持三种传输方式：
- stdio（默认）：作为子进程嵌入，生产环境推荐
- Unix socket：本地多进程通信
- WebSocket：跨进程流式传输（实验性，官方明确说生产别用）
说到 WebSocket 我得多嘴一句------我一开始没注意这个标注，试着用 WebSocket 传输跑了一个小 demo，结果连上就断、断了重连、重连又断，折腾了快半小时。翻了下源码才发现官方注释里写着 experimental, do not use in production。行吧，是我没仔细看文档，这锅自己背。老老实实切回 stdio 就稳了。 名字起得挺学术，其实就是把对话拆成三个粒度：
- Thread：完整对话会话，可 fork/resume
- Turn：单轮交互（用户消息 → Agent 完成）
- Item：原子事件（消息、推理步骤、Shell 命令、文件编辑等）
可以用 CLI 生成类型定义：
bash
codex app-server generate-ts --out ./schema/
codex app-server generate-json-schema --out ./schema/生成完直接在你的项目里 import 用，类型安全。 app-server 的审批机制也值得说说。它不是简单地"全部自动执行"或"全部要人工确认"，而是有一套 Permission Profile 系统------你可以定义哪些操作自动放行（比如读文件、运行测试），哪些需要人工审批（比如删文件、执行未知的 shell 命令），哪些直接禁止。这个 Profile 可以在创建线程时指定，也可以在运行时动态切换。
一个让我意外的数据
拆架构的过程中，我看到一个数据挺意外的。 通过 Harness 层面的 retained reasoning 和 context compaction 优化，GPT-5.6 Sol 在 ARC-AGI-3 上的得分从 13.3% 跳到了 38.3%，同时输出 Token 消耗减少了 6 倍。 注意：模型没变，只是 Harness 层面的策略不同。换句话说，同样是调 GPT-5.6 的 API，你的 Agent 产品跑出来的效果可能和别人差 3 倍------差距不在模型上，在运行时上。 retained reasoning 的核心思路是：在多轮对话中，把前几轮的关键推理路径保留在上下文里，而不是每次都从头推理。context compaction 则是对历史消息做智能压缩------不是简单的截断，而是保留首尾各几轮关键对话，中间部分做摘要。 这两个策略在 codex-rs 的 Rust 核心里实现，所以性能开销很低。如果是用 TypeScript 做，光压缩算法本身的 CPU 开销可能就抵消了省下来的 token 成本。
模型无关：不绑定 OpenAI
这点容易被忽略，我单独拎出来说下。 Codex Harness 的 model-provider 抽象层支持接入任意兼容 OpenAI API 的模型服务。通过环境变量就能切换：
bash
export OPENAI_API_KEY="your-key"
export OPENAI_BASE_URL="https://your-provider.com/v1"
codex exec --model deepseek-v4-flash "帮我优化这段代码"也就是说，你可以用 Codex 的 Harness 架构，跑 DeepSeek、Qwen、甚至自己本地部署的模型。v0.148.0 还加了 Amazon Bedrock 作为内置 provider 的支持。 不过别高兴太早。我试着把 OPENAI_BASE_URL 切到 DeepSeek 的 API，基本功能没问题，但一涉及到工具调用（tool_call）就开始报奇怪的格式错误。翻了源码才发现，model-provider 层对非 OpenAI 原生模型的工具调用返回格式支持还比较粗糙，有些边界情况没处理。最后老老实实切回 OpenAI 的模型才跑通。想用第三方模型跑复杂编排任务的，建议先看看 codex-rs 里 model_provider.rs 的实现，评估下你的模型兼容性。 话说回来，OpenAI 把"运行时基础设施"的定位做扎实了这一点是真的。不管你用什么模型，底层的 Agent 循环、沙箱执行、审批机制这些脏活累活它都帮你干了。
我怎么看这件事
说实话，AI 编程工具的竞争已经到了一个新的阶段。 去年大家比的是"谁的模型更强"、"谁支持的上下文窗口更大"。但到了 2026 年，模型能力的差距在缩小，真正的差异化开始往"运行时"转移------同样一个模型，谁的 Agent 循环设计得更好、谁的沙箱更安全、谁的上下文管理更高效，谁的产品体验就更好。
Codex Harness 的开源，相当于 OpenAI 把它在商业产品上验证过的运行时架构直接开放给了所有人。对于做 Agent 开发的团队来说，这是一个非常好的参考实现------你不需要从零开始设计 Agent 循环、审批机制、上下文压缩这些基础设施。
但我也要泼一盆冷水：如果你只是想做个 Demo 或者内部工具，别碰这个，直接用 Claude Code 或者 Cursor 的 API 就行，省心得多。Harness 面向的是有基础设施开发能力的团队。它的 app-server 目前还不支持 WebSocket 生产环境，Permission Profile 的配置也比较底层，缺少一个友好的管理界面。没有 Rust 或 TypeScript 基础设施开发经验的团队，接入成本不会低。
另外有一点我觉得挺值得玩味的。OpenAI 把运行时开源了，但模型还是闭源的。你用它的 Harness 架构跑 DeepSeek，跑得越顺，越说明这套系统设计得好------但设计得再好，它也是 OpenAI 做的。等你把 Agent 产品跑起来了，最贵的 token 费用还是得交给 OpenAI 买模型。这招"以退为进"挺高明的。
看到 Codex Harness 开源，很多人会问和 DeepSeek 之前开源的 DSH（DeepSeek Harness）是什么关系。两者独立开发，Codex 用 Rust 核心，DeepSeek 用 TypeScript/Cordis。有意思的是 Codex 的 app-server 可以作为子代理安装到 DSH 里形成嵌套------但这个太进阶了，大多数人目前用 Codex Harness 就够了。
最后说一嘴：OpenAI 这次从 TypeScript 重写成 Rust，说白了就是 AI 工具从玩具走向生产环境的信号。当你要把一个 AI 能力嵌进几百万用户使用的产品里时，语言选择的考量就完全不同了。TypeScript 开发体验好没错，但 Rust 在性能和安全上的优势，在嵌入式运行时场景下是硬需求。
就写到这吧。v0.149.0 的 Release Notes 很长，感兴趣的话建议直接去看，里面有不少细节上的打磨（比如 Vim 编辑模式扩展、codex doctor 诊断工具等），这里篇幅有限就不一一展开了。