尧图网站建设 
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 的看法。以及在 OpenAIHarnessCodex和模型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偏偏选了 RustTibo 的考虑从核心 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]项目地址https://github.com/oceanbase/powercontext%EF%BC%89%E5%B0%B1%E6%98%AF%E4%B8%BA%E8%BF%99%E6%A0%B7%E7%9A%84%E4%BA%A4%E6%8E%A5%E5%81%9A%E7%9A%84%EF%BC%9A%E6%97%A2%E4%BF%9D%E5%AD%98%E4%BB%A5%E5%90%8E%E8%BF%98%E8%A6%81%E7%94%A8%E7%9A%84%E9%A1%B9%E7%9B%AE%E8%AE%B0%E5%BF%86%EF%BC%8C%E4%B9%9F%E4%BC%9A%E6%95%B4%E7%90%86%E7%9C%BC%E5%89%8D%E5%B0%9A%E6%9C%AA%E5%AE%8C%E6%88%90%E7%9A%84%E5%B7%A5%E4%BD%9C%E3%80%82拿前面那次排查来说已经确认的环境约束、放弃某个方案的原因可以连同依据留在项目记忆里代码改到了哪里、哪些测试还没跑则整理进交接记录。下一位接手时先看这次工作走到了哪一步再对照当前代码继续检查。相关做法在 《PowerContext 1.0.0 正式发布前事有据后事可续》 里有更完整的介绍。PowerContext 已提供 Codex、Claude Code 等集成上下文由独立服务管理可选 seekdb 或 OceanBase 存储。双方接入同一服务、选定同一项目范围并具备相应访问权限就可以复用已保存的项目记忆再把整理好的交接内容交给接手者核对。来源和历史版本也会保留方便回查当时的依据。PowerContext 项目的代码、接入文档和示例都已开放欢迎试用也欢迎大家来 https://github.com/oceanbase/powercontext 和我们交流在使用过程中的经验以及遇到的问题~参考资料[1]丁尼生《国王叙事诗·亚瑟之逝》: https://www.gutenberg.org/cache/epub/610/pg610-images.html#link2H\_4\_0013[2]The Pragmatic Engineer 访谈: https://newsletter.pragmaticengineer.com/p/building-codex-with-tibo-sottiaux[3]PowerContext: https://github.com/oceanbase/powercontext往期内容推荐了解更多添加社区小助手加入微信交流群~微信扫一扫赞赏作者AI 技术 · 目录作者提示: 个人观点仅供参考阅读原文 Tibo 谈 Codex：harness 总比模型快一步
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 的看法。以及在 OpenAIHarnessCodex和模型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偏偏选了 RustTibo 的考虑从核心 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]项目地址https://github.com/oceanbase/powercontext%EF%BC%89%E5%B0%B1%E6%98%AF%E4%B8%BA%E8%BF%99%E6%A0%B7%E7%9A%84%E4%BA%A4%E6%8E%A5%E5%81%9A%E7%9A%84%EF%BC%9A%E6%97%A2%E4%BF%9D%E5%AD%98%E4%BB%A5%E5%90%8E%E8%BF%98%E8%A6%81%E7%94%A8%E7%9A%84%E9%A1%B9%E7%9B%AE%E8%AE%B0%E5%BF%86%EF%BC%8C%E4%B9%9F%E4%BC%9A%E6%95%B4%E7%90%86%E7%9C%BC%E5%89%8D%E5%B0%9A%E6%9C%AA%E5%AE%8C%E6%88%90%E7%9A%84%E5%B7%A5%E4%BD%9C%E3%80%82拿前面那次排查来说已经确认的环境约束、放弃某个方案的原因可以连同依据留在项目记忆里代码改到了哪里、哪些测试还没跑则整理进交接记录。下一位接手时先看这次工作走到了哪一步再对照当前代码继续检查。相关做法在 《PowerContext 1.0.0 正式发布前事有据后事可续》 里有更完整的介绍。PowerContext 已提供 Codex、Claude Code 等集成上下文由独立服务管理可选 seekdb 或 OceanBase 存储。双方接入同一服务、选定同一项目范围并具备相应访问权限就可以复用已保存的项目记忆再把整理好的交接内容交给接手者核对。来源和历史版本也会保留方便回查当时的依据。PowerContext 项目的代码、接入文档和示例都已开放欢迎试用也欢迎大家来 https://github.com/oceanbase/powercontext 和我们交流在使用过程中的经验以及遇到的问题~参考资料[1]丁尼生《国王叙事诗·亚瑟之逝》: https://www.gutenberg.org/cache/epub/610/pg610-images.html#link2H\_4\_0013[2]The Pragmatic Engineer 访谈: https://newsletter.pragmaticengineer.com/p/building-codex-with-tibo-sottiaux[3]PowerContext: https://github.com/oceanbase/powercontext往期内容推荐了解更多添加社区小助手加入微信交流群~微信扫一扫赞赏作者AI 技术 · 目录作者提示: 个人观点仅供参考阅读原文