分享 Codex 负责人 Tibo 的公开演讲，主要探讨三个问题：OpenAI 如何融合 Codex（Agent Harness）与 GPT（Model），Codex 为何采用 Rust 开发，以及他对 AI 时代代码审查和开源的看法。
Tibo 谈 Codex：Harness 总比模型快一步
旧序更迭，让位于新。
------阿尔弗雷德·丁尼生《国王叙事诗·亚瑟王之逝》
这句话对应丁尼生原诗中的 "The old order changeth, yielding place to new"，确实出现在其亚瑟王题材作品中。
编者说明
本文主要整理自 The Pragmatic Engineer 于 2026 年 9 月 9 日 发布的 Tibo Sottiaux 访谈，并结合截至 2026 年 9 月 25 日的 OpenAI 官方文档、Codex 开源仓库和 PowerContext 官方资料进行核查与更新。Tibo 是 Codex 的早期创建者之一，访谈发布时负责 OpenAI 的 Core Products & Platform 组织，其中包括 Codex。
程序员难免对自己写下的代码有感情。但在模型快速迭代的今天，即使当前合理的实现，也可能很快因为模型能力提升而失去必要性。
这带来一个越来越重要的工程问题：
围绕模型构建的 Harness，究竟应该做到什么程度？
Tibo 给出的答案很明确：
Harness 总要比模型稍微领先一点。
这里的 Harness，对应访谈中的 Harness。它不是单一组件，而是模型之外的一整套工程系统，包括指令、工具、权限、沙盒、运行环境以及控制模型行为的上下文。
一、模型不够，就先用 Harness 补上
主持人 Gergely Orosz 提到一个很具体的变化。
早期使用 Codex 时，让它修改代码，它可以完成修改，却未必主动运行仓库里已有的单元测试。几个月后，同样的任务，它已经会主动测试。
这是 Codex 团队修改了 Harness，还是模型本身变强了？
Tibo 的回答是：两者都有。
Harness 的作用，是把模型当前还做不稳定的事情补起来。比如模型暂时不会主动想到运行测试，就可以通过每轮开始时注入的开发者消息提醒它。
随着模型能力提升，这类提醒就可以逐渐删掉。
Tibo 将这个过程概括为：Harness 为模型提供一些临时 "拐杖"，帮助它提高可靠性、效率和可控性；模型一旦学会相应能力，这些辅助机制便不再需要。
这也是 "Harness 总比模型稍微领先一点" 的真正含义。
它并不是要永久包住模型，而是解决模型今天还解决不了、但产品今天必须解决的问题。
二、先改模型，还是先写代码？
这也改变了 Codex 团队的工程决策方式。
过去发现产品缺少一项能力，通常意味着工程团队开始设计、开发、测试和上线。
但在 Codex 团队，第一步可能是先问：
这个问题究竟应该由 Harness 解决，还是由下一代模型解决？
据 Tibo 介绍，研究团队与工程团队会共同设计这类能力。如果判断应该由模型解决，他们还会进一步讨论时间：
- 1 个月能解决吗？
- 3 个月呢？
- 6 个月呢？
如果模型很快就能获得这项能力，团队有时会选择不写临时的 Harness 代码，直接等待模型补齐。团队还会利用智能体分析用户反馈、归纳问题并辅助确定优先级。
于是，工程师多了一项过去并不常见的判断：
这段代码现在还值得写吗？
Tibo 给团队举过一个极端例子：
如果为了绕过模型的某个缺陷，需要写出 1 万行补偿代码，那么很可能方向已经错了。
他的意思并不是 "一万行" 本身有什么特殊界限，而是提醒团队同时关注用户、产品和模型的发展方向。为了一个可能很快消失的模型缺陷，长期堆积大量工程复杂度，未必划算。
换句话说：
代码不是资产的唯一形式，有时甚至会变成未来需要删除的负担。
三、/goal：最典型的一根 "拐杖"
访谈中的 /goal 是一个很直观的例子。
Tibo 介绍，过去为了让 Codex 长时间围绕同一个目标持续工作，需要 /goal 之类的额外机制。复杂任务甚至可以持续运行数天或数周。
但他表示，在团队观察的新一代模型上，模型本身维持长期目标的能力已经明显增强，因此某些过去依赖 /goal 才能实现的行为，可以直接通过给模型长期目标来完成。
这里需要注意：这是 Tibo 在访谈中对内部新一代模型表现的描述，不应理解为任何模型、任何任务都能稳定自主运行数周。
真正值得关注的是背后的工程规律：
模型能力增强后，Harness 中曾经必要的机制，也需要重新评估，而不是永久保留。
四、从 "不能合上盖子的笔记本" 到云端开发环境
智能体能够持续工作，也把一个老问题重新带了回来：任务到底应该在哪里运行？
Gergely 在访谈中提到，他去过一家 AI 公司，发现开发者为了让智能体持续使用本地数据库、工具和开发环境，只能让笔记本一直开着。
这并不只是一个电源管理问题。
本地电脑往往包含开发者真正需要的环境：
- 本地数据库；
- 代码仓库；
- 开发工具；
- 本地服务；
- MCP 服务；
- 凭据和个性化配置。
把任务搬到云端很容易，把完整环境搬过去却不容易。
Tibo 因此判断，过去没有在中小团队中真正普及的云开发环境，可能会因为智能体重新获得机会。
过去，云开发环境最大的成本之一，是搭建和持续维护环境本身。现在，如果智能体能够根据本地 SQLite、服务器和 MCP 等配置自动构建并维护云端环境，这部分成本就可能明显下降。
他的设想并不是简单的 "本地换云端"，而是让执行位置逐渐变得透明：
今天一部分任务在本地完成，另一部分在云端完成；以后还可能根据算力、数据和工具需求动态选择环境。
五、Codex 目前仍同时存在本地与云端形态
从今天的产品状态看，这个方向已经相当清晰。
Codex 官方开源仓库仍将 Codex CLI 定义为运行在本地电脑上的编程智能体。本地 Codex 可以访问用户授权的工作目录，并通过沙盒模式和审批策略控制文件系统、网络及命令权限。
例如，在常见的 workspace-write 模式下，Codex 可以在工作区内读写和执行常规命令；在需要访问互联网或越过工作区边界等情况下，可以按照审批策略请求用户许可。
与此同时，OpenAI 也提供云端执行环境以及用于智能体运行的云端基础设施。官方文档已经公开了云环境注册、环境密钥和远程执行相关机制。
需要对原访谈中的产品表述做一个时间上的校准。
Tibo 在 2026 年 9 月 9 日的访谈中，将当时的 ChatGPT Work 描述为在云端计算机上运行完整 Codex Harness，并介绍了团队将本地 Codex 能力整合进云端产品的工程过程。他还举例称，用户曾让云端环境安装 Blender 并进行 3D 建模。
但截至 2026 年 9 月 25 日，OpenAI 最新产品文档已经进一步调整了用户侧的产品划分：
- Work 面向研究、分析和多步骤交付任务；
- Codex 继续专注软件开发；
- 桌面端的 Codex 仍作为独立入口存在；
- Work 可以在云端运行，桌面端在授权后也可使用本地文件和应用。
因此，访谈中的"合并"更适合理解为底层能力和基础设施的融合过程，而不是认为今天 Work 与 Codex 已经是完全相同的产品入口。
六、为什么偏偏选择 Rust？
Codex 最初并不是今天这个形态。
Tibo 回忆，他加入 OpenAI 后，最初主要为研究团队建设基础设施。当时团队已经意识到，可以利用模型本身帮助研究人员更快写代码、建设训练和分析系统。
于是，他们与研究人员一起训练模型、构建小型智能体，让内部模型特别熟悉 OpenAI 的 Python 代码库、代码风格和架构习惯。
这些小型智能体成为后来 Codex 的前身。
随后，这条研究线与内部的 ASWE（Autonomous Software Engineer，自主软件工程师）方向合并，最终形成早期云端 Codex。Tibo 坦言，最初的产品使用阻力仍然较大，并没有真正找到产品市场契合点，之后团队继续推出 Codex CLI 并迭代产品形态。
这里有一个看起来反直觉的技术选择：
当时模型明显更擅长 Python 和 TypeScript，为什么 Codex 核心却选择了 Rust？
选 Rust，首先是为了边界。Tibo 给出的考虑主要包括：
- 稳健性；
- 安全性；
- 执行效率；
- 大规模扩展能力；
- 编译期静态检查。
他过去经历过一些项目：最初规模很小，后来却需要扩展到大型数据中心级别，因此希望从一开始就考虑系统的长期边界，前提是不明显牺牲开发速度。
但比性能本身更重要的，是另一条设计原则：
智能体核心应该能够独立于具体产品存在。
如果产品层和智能体核心都放进同一个代码库、使用同一种语言，工程师很容易为了短期方便不断增加内部耦合。
时间一长，产品和智能体就很难分别演进。
Tibo 认为，Rust 在这里不仅是一门编程语言，也形成了一道工程边界：产品入口可以变化，智能体核心仍能保持相对独立。
他同时承认，如果当初使用 TypeScript，甚至 Python，也可能做成，未来再重写即可。
这意味着 Rust 并不是 "唯一正确答案"。
真正的设计原则是：
如果一个模块未来需要独立高速演进，就应该尽早为它建立清晰边界。
七、代码越来越容易重写，架构还有没有意义？
这是一个很自然的问题。
如果模型让写代码、重构代码都越来越便宜，还需要提前认真设计架构吗？
Tibo 的答案仍然是需要，只是关注点发生了变化。
他举了第三方依赖升级的例子：如果变更日志清楚、代码文档完整，模型已经可以沿代码库理解影响范围，在几个小时内完成过去很容易被长期拖延的升级工作。
更大规模的重构和系统调整，也在因为 AI 辅助开发而加速。
但 "代码改得快" 和 "系统可以随便设计" 是两回事。
真正决定变化成本的，仍然是边界。
Tibo 用"盒子"来描述这种设计：
先确定一个模块对外承诺什么，以及哪些不变量必须始终成立。
只要这些条件不变，盒子内部就可以快速修改，而不必让所有相关团队重新讨论一遍。
这实际上把架构重点从"内部实现稳定"转向了：
边界稳定，内部可以快速变化。
八、一个周末，项目可能就从几个人变成 100 个智能体
AI 还压缩了软件项目原本漫长的组织成长过程。
过去，一个项目从几名工程师发展到 50 人、100 人，往往需要较长时间。团队可以随着人员增加逐渐补文档、接口规范、测试制度和协作机制。
Tibo 描述了一种新的情况：
现在可能一个周末，就突然有 100 个智能体开始向同一个项目贡献代码。
于是，过去可以以后再补的事情，突然必须提前解决。
比如一个公共接口发生变化：
- 哪些调用方必须同步修改？
- 哪些兼容条件不能破坏？
- 哪些不变量必须继续成立？
- 新的贡献者去哪里了解这些规则？
以前这些知识可以依靠团队慢慢形成。
当贡献速度被压缩到机器尺度以后，没有明确写下来的约束，很快就会变成系统性风险。
这也是为什么代码生成能力越强，架构、接口、文档和上下文管理反而越重要。
九、开源：功能可能还没发布，就先被别人复制了
Codex 另一个重要选择是开源。
目前 Codex 官方仓库采用 Apache 2.0 许可证，Codex CLI 及其核心 Rust 实现均公开可查。
Tibo 对开源的态度并不浪漫化。
他明确谈到了成本。
团队有时正在公开仓库中开发一个新功能，还没有正式发布，其他产品就可能已经看到了代码，并更早推出类似实现。
他的看法是：
公开开发本身就意味着接受这种可能性。Codex 使用的又是相当宽松的许可证，因此他人依据许可证使用、修改和分发代码，本就是开源选择的一部分。
除此之外，团队还需要承担：
- 公开仓库与内部代码之间的边界成本；
- 多仓库协同成本；
- 大量质量参差不齐的社区贡献带来的维护成本。
但 Tibo 仍认为开源值得。
十、为什么一个编程智能体尤其适合开源？
原因很直接：
用户一定会拿编程智能体来修改编程智能体自己。
公开代码以后，社区可以直接尝试不同实现，团队也可以看到用户真正希望改变什么。
开源还降低了新人进入项目的门槛。
Tibo 说，新同事加入 Codex 团队以前，往往已经看过仓库和 PR；正式加入以后，可以直接让 Codex 帮助阅读仓库、解释代码和回答问题。
从这个角度看，开源仓库不仅是代码分发渠道，也是一份持续更新的产品和工程说明书。
十一、"支持多模型" 需要说准确
原访谈中还有一个容易被过度概括的观点：
Codex 不只支持 OpenAI 模型。
更准确地说，这是指开源 Codex CLI / Harness 的模型提供方机制。
Tibo 在访谈中解释，如果用户只是为了接入另一个模型提供方，需要修改十行左右代码，却不得不长期维护整个 Fork，这没有太大意义。既然 Harness 已经开源，不如直接允许用户选择其他模型提供方。
截至目前，Codex 开源代码中确实存在多模型提供方机制。
官方代码当前内置了 OpenAI、Amazon Bedrock，以及 Ollama、LM Studio 等提供方，并允许用户通过配置增加自定义模型提供方。
但这里不能进一步推导成：
"所有 OpenAI 托管的 Codex 产品都可以任意更换其他公司的模型。"
公开证据支持的是 Codex CLI / 开源 Harness 具备多提供方架构，而不是所有托管产品都开放同样的模型选择。
Tibo 还表示，Codex 团队自己也会把其他模型放入同一个 Harness 中测试。
他的竞争逻辑是：
希望依靠更好的模型、更高的效率和更好的产品赢得用户。
十二、代码审查正在从 "看代码" 转向 "确认意图"
AI 改变的不只是写代码，也包括代码审查。
Tibo 早期曾与研究团队一起开发代码审查模型，希望发现普通审查者很难快速发现的深层问题。
比如，一个错误可能隐藏在依赖的第 3 到第 4 层：
第三方库文档写的是一种行为，真正实现却是另一种行为，上层代码因此依赖了一个实际上并不成立的条件。
对不熟悉该库的人来说，仅仅定位这种问题，就可能需要几个小时。
Tibo 表示，这类深度验证能力后来已经进入 OpenAI 的主线模型。
他还介绍，OpenAI 内部已经将自动化安全审查加入 PR 流程；如果自动审查标记出安全问题，PR 会被阻止合并。这个 "自动阻止" 的具体内部规则来自 Tibo 的访谈陈述；OpenAI 此前也公开表示，Codex 会自动审查公司内部几乎所有 PR，以发现关键问题。
十三、人类审查不会消失，只是审查对象变了
代码审查从来不只是在找 Bug。
它同时承担几项组织功能：
- 信息交换；
- 知识共享；
- 架构讨论；
- 确认开发意图；
- 判断某项功能是否真的值得建设。
过去，这些讨论经常直到 PR 已经写完才发生。
Tibo 的判断是，正确性和网络安全检查会越来越自动化；而真正需要人类投入注意力的部分，会更多转向：
- 为什么要做？
- 做这件事是否合理？
- 它与整个产品是否一致？
- 接口和不变量应该是什么？
- 谁来承担长期维护？
他认为，这些讨论完全可以提前到代码产生之前，而不必继续依赖 PR 作为主要触发点。
这实际上意味着软件工程的注意力正在前移：
从审核实现，转向审核意图、边界和约束。
十四、新人加入团队："你问过 Codex 吗？"
如果越来越多工作不再围绕 PR 展开，那么团队历史和项目背景应该去哪里找？
Tibo 介绍，新人加入 Codex 团队后，遇到问题经常听到的一句话是：
"你问过 Codex 吗？"
据他描述，在 OpenAI 内部，Codex 可以访问 Slack、文档和代码，因此可以回答：
- 项目目前是什么状态？
- 谁正在负责某项工作？
- 当时为什么做这个决定？
- 某个方案之前讨论过什么？
团队也会有意识地把更多讨论放在开放频道和权限较宽的文档中，让其他成员和智能体都能够访问这些信息。
这里同样需要注意边界：
这是 Tibo 对 OpenAI 内部配置的描述，不代表普通 Codex 用户默认拥有对 Slack、全部文档和全部代码的访问权限。
OpenAI 面向外部用户公开的 Codex 确实已经提供 Slack 集成，但具体能访问什么内容，仍由用户授权、工作空间配置和相关系统权限决定。
十五、Codex 甚至成了 "项目记者"
在 Codex 与 ChatGPT 基础设施整合的过程中，Codex 还承担了另一种角色。
Tibo 说，团队曾经反复讨论：
- 两套系统应该怎样整合；
- 产品应该叫什么；
- 什么时间推出；
- Work 的切换入口应该怎样设计；
- 哪些底层能力应该统一。
由于 Codex 能访问相关 Slack 和文档，它把这些讨论和决策过程记录了下来。
因此，后来者不仅能够看到最终结果，还可以回过头追问：
为什么最后选择了这个方案？
主持人 Gergely 对这种模式也表达了保留意见。
他认为，当 AI 持续存在于各种工作讨论中时，会带来某种 "老大哥一直在看" 的感受，自己仍未确定应该怎样看待这种变化。这个疑问很重要。组织知识越来越容易被智能体查询，并不意味着权限、隐私和信息边界可以被忽略。
恰恰相反：智能体能看到得越多，权限治理就越重要。
十六、真正需要长期保存的，不是提示词，而是 "工作状态"
回到最开始的问题。
为了提醒模型运行测试的一句话，可以删除。为了补偿模型缺陷写下的代码，也可能删除。但有一类东西不能随着模型升级而消失：
项目已经形成的事实、判断、验证结果和未完成工作。
举一个典型的软件排查过程：
代码改动在 Git 中；
复现条件在日志里；
为什么排除某种原因，可能只存在于一次聊天中；
为什么放弃某个方案，也许只在 Slack 中讨论过；
哪些测试已经执行，哪些还没有执行，又可能写在另一个工具里。
资料看起来都还在。
但如果第二天换一个人、换一个智能体、换一个会话继续，工作未必能够真正接上。
问题不再是 "有没有保存信息"，而是：
有没有保存可以继续工作的上下文。
十七、上下文不是聊天记录
这里尤其容易混淆两个概念。
聊天记录是 "发生过什么"。
工作上下文则需要回答：
- 当前目标是什么？
- 已经确认了什么？
- 结论依据是什么？
- 哪些条件下这个结论成立？
- 哪些问题还没有验证？
- 当前代码对应哪个状态？
- 下一步应该从哪里继续？
例如，"测试通过" 这句话本身几乎没有价值。
真正有价值的信息是：
哪一版代码，在什么环境、什么条件下，通过了哪些测试。
同样，"问题已经解决" 也可能是危险的摘要。
它可能隐藏了：
- 尚未运行的回归测试；
- 尚未确认的生产环境差异；
- 仍然存在的边缘情况。
反过来，如果为了避免信息损失，把所有聊天、日志和命令历史原样保存，接手者又必须重新阅读全部内容。
因此，跨会话协作真正需要的并不是"保存更多文本"，而是：
持续维护一份可验证、可追溯、可修订的工作状态。
十八、这同样应该成为 Harness 的一部分
从这个角度看，Harness 不应只管理：
- 模型；
- 工具；
- 沙盒；
- 权限；
- 指令；
- 执行环境。
对于真正长周期的软件工程，它还需要管理：
工作上下文如何保存、检索、验证和交接。
而且，这份上下文不能只有结论。
它还需要保留：
- 来源；
- 证据；
- 适用范围；
- 版本；
- 当前状态；
- 下一步行动。
否则，模型每换一次、会话每重开一次、工具每切换一次，团队都要重新恢复上下文。
模型推理越来越快以后，这部分重复劳动反而会越来越显眼。
十九、PowerContext：让上下文跟着工作走
OceanBase 开源项目 PowerContext 关注的正是这一问题。
截至 2026 年 9 月 25 日 ，PowerContext 最新稳定版本为 1.1.0 ，于 2026 年 9 月 21 日发布。
它的核心目标不是简单保存聊天记录，而是让人和智能体能够跨会话保存、交接和复用项目上下文。
PowerContext 将不同类型的信息分别管理。
例如：
- Memory：保存长期有效的决策、约束和知识；
- Topic Memory：围绕主题持续吸收新证据并更新知识；
- Handoff：保存当前目标、已验证进展、证据、当前状态和下一步；
- Experience / Skill：将经过审核的经验进一步沉淀为可复用方法。
其中，Handoff 与前面的问题尤其直接相关。
一次工作结束时，不只是写一句"做到这里了"，而是明确留下：
- 当前目标；
- 当前状态；
- 已验证结果；
- 证据；
- 已知遗漏；
- 下一步行动。
接手者因此可以从当前状态继续，而不是重新阅读整段历史。
二十、来源和历史版本同样重要
PowerContext 还保留来源、修订历史和证据引用。
例如，一个 Topic Memory 可以随着新证据不断更新，但此前的版本并不会失去踪迹；系统可以查看精确版本、版本历史和来源链路。
这解决了另一个非常现实的问题：
上下文也会过期。
昨天成立的环境约束，今天可能已经改变。
一个月前验证过的结论，也可能只适用于当时的软件版本。
因此，项目记忆不能只有"记住"和"召回"，还必须支持：
修订、追溯和失效管理。
否则，错误的旧上下文可能比没有上下文更加危险。
二十一、同一份上下文，可以跨智能体复用
PowerContext 已提供 Codex、Claude Code 等多种智能体集成。
不同集成能够共享同一套由 PowerContext Server 管理的项目上下文。具体的自动捕获、上下文注入和 Handoff 能力会因 Host 而有所不同，因此实际使用时仍需以对应集成文档为准。
在存储方面，当前默认可以使用 SQLite；PowerContext 也提供 OceanBase 后端，并在兼容的 Linux 和 macOS 环境中支持嵌入式 seekDB。
因此，一项工作不必绑定在某一次 Agent 会话中。
只要新的接手者拥有相应 Scope 的访问权限，就可以读取已有上下文，再继续工作。
这才是真正意义上的：
上下文跟着项目走，而不是跟着聊天窗口走。
二十二、从 Codex 的经验看，未来真正稀缺的是什么？
Tibo 这场访谈表面上谈的是 Codex。
但背后其实有一条更普遍的工程逻辑。
第一，模型能力会持续变化。
今天 Harness 必须补偿的问题，明天可能已经被模型本身解决。
第二，代码的修改成本正在下降。
越来越多过去需要大量人工投入的升级、重构和检查，会被自动化。
第三，变化越快，边界越重要。
如果接口、不变量和系统责任没有定义清楚，智能体只会更快地产生耦合。
第四，知识和状态不会因为模型变强而自动存在。
为什么这样设计，已经验证了什么，还有什么没做，这些信息仍然需要被明确保存。
所以，未来 Harness 真正长期有价值的部分，可能不是越来越多的补偿代码，而是那些模型能力提升后仍然存在的工程基础设施：
工具、权限、环境、边界、证据，以及可持续交接的上下文。
结语
Tibo 对 Codex Harness 与模型关系的描述，可以压缩成一句话：
模型追上来，就把拐杖撤掉。
Harness 不应该以代码量衡量价值。
它真正要做的是：在模型能力不足时，把产品能力向前推进一步；当模型自己能够完成这一步时，又及时把不再必要的复杂度删除。
但有些东西不能随着 "拐杖" 一起消失。
项目为什么这样设计，哪些结论已经验证，依据是什么，还有哪些事情没有完成，这些才是团队和智能体继续工作的基础。
模型会不断换代，代码也会不断重写，但工作不能每次都从头开始。
这可能才是下一阶段智能体工程真正需要解决的问题。
参考资料
- 丁尼生，《国王叙事诗》相关原文。Project Gutenberg：Idylls of the King
- Gergely Orosz，Building Codex with Tibo Sottiaux ，The Pragmatic Engineer，2026 年 9 月 9 日。访谈原文
- OpenAI Codex 开源仓库。openai/codex
- OpenAI Codex 配置与沙盒文档。OpenAI Codex 文档
- OpenAI，ChatGPT Work and Codex。官方帮助文档
- OceanBase PowerContext 开源仓库。oceanbase/powercontext
- PowerContext 1.1.0 Release。PowerContext Releases
- PowerContext 官方文档。PowerContext Documentation