大家好，我是小木头。这两天很多媒体在报道关于 OpenAI 开源了 Codex Harness。一开始我也以为 OpenAI 刚刚官宣了一次新的开源发布，但看完 OpenAI Developers 官方的推文和博客，我发现事情似乎并不是这样。官方推文说的是团队正在使用开源的 Codex Harness 把 Agent 带进到内部应用和运维的面板。注意这里的时态，官方说的是正在使用这套开源 Harness 以及在这套开放的 Agent Harness 上面构建产品。它没有说我们今天开源了 Codex Harness，也没有把这篇博客写成一次开源发布的公告。出于好奇呢，并且确实也想看看 Codex 的 Harness 是怎么做的，我顺着官方链接去 GitHub 浏览了一番。我发现 OpenAI 并没有一个叫 Codex Harness 的仓库，所有链接最后都回到了我们已经非常熟悉的 openai/codex 这个代码仓库。所以这期视频我想纠正这个容易被误读的口径，再聊聊3个问题：Harness 究竟是什么？源代码到底在哪里？以及这篇博客真正想介绍的是什么。
咱们先明确一点，Codex Harness 确实是开源的，但“它是开源的”和 OpenAI 在这一天宣布把它开源是两件不同的事情。另外呢，这也不是 Codex 模型或模型权重的开源。一个 coding agent 可以粗略地拆成两层：里面呢是模型，负责根据当前信息决定下一步回答用户、读文件、执行命令或者修改代码；外面呢是 Harness，负责准备模型看到的上下文，把工具告诉模型，真正的执行工具、处理权限和 sandbox（也就是沙箱环境），再把结果送回模型，直到任务完成。如果模型是大脑，Harness 更像神经、手脚和安全系统的组合。只有模型，你得到的是一次文本的生成；模型加上 Harness 才得到一个能够持续工作、能操作真实文件和命令，还能在风险动作前停下来问你的 Agent。
OpenAI 官方的开源组件表也写得很清楚：Codex CLI、SDK Security TypeScript SDK App Server 和 Skills 等组件可以在公开仓库里面找到，但是 GPT 模型本身并不是开源组件。另一方面呢，Codex Cloud 也不是。所以更准确的表达应该是 OpenAI 在介绍和推广已经开源的、位于 Codex 模型外面的 Agent runtime。它不等于 Codex 整个产品全部开源，更不代表这套 runtime 是博客发布当天才开源的。官方博客还用一句话概括了这套 Harness 的职责：它帮助模型收集上下文，围绕任务进行推理，使用工具，并且在配置好的边界内进行运行，在必要时请求批准，并把工作持续地推进下去。
这6个动作可以把它们快速的记成 Gather context、Reason、Use tools、Stay in bounds、Request approval、Carry work forward。它们听起来像一句产品介绍，但每个词背后其实都有它对应的工程系统：比如上下文怎么收集和更新？模型的思考和工具的执行怎样形成循环？所谓的 configured boundaries 到底是提示词、审批策略，还是操作系统级别的沙箱环境（也就是 sandbox）？任务在被打断或上下文被压缩以后，那又该怎么样继续呢？这也就是刚才提到的术语 Carry work forward。这些问题这一期咱们先点到为止，后面呢咱们会直接的基于源代码来逐一的剖析。
那接下来咱们聊聊源代码。Harness 的源代码就在 openai/codex 这个代码仓库，进入 codex-rs 这个目录可以看到它的 Rust 实现。再进入 core 这个目录，README 直接就写着 codex-core：这里不是某个界面的外壳，它是会话、模型请求、工具执行、权限、沙箱环境、MCP、压缩（也就是 compaction）等等能力汇合的地方。如果你对于智能体工程或者是上下文工程非常的感兴趣呢，这个目录应该是你值得去看一看的地方。当前版本里，一次的问答主要流程就在 codex-rs 的 session/turn.rs 这个代码文件中。工具调用经过了 tools 目录里的路由以及处理器（也就是 handler）。普通任务的生命周期在一个叫 regular.rs 的代码文件中。对外暴露的线程对象在 codex_thread.rs 这个文件。也就是说所谓的 Harness 并不是一个单独文件，更不是一个刚出现的 npm 包，而是一组共同完成 Agent runtime 的模块。
官方博客给出了三种使用它的入口：第一种呢是命令行接口 CLI，你可以直接运行 Codex（我相信这也是绝大多数用户早已经在使用的接口吧），当然了也可以用 codex exec 把任务塞进脚本或 CI（也就是持续集成环境或流程）。第二种呢是 SDK，可以用 TypeScript 或 Python 在自己的程序里启动和管理 Codex。第三种是 App Server，它用双向的 JSON-RPC 来暴露 Thread、Turn、Item、事件和审批请求等等，适合于编辑器桌面应用或者企业内部的工作台。呃，CLI、SDK 和 App Server 它们并不是三套不同的 Harness，它们更像三扇门：后面复用着同一套 Codex runtime。需要一次性的任务就走 CLI，需要编程控制呢咱们可以走 SDK，如果需要自己做完整的交互界面就连接 App Server。
既然仓库 Harness 早就存在，那么这篇博客到底在讲什么呢？我认为标题里的关键词倒并不是 open source，而是 Codex as a platform。过去大家容易把 OpenAI 的 Codex 代码仓库理解成 Codex CLI 的代码仓库，其实我之前呢好像也是这么认为的。因为我也并没有完整的看过 Codex 所有的代码，没有看过整个代码仓库。那这篇文章真正告诉开发者的是：在 CLI 的背后，这个 Agent runtime 本身就是可以检查、修改和复用的平台底座。另一方面呢 SDK 和 App Server 则是使用这套底座的集成接口或集成面。换句话说，这是一篇平台能力介绍和集成的指南：不要只把 Codex 当做终端里的一个 coding agent，也可以把它嵌入代码审查、安全调查、运维流程，甚至完全不是写代码的业务系统。仓库当然一直在快速更新，协议和 SDK 也在持续的成熟。
但是呢，2026年8月 OpenAI 突然官宣开源 Codex Harness，既不是官方文章说的事情，也不是 Git 历史当中能够展示出来的故事。那咱们就简单说说 Git 历史：我把仓库的历史翻了一下，翻到了2025年4月24日左右这个提交。当时大致的标题就是 initial import of Rust implementation of Codex CLI，也就是 Codex Rust 实现的第一次进入公开的代码仓库。如果咱们打开那一版的源代码已经能够看到一个最小的完整的 Agent 循环：用户输入进入运行任务（也就是一个 run task），运行轮次请求模型，模型如果返回 function call（也就是工具调用或函数调用）运行时就会执行 shell 或者 apply patch，把工具结果呢再写回历史然后继续下一次的运行轮次（也就是 run turn）。模型不再调用工具，任务才结束。
最重要的是当时已经有了沙箱环境、人工批准、失败重试、任务中断以及用户中途追加消息这些功能或特性。今天的实现当然复杂得多，但 Harness 最基本的骨架在2025年第一次导入 Rust 版本的时候呢就已经公开可见了。再往后看，2025年9月29日仓库加入了 TypeScript SDK scaffold；第二天的一个提交里命令行已经明确区分了 MCP Server 和 App Server。这说明 SDK 与 App Server 也不是2026年8月才第一次出现。不过这里呢需要加个限定：说源码早就在倒不等于说2025年已经拥有了今天的全部功能。过去一年多 Codex 在上下文管理、工具系统协议、MCP、安全边界和多种客户端支持上都在不断的演进。我们能确认的是，官方博客不是一场从无到有的源代码投放，而是在介绍如何把这套长期公开开发的 Harness 当做平台来使用。
好了咱们回到今天刚才所介绍的代码仓库和源代码，其中的 turn.rs 这个代码文件对执行一个对话轮次呢它的注释非常直白：一次请求模型，模型返回 AI 的响应（或者叫 assistant message）或者呢是一个工具调用 tool call。工具执行结果追加到聊天历史然后继续请求模型，这个循环很重要但它本身并不神秘：十几行伪代码就可以写出 model、tool、model。Codex Harness 真正值得研究的是循环周围那些让它可以用于实际或真实工程的部分：比如模型每次到底能看到哪些上下文（AGENTS.md、Skills、当前目录环境的变化）以及历史的工具结果怎样进入请求？模型看到的工具定义怎样保证和 runtime 真正执行的工具是一致的？上下文太长以后怎么压缩？要怎样恢复工作目录、权限和信息来源？审批窗口与操作系统级别的 sandbox 为什么是两道不同的安全边界？
这些才是 openai/codex 代码仓库最有价值也最容易被“开源一个 Agent loop”这句话掩盖的内容。最后咱们还是来总结一下吧：首先 Codex Harness 并不是模型，而是模型外面的 Agent runtime。它负责上下文、工具执行、权限安全和生命周期。其次没有一个新的 Codex Harness 仓库，核心源码一直就在 OpenAI 的 Codex 这个项目中。重点可以从 codex-rs 的 core 开始阅读，当然了感兴趣的朋友呢可以去读一下 CLI、SDK 和 App Server。是三种不同的集成入口：第三，这篇官方博客不是 Harness 开源公告，它真正介绍的是怎样通过 CLI、SDK 和 App Server 把已经开源长期公开开发的 Codex runtime 当做平台使用。很多媒体把 open-source Harness 这个既有属性误读成了 OpenAI 当天宣布开源 Harness 这个新闻事件。
好了下一期我会继续沿着当前源码继续往那边走，专门讲讲 Codex Harness 的上下文工程：一次对话轮次为什么会包含很多次模型请求呢？StepContext 这个概念如何冻结同一个 request view？压缩（也就是 compaction）之后又怎样避免 Agent 忘记自己在哪里、拥有什么权限呢？如果你准备自己基于 Codex 做 Agent，甚至你打算自己做一个有意义的 Agent，这些实现细节可能比那几行循环重要的多。好了我是小木头，我们下期见。