The old order changeth, yielding place to new,
旧序更迭，让位于新。
------ 丁尼生，《国王叙事诗·亚瑟之逝》 [1]
楔子
程序员对自己的作品多少有些感情。Tibo 也一样，他怀念深夜用 Vim 写代码、喝着无糖可乐、只管眼前 bugs 的日子；当然，他也记得重构了三个小时才发现走进死胡同，必须从头再来的悲情时刻。
如今，连那些做对了的工作，也可能很快过时。
既然如此，那么围绕模型搭建的这套 Harness 系统，究竟该怎么做？
这篇文章的内容来自于：9 月初，The Pragmatic Engineer 访谈 [2] 中，主持人 Gergely 和 Codex 负责人 Tibo 聊的关于模型和 Harness 的相关内容（文章据访谈内容进行整理，对赞助商的广告和 Tibo 个人的背景介绍部分进行了一些删减）。
本文会聊聊 Codex 如何诞生？为何用 Rust 语言来开发？Tibo 对开源和 code review 的看法。以及在 OpenAI，Harness（Codex）和模型（GPT）的融合过程是怎样的？
欢迎大家关注 OceanBase 社区公众号 "老纪的技术唠嗑局"。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~
模型 & Harness
主持人 Gergely 用自己的经历问过 Tibo：早期 Codex 会按要求修改代码，但不晓得要去跑仓库里已有的单元测试。但过了几个月，Codex 很快就会自己跑测试了。Codex 团队究竟改了什么，是运行脚本里的指令，还是模型？
Tibo 说，这些表现来自 Harness 与模型的共同作用。Harness 把指令、工具、执行环境和权限组织起来，也给模型配上几根"拐杖"，让它做得可靠、高效，行为符合用户的预期。每轮开始时注入的开发者消息，就是其中一种办法：暂时想不到跑测试，那就提醒它。
等模型更能理解用户要求背后的意思，这句提醒就可以省掉。按 Tibo 的观察，随着模型进步，开发者消息会变短，Harness 也会缩小。他用了这样一句话来描述两者的关系：
"从某种意义上说，Harness 总是比模型稍微领先一点。"
工程团队既要照顾眼下的模型，也需要知道下一代模型可能可以走到哪里。为此，Codex 的研究团队与工程团队一起做设计：发现一种失败，或者想增加一项能力，先商量该改 Harness，还是该改模型。Tibo 会把这件事问到月份：
"如果要改模型，需要多久？一个月能做到吗？三个月呢？六个月呢？"
如果训练很快能解决，有时团队会决定 Harness 这边干脆先不做。Agent 也参与这个过程：分析用户反馈，归纳问题，帮助团队确定优先级。工程师的工作清单里，由此多了一类决定：这段代码，值得现在写吗？
Tibo 给团队的提醒是：为了绕过模型缺陷，写出一根一万行代码的拐杖，那么，你多半走错了方向。他用这个夸张的例子提醒大家，关心用户、关心产品，也要关心模型的发展方向。代码写得越多，并不一定离目标越近。
他还提到 /goal 。过去需要它帮助模型长时间守着一个目标，持续跑几天、几周；而在他们观察的新一代模型上，直接交代长期目标，已经能做到原先需要额外机制维持的事。
合不上盖儿的笔记本
Gergely 去过一家 AI 公司的办公室，桌子上的笔记本一直都不关机，电脑上有他员工的数据库，有开发工具，有用顺手的一整套环境配置。因为模型已经能接手工作了，所以笔记本就得陪模型一起一直干活，Agent 一天 24 个小时都在被他的主人剥削。
Tibo 介绍的 Codex 默认在本地沙盒执行工具，需要越过沙盒边界的命令，会向用户申请额外权限。选择云端运行时，任务则进入托管虚拟机，本地主要负责输入和接收结果。
他看好云开发环境再次流行起来。过去，小团队要自己承担配置与维护成本；如果 Agent 能按本地的 SQLite、服务器、MCP 等配置，把云端环境搭起来，再帮忙维护，两边的取舍就会变化。他还在考虑，未来能否一部分任务在笔记本上执行，另一部分放到云端，逐渐用上单台电脑容纳不下的算力和资源。
把 Codex 带进 ChatGPT，团队实际做过的事情更具体：把完整的 Harness 放到一台云端电脑上，还得做得足够高效，才能包含在 Plus 套餐里。Tibo 提到，用户已经能让它安装 Blender，做 3D 建模；团队自己则靠 Codex 帮忙构建基础设施、整合插件架构和库。
从外面看，不过只是应用里多了一个入口。里面却要接通两套技术栈，处理原本在本地运行的 Agent，怎样使用云端资源，以及面向更多人提供相近的能力。
Rust 的边界，和来不及长大的项目
Tibo 最早在 OpenAI 搭的小型 Agent，专攻内部 Python 代码库，目的是帮助研究人员更快地写基础设施。后来，这条研究线与 ASWE（自主软件工程师）项目合并，做成了最初的云端 Codex。Tibo 坦言，当时使用阻力仍然较大，没有找到产品与市场的契合点。团队也发布了 CLI，继续尝试怎样让模型帮上用户的忙。
Gergely 对另一件事颇有疑问：模型当时更擅长 Python、TypeScript，为什么做 Codex，偏偏选了 Rust？
Tibo 的考虑从核心 Agent 开始。它要稳健、安全，运行高效，还要能扩展到很大的规模。团队恰好有优秀的 Rust 开发者，内部模型写 Rust 也不差，编译时的静态检查又能帮助人和 Agent 发现问题。他以前参与过一些项目，起初只是觉得好玩，后来却得扩展到数据中心的规模，因此愿意提前想这些事情，前提是别牺牲太多推进速度。
他也承认，用 TypeScript，甚至 Python，可能一样能做成，将来再重写。更令他在意的是这条原则：
"Agent 本身可以独立于产品存在，把它和产品非常清楚地分开，是一条很重要的原则。"
所有东西放在同一个仓库、用同一种语言，开发时很容易顺手多连一根线，逐渐纠缠在一起。Tibo 认为，Rust 划出的边界，对维持这种分离很有帮助。产品入口可以变化，Agent 核心也有自己的演进空间。
如果重写越来越容易，提前做这些安排还有多大必要？谈到维护时，Tibo 举了升级第三方依赖的例子。有清楚的更新日志，代码文档也写得好，模型就能沿着代码库推理，在几个小时里完成过去常被拖延的工作。再大一些的改动，比如为了新功能、工作负载或新的取舍重做架构，以前可能花上好几年，他认为现在也在大幅加速。
但一个模块会不会牵连其他服务，依然取决于它怎样设计。Tibo 用的是一个带有不变量约束的"盒子"：先约定哪些条件必须始终成立，把边界划对，盒子内部就能快得多地变化，而不影响外部。
他还举了一个颇能说明当下节奏的情景。以前，项目从几个人长到五十人、一百人，也许需要一年，文档和协作方式还有时间慢慢补。现在，可能一个周末，就有一百个 Agent 开始贡献代码。
他设想的这个周末，把软件原本漫长的生长过程压在了一起。拿一个公共接口来说，它被改动以后，哪些调用方得跟着动、哪些兼容条件必须保留，都要及时让其他贡献者知道。原来还能随着招人慢慢补上的约定，现在可能等不起了。
聊到架构意识时，Gergely 还问，每个工程师是不是都得懂这些、提前规划？Tibo 接着说，GPT 模型也越来越擅长考虑长期维护和好的架构。它要判断的，还包括怎样减少日后的维护负担，为下一次产品变化留出空间。
开源，偶尔会很扎心
还有一种失落，来得比模型换代更快。
Tibo 在访谈中说，团队有时正在公开开发一个令人兴奋的功能，还没来得及发布，别人就已经提前 Copy 过去了。Gergely 在节目结尾也提到这种情形：竞争者可能赶在你前面推出你开发出的功能。
"你在公开开发，相当于已经同意了这样一种约定：别人可以复制。"
许可证很宽松，因为这项权利本来就在里面。与此同时，公开仓库与内部代码之间要协调，维护者还会被大量随意提交的 PR 贡献淹没。
可 Tibo 仍然愿意付这笔成本。一个编程 Agent，天然会被用户拿来修改它自己。团队可以从这些改动中学习，也能直接碰到社区正在经历的问题。新同事还没入职，就已经看过仓库、读过 PR；入职以后，让 Codex 陪着读一遍代码，再问些问题，就能开始工作。
说到多模型支持，他用了另一个很具体的例子：用户只想改十行左右的代码，接入另一家模型，却因此要维护一整个 fork，这件事有什么必要？既然代码已经开放，不如直接给用户选择。
明天有个新模型发布，用户可以在熟悉的环境里试，团队也能知道它哪里好、哪里不好。Codex 团队自己就在同一个 Harness 里试其他模型。模型可选，并没有降低他们对模型的要求，Tibo 说：
"我希望我们靠最好的模型、最高效的模型、最好的产品赢得用户。"
找谁来兜底？
把代码合进去以前，依然要有人类来审核。
以前，开发者突然被同事拉住，被要求帮忙 review 代码。小编也对这种切换很有体会：一边开发着数据库内核的代码，另一边不得不停下手头的事，重新进入别人 review 链接的新上下文。
Tibo 早期和研究团队做过代码审查模型，专门追那些不好找的问题。它可能要沿依赖深入三四层，才发现文档说的与第三方库实际做的不同，导致上层代码依赖的条件并不成立。对不熟悉这个库的人来说，光发现问题就可能要花几个小时。
按他的介绍，这类深入验证的能力已经进入主线模型；在 OpenAI 内部，PR 被标记出安全问题，会被自动阻止合并。
但 review 还兼着另一份工作：交换信息、让大家对齐，顺便问清楚"你到底想做什么，这是不是该尝试做的事"。过去，这些讨论常常等到代码写完才发生。Tibo 希望把它们往前移，也可以在 PR 之外一起做设计、确认意图。
正确性与网络安全检查会更多地自动化，这是他的判断。团队仍然需要有机会讨论，某个功能值不值得做，与产品的其他部分合不合得来，后面准备怎样维护。否则，审查者面对的就不只是眼前几百行代码，还有此前未曾说清的一整段来龙去脉。
"你问过 Codex 吗？"
如果这些讨论不围着 PR 发生，人该到哪里找？Gergely 问过 Tibo，一个新人加入 Codex 团队，会怎样熟悉这里的工作方式。Tibo 说，当然先介绍一些很棒的同事；此后，新人有问题，听到最多的一句话大概是：
"你问过 Codex 吗？"
项目现在怎么样，谁在做什么，当初为什么作出那个决定，都可以问。在 Tibo 描述的内部环境中，Codex 接入了 Slack、文档和代码。团队也有意识地把大量工作放在可访问的频道里讨论，把文档开放给较广泛的成员，Agent 才有材料查阅。
整合 Codex 与 ChatGPT 时，它甚至当起了项目记者。团队争论怎样合、叫什么、什么时候推出，连 Work 切换开关本身都讨论过很多轮，Codex 一路记下这些过程。一个后来者看到的，因而可以包括方案被怎样选择，以及中间走过哪些岔路。
Gergely 对此也留了一点犹疑。他在节目结尾说，AI 仿佛一直在看着，有种"老大哥"的感觉，自己还没想好该怎样看待。
至于 Tibo，他已经习惯在会议之间对着手机口述问题，让 Codex 查项目、看使用情况、准备报告。有些大一点的问题来不及白天看，就派它夜里去研究。他说，自己会很期待第二天早上醒来，看看结果。
用来提醒模型跑测试的那句话可以删，暂时用不上的补偿代码可以不写。一个团队为什么选择这个架构，哪些讨论已经有结论，哪些事情还没验证，仍得留下可供下一次工作查阅的依据。
（访谈主体内容结束）
小编评注
Tibo 在这场访谈里，为大家介绍了把 Codex 团队的工作： 先用 Harness 补上模型的短板，等模型赶上来，再把多余的"拐杖"撤掉。
沿着这个思路，还有一个值得思考的问题：模型升级了，项目里已经作出的判断、验证过的结果，以及没做完的工作，都要放在哪里？
比如，同一次排查，代码改动在 Git 里，复现条件在日志里，为什么放弃某个方案，又可能只留在 Agent 的会话里。今天在 Codex 里推进，明天交给另一位同事或另一个 Agent，接手者得重新把这些材料拼起来。材料都还在，工作却未必接得上。
尤其麻烦的是，记录有新旧，结论有适用条件。"测试通过"对应哪版代码？那条环境约束后来改了没有？一份摘要只写"问题已解决"，就可能把尚未完成的检查一并略过；把整段聊天和日志原样交过去，接手者又得重新找出哪些结论仍然有效。 上下文的保存、核验和交接，也需要被当作 Harness 的工程问题来处理。
访谈里已经有一个很具体的例子。Tibo 介绍，Codex 能够查阅团队的 Slack、文档和代码，还记录了产品整合过程中的争论与取舍。团队把这些过程留下来，后来者才有机会追问一个决定是怎样作出的。沿着这个做法再往前想：如果接手的换成另一个工具、另一个会话，这份工作的当前状态和判断依据，能不能也一起交出去？
对于要跨会话、跨工具推进的项目，值得单独建设的，就是这部分上下文管理与交接能力。哪些判断已经验证，哪些问题仍然悬着，下一步从哪里继续，都应连同来源和适用条件一起保存、检索和修订。这样，一次排查留下的记录，才能在下一次工作里用得上。
What's more?
OceanBase 开源项目 PowerContext [3] （项目地址：github.com/oceanbase/p...
拿前面那次排查来说，已经确认的环境约束、放弃某个方案的原因，可以连同依据留在项目记忆里；代码改到了哪里、哪些测试还没跑，则整理进交接记录。下一位接手时，先看这次工作走到了哪一步，再对照当前代码继续检查。相关做法在 《PowerContext 1.0.0 正式发布：前事有据，后事可续》 里有更完整的介绍。
PowerContext 已提供 Codex、Claude Code 等集成，上下文由独立服务管理，可选 seekdb 或 OceanBase 存储。双方接入同一服务、选定同一项目范围并具备相应访问权限，就可以复用已保存的项目记忆，再把整理好的交接内容交给接手者核对。来源和历史版本也会保留，方便回查当时的依据。
PowerContext 项目的代码、接入文档和示例都已开放，欢迎试用，也欢迎大家来 github.com/oceanbase/p... 和我们交流在使用过程中的经验以及遇到的问题~
参考资料
1
丁尼生，《国王叙事诗·亚瑟之逝》: www.gutenberg.org/cache/epub/...
2
The Pragmatic Engineer 访谈: newsletter.pragmaticengineer.com/p/building-...
3
PowerContext: github.com/oceanbase/p...
往期内容推荐
了解更多
添加社区小助手，加入微信交流群~
微信扫一扫赞赏作者
AI 技术 · 目录
作者提示: 个人观点，仅供参考
阅读原文