澄清“开源”误解与概念界定
近期媒体广泛报道OpenAI开源了Codex Harness，但这一说法存在严重的误读。博主小木头在查阅OpenAI Developers官方推文和博客后发现，官方的时态是“正在使用”而非“刚刚开源”。官方明确表示团队正将Agent引入内部应用和运维面板，并基于这套开放的Agent Harness构建产品。这并非一次新的开源发布公告，也没有将博客写成开源发布的声明。准确的理解是：OpenAI在推广已经开源的组件，而非宣布当天新开源了Codex Harness。
此外，这也不等同于Codex模型或模型权重的开源。一个Coding Agent可以粗略拆分为两层：内部是负责决策的模型（Model），外部则是Harness。如果将模型比作大脑，那么Harness更像是神经、手脚与安全系统的组合。只有模型只能得到一次文本生成；加上Harness，才得到一个能持续工作、操作真实文件命令并在风险动作前暂停询问的Agent。
“官方说的是正在使用这套开源Harness以及在这套开放的Agent Harness上面构建产品。”
OpenAI官方组件表也清晰列出了可公开获取的开源部分：Codex CLI、SDK Security TypeScript SDK App Server和Skills等组件可以在公开仓库找到。但GPT模型本身不是开源组件，Codex Cloud也不是。更准确的表达应该是：OpenAI在介绍和推广已经位于Codex模型外面的Agent runtime，它不等于整个产品全部开源。
Harness的核心职责与工程系统
官方博客用一句话概括了Harness的职责：帮助模型收集上下文、围绕任务推理、使用工具，并在配置好的边界内运行。这六个动作可以简记为：Gather context（收集上下文）、Reason（推理）、Use tools（使用工具）、Stay in bounds（保持在边界内）、Request approval（请求批准）和Carry work forward（推进工作）。
这些看似产品介绍的词汇背后，对应着具体的工程系统。例如：上下文如何收集和更新？模型的思考与工具执行怎样形成循环？所谓的“配置好的边界”是指提示词审批策略，还是操作系统级别的沙箱环境（sandbox）？当任务被打断或上下文被压缩后，系统该如何继续推进工作？这些问题构成了Harness的核心技术挑战。
“它帮助模型收集上下文，围绕任务进行推理，使用工具，并且在配置好的边界内进行运行。”
博主指出，虽然这些概念听起来像产品介绍，但每个词背后都有对应的工程实现。例如，“Stay in bounds”涉及安全边界的设定，而“Carry work forward”则关乎任务中断后的状态恢复。这些细节在后续基于源代码的剖析中会逐一展开，但目前可以确定的是，Harness是一个复杂的运行时环境，而非简单的代码片段。
源代码位置与核心模块解析
Codex Harness的源代码并不在名为“Codex Harness”的新仓库中，而是位于大家熟悉的openai/codex代码仓库。进入codex-rs目录可以看到其Rust实现，再深入core目录。README明确指出：codex-core不是某个界面的外壳，而是会话、模型请求、工具执行、权限、沙箱环境、MCP及压缩（compaction）等能力的汇合处。
对于关注智能体工程或上下文工程的开发者，这个目录极具价值。当前版本中，一次问答的主要流程位于codex-rs/session/turn.rs文件中。工具调用经过tools目录里的路由及处理器（handler），普通任务的生命周期在regular.rs中定义，对外暴露的线程对象则在codex_thread.rs文件中。
“Codex-core这里不是某个界面的外壳，它是会话模型请求工具执行、权限、沙箱环境、MCP、压缩等等能力汇合的地方。”
由此可见，Harness并非一个单独文件或刚出现的npm包，而是一组共同完成Agent runtime的模块集合。官方提供了三种使用入口：CLI、SDK和App Server。它们并非三套不同的Harness，而是复用同一套Codex runtime的三种集成门。一次性任务走CLI；需要编程控制走SDK（TypeScript或Python）；若需构建完整交互界面，则连接App Server。
博客的真正意图：Codex as a Platform
既然Harness早已开源，这篇博客究竟在讲什么？博主认为标题中的关键词并非“open source”，而是Codex as a platform（作为平台的Codex）。过去开发者容易将OpenAI的Codex代码仓库误解为仅仅是CLI的代码，但实际上Agent runtime本身就是可以检查、修改和复用的平台底座。
SDK和App Server则是使用这套底座的集成接口。换句话说，这是一篇平台能力介绍和集成的指南。开发者不应只把Codex当作终端里的coding agent，而应将其嵌入代码审查、安全调查、运维流程甚至非写码业务系统中。博客的真正目的是展示如何将长期公开开发的Harness作为平台来使用，而非宣布新开源事件。
“这篇文章真正告诉开发者的是，在CLI的背后这个Agent runtime本身就是可以检查修改和复用的平台底座。”
仓库一直在快速更新，协议和SDK也在持续成熟。但2026年8月OpenAI官宣“开源Codex Harness”既不是官方文章所述的新事，也不是Git历史中能展示出的新故事。博主通过翻阅Git历史发现，早在2025年4月24日左右的一次提交中，标题即为“initial import of Rust implementation of Codex CLI”，当时已包含最小的完整Agent循环。
Git历史验证与早期功能回顾
博主详细回顾了Git提交记录以证伪“新开源”说法。在2025年4月24日的提交中，用户输入进入运行任务（run task），请求模型返回AI响应或工具调用。若为函数调用，运行时执行shell或apply patch并将结果写回历史，继续下一次运行轮次（run turn）。当模型不再调用工具时任务结束。更重要的是，当时已具备沙箱环境、人工批准、失败重试、任务中断及用户中途追加消息等功能。
“当时的实现已经能够看到一个最小的完整的Agent循环，最重要的是当时已经有了沙箱环境、人工批准、失败重试。”
虽然今天的实现更复杂，但Harness最基本的骨架在2025年第一次导入Rust版本时就已经公开可见。随后，2025年9月29日仓库加入了TypeScript SDK scaffold，次日提交中命令行已明确区分MCP Server和App Server。这说明SDK与App Server也不是2026年8月才首次出现。
需要限定的是，源码早就存在不等于当时拥有今天的全部功能。过去一年多，Codex在上下文管理、工具系统协议、MCP、安全边界及多种客户端支持上不断演进。我们能确认的是，官方博客不是一场从无到有的源代码投放，而是在介绍如何把这套长期公开开发的Harness当做平台来使用。
核心循环与工程细节的价值
在turn.rs文件中，执行对话轮次的注释非常直白：一次请求模型 -> 返回AI响应或工具调用 -> 执行结果追加历史 -> 继续请求。这个循环本身并不神秘，十几行伪代码即可写出model-tool-model。但Codex Harness真正值得研究的是循环周围那些让它可以用于实际工程的部分。
这些关键细节包括：模型每次能看到哪些上下文（AGENTS.md、Skills、当前目录环境变化及历史工具结果）？模型看到的工具定义如何保证与runtime真正执行的工具一致？当上下文过长时，如何进行压缩（compaction）？如何恢复工作目录、权限和信息来源？审批窗口与操作系统级别的sandbox为何是两道不同的安全边界？
“Codex Harness真正值得研究的是循环周围那些让它可以用于实际或真实工程的部分。”
这些才是openai/codex代码仓库中最有价值且容易被“开源一个Agent loop”这句话掩盖的内容。博主强调，拥有一次对话轮次包含多次模型请求的机制、StepContext如何冻结同一request view，以及压缩后如何避免Agent遗忘权限和位置，这些实现细节对于基于Codex构建有意义Agent的开发者而言，远比几行循环代码重要得多。
结论
综上所述，OpenAI并未在近期“新开源”Codex Harness。所谓的Codex Harness是位于模型外部的Agent runtime，负责上下文管理、工具执行、权限控制和生命周期维护。其核心源代码一直存在于openai/codex仓库中，特别是codex-rs/core目录。官方博客并非开源公告，而是一份平台集成指南，旨在指导开发者通过CLI、SDK和App Server三种入口，将长期公开开发的Codex runtime作为平台底座嵌入各类应用。媒体误读了“正在使用开源组件”为“当天宣布新开源”，忽略了该Runtime自2025年4月起已在Git历史中公开演进的事实。开发者应关注其上下文工程、安全边界及工具一致性等深层实现，而非仅仅视其为一个新的开源项目。