OpenAI 2026 年 6 月 22 日发了一份新白皮书，叫 Codex-maxxing for long-running work。
这两个 double x 是亮点，直接让白皮书没那么生硬了。
这个白皮书的内容简单来说就是，OpenAI 想让大家常驻在 Codex 中了。
这让我想起了 Mac 为何能入侵用户心智，而现在，Codex 也想这样。
我来给大家详细说说这个白皮书都有啥东西。
白皮书开头先承认，Codex 从生下来就是 for coding work 为了编码开发工作来做的：你可以用 Codex 改 repo、做 diff、review、帮助发版。
但是，OpenAI 说，当 Codex 有了durable thread、shared memory、tools、recurrence，还有一个能 review 产物的地方，后面的重点就变了。
你有可能会想，整这些拗口的英文词儿干啥，这 OpenAI 又开始造词儿了？别急，下面会告诉你这些是干啥的。
不过现在，你需要先记住一点的就是， Codex 想要杀入每个职场人的办公桌面了。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
常驻线程
这份白皮书里，首先介绍的是 durable thread。
大家知道，在 Codex 里面，每个任务都叫一个 thread，也就是线程。
说白了，它就是一个聊天窗口。
只不过微信开个聊天窗口只能聊天，而 Codex 开个聊天窗口可以真的帮你干活。
你每次重新打开一个 thread，都像是公司里新来了一个同事。
虽然他很能干，但你得重新交代背景，比如这个项目干到哪了，前面踩过什么坑，哪些地方不能碰，谁之前说过什么，他都不知道。
durable thread 要解决的就是这个问题。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
OpenAI 举了几个例子来说明：社交反馈监控、开源项目维护、OpenAI CLI、Agents SDK、Chief of Staff。
这些任务都有一个特点：一天干不完。
比如开源项目维护，你不是今天让 Codex 修一个 issue 就完事了。
它可能要长期看 issue、看 release note、看贡献者习惯，还要记住怎么 review。
这类事情如果每次都新开线程，之前的记忆就没了。
所以这节 Codex 更像是在说：重要的工作，可以先把一个 thread pin 起来，让它能够方便的能够找到。
然后你长期在里面处理同一件事，比如上下文、偏好，等慢慢沉淀之后，你这个 thread 就成为了 durable thread ，就有了故事，有了背景，可以沉淀下来了，就是这么简单。
当然，durable thread 也有代价，因为它带着更多 context，跑起来可能会更贵。
语音输入
第二个点是 voice input。
这个词很容易被理解成语音转文字，但其实不是。
OpenAI 给了一个场景：
假如你此时正在看 Codex 做出来的一个页面。
你一边看，一边语音说：
“这个按钮小一点。”
“这句文案不对。”
“我记得微信里有个叫 cxuan 的人提过这事，但我不太确定，你去找找。”
这些话如果让你打字，你很可能会本能地整理一下，删掉不确定的部分。
比如你会想想哪个按钮需要小一点，哪个文案不太对，你可能会想想 cxuan 到底是谁。
但是语音输入不是这样，它就喜欢这些模糊的不确定的线索。
不要觉得这些模糊的细节没啥用，相反，它对 Agent 很有用。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
白皮书里 Jason Liu 的用法是这样的：
他一边在浏览器里看 Agent 做出来的页面，一边录语音吐槽和提修改意见。
录完之后，按下 Enter 发送。
Codex 再把这段语音变成要执行的反馈。
它是在把 review 过程塞回同一个 thread 里。
电话、会议、走廊里随口聊出来的一段话，也一样可以这么用。
Codex 再把这堆原话整理成计划、草稿、页面、报告，或者下一步动作。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
插个队
这一节的主题，叫 Steering，Shape the queue while Codex works。
Codex 正在干活的时候，你可以继续往队列里塞下一步，让 Codex 优先执行你插队的指令。
比如它正在改一个页面。
你看着看着，突然发现按钮太大。
你不用等它整轮跑完，再开一条新指令。
你可以直接补一句：
“这个按钮小一点。”
“这句文案不对。”
“这个做完之后，开一个 PR。”
“先等 preview 部署好。”
“发布前先把 preview 链接给我看。”
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
这就是 steering。
它可以和 voice input 更好的配合。
语音输入负责把你脑子里那堆没整理好的话说出来。
steering 负责把这些话变成 Codex 工作中的下一步。
记忆
这节来讲讲 memory。
我在今年 4 月份的时候就说过，memory 会成为今年优先解决的主题。
这次白皮书对 memory 有了更进一步的解释。
它说的是：长线程里的重要信息，不能只存在于聊天记录中。
聊天记录太长，人也不会逐条看，Agent 自己也可能抓错重点。
所以有用的信息要写出来，变成你能打开、能编辑、能看 diff、能复用的文件。
白皮书给了一个结构：
vault/
TODO.md
people/
projects/
agent/
notes/
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
就是你可以建一个 vault/ 文件夹。
代码仓库放代码。
vault 放工作上下文。
比如你长期让 Codex 帮你维护一个开源项目，这个 vault 可以长这样：
vault/
TODO.md
people/
alex.md
maintainer-lucy.md
projects/
codex-cli.md
agent/
review-rules.md
release-checklist.md
notes/
2026-06-24.md
TODO.md 里放还没处理完的事。
比如：
- 等 preview 部署完成后，把链接发给 cxuan 看。
- 检查 issue #184 里用户提到的参数问题。
- 下次发版前确认 changelog 里有没有漏掉 CLI 参数变化。
people/maintainer-lucy.md 里放人的偏好。
比如：
cxuan 不喜欢大 PR。
他 review 时会先看测试和 changelog。
涉及 release 的改动，最好先给他一个简短 summary。
projects/codex-cli.md 里放项目状态。
比如：
当前重点：减少 reconnecting 相关问题。
已决定：先修日志可观测性，再动重试策略。
阻塞点：还缺 Windows 用户的复现日志。
agent/review-rules.md 里放给 Codex 自己看的规则。
比如：
不要改认证逻辑。
不要顺手重构无关文件。
改 CLI 行为后，必须更新帮助文档和测试。
这样你下次再回到这个 thread，Codex 不用只靠聊天历史猜。
它可以直接打开这些文件，看人、项目、规则、待办分别是什么。
这些东西放在聊天记录里，过几天就很难找。
放进 vault/，就变成了项目的台账。
如果这个 vault 放在 GitHub 里，还有个好处：你能看 diff。
也就是说，Codex 写下来的“记忆”，它改了哪个文件，新增了哪条记录，你都能看到。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
Computer and browser use
memory 讲完之后，白皮书下一节讲的是 Computer and browser use。
这节看起来像工具介绍，其实是在讲权限边界。
OpenAI 把这些入口分得很清楚
browser 适合本地网页、preview、annotation。
chrome 适合需要登录状态的网页，比如你已经登录的后台、工作台、内部系统。
computer use 适合那些只能点 GUI 的任务。
connectors 则是 Slack、Gmail、Calendar、GitHub 这些工作入口。
skills 则是可以复用的工作流程。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
远程控制
这一节是 Remote control。
这节其实没啥好值得拿出来细讲的。
无非就是你可以通过移动设备来实时监控和审查桌面端 Codex 的工作进度。
你人可以不用在工位前，但是活可以让工位上的 Codex 来干。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
自动执行
白皮书里还有一个东西叫 thread automations。
它就是让 Codex 定时回到同一个线程里，看事情有没有变化。
普通 prompt 是：
现在做这个。
thread automation 更像：
每 30 分钟回来看看，如果有新情况，就准备下一步。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
白皮书举了一个 Chief of Staff 的例子。
Codex 每 30 分钟检查 Slack 和 Gmail，看看有没有需要回复的消息。
它可以找上下文，写草稿，列出需要你判断的问题。
但是，它不能直接替你发送。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
三个 loop
白皮书后面还有一节叫 Three examples of loops。
这节其实是在把前面那些东西串起来，形成一个闭环。
前面讲 thread、memory、tools、automation、review，单独看都像功能点。
但真正有用的是 loop。
也就是：Codex 按节奏回来，看上下文，用工具做一部分事，然后把需要人判断的地方交给你。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
白皮书给了三个例子。
第一个就是前面说的 Chief of Staff：定时看 Slack 和 Gmail，找需要回复的消息，补上下文，写草稿。
但是发不发、什么时候发、用什么语气，还得是让人来决定。
第二个是 monitor for feedback。
可以想象一下一个团队在 Slack 等平台里给一段动画提反馈。
Codex 定时去看这个线程。
有新反馈，就先整理成修改清单。
然后去改 Remotion 项目。
Remotion 你可以简单理解成用代码做视频和动画的工具。
改完之后，Codex 重新渲染一版，写清楚这版改了什么，再给一个 review 链接。
也就是说 Codex 负责读反馈、改动画、出新版本。
而人负责看效果、判断创意方向、决定能不能发。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
第三个例子更生活化：get a refund。
这个例子说的是退款流程。
比如你在某个网站申请退款，客服系统一直显示“等待人工接入”。
这时候你不想一直盯着页面。
Codex 可以定时看一眼：客服来了没，对话有没有新消息，退款状态有没有变化。
一旦客服回复了，它先帮你把东西准备好。
比如订单号、付款记录、之前的沟通内容、为什么要退款。
然后它起草一段回复，顺便给你一个建议：下一步应该补截图，还是直接要求退款。
但它不能替你点“确认”。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
这三个例子放在一起，白皮书想说的就很清楚了。
Codex 已经太想把大家能干的活都干完了，除了最后一步它不敢做：点确认按钮。
goal 要写得能验收
白皮书后面讲 goal 。
这个我有太多话想说了。
我之前就跑了一个 75 h 的 goal ，结果产出是一坨，真的没法说。
一个很 low 的 goal 是这样的：
Implement the plan in this Markdown file.
翻译一下就是：按这个计划做。
问题是，做到什么程度算做完？
不知道。
所以 Codex 很容易一直忙，而且还在烧你的 SSD， 看起来很努力，但努力并不一定有结果。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
比较优质一点的 goal 要有验收基线。
白皮书举了 Rich-to-Rust 的例子。
不是简单说“把这个库迁到 Rust”。
它的完成标准是：迁完之后，还能通过原来的单元测试。
我自己用 Codex 的时候，也会越来越喜欢写这种话：
完成标准：
- 原有行为不变。
- 对应测试通过。
- 不改无关模块。
- 输出改动文件、验证命令和失败尝试。
记住一点：goal 一定要能验收。
关于 goal 的更多用法，可以看一下这一篇。
Side panel
最后是一节是 side panel。
这个东西也很好理解。
你不能永远在聊天框里 review 工作。
Markdown、表格、CSV、PDF、slides、网页，这些东西本身就是立体的。
只靠聊天框描述，是说不清楚，讲不明白的。
图源：OpenAI 官方白皮书，本地 PDF 渲染截图
side panel 的价值就是：你和 Codex 在看同一个东西。
你看一个页面，说这个按钮太挤了。
你看一个表格，说这个公式不对。
你看一个 slide，说这个标题太长了。
这些评论会直接变成可执行的下一步指令。
这比在聊天框里说“刚才那个页面左上角第二块下面那个东西”靠谱多了。
我觉得这也是 Codex 往办公桌面走的关键一步。
它不能只是一个聊天窗口。
它得让你看到文件、网页、表格、PPT，然后在这些东西上继续改。
到这一步，Codex 才开始像一个真正能干活的地方。
总结
Codex 更新到现在，一些最有亮点的功能都在这份白皮书中了。
所以最后来给这份白皮书做个总结，如果大家懒得看上面的内容可以直接看总结。
- Codex 要成为你桌面的操作系统
白皮书通篇在讲一件事：如何让 AI 参与那些干不完的长期工作。OpenAI 想让你把 Codex 常驻在桌面，像当年 Mac 入侵用户心智一样，让它变成你工作的默认入口。
- 给 AI 装上脑子
以前每次开新对话都是“新同事”，现在通过常驻线程（durable thread）+ 记忆库（vault），Codex 有了长期记忆。项目背景、人员偏好、踩坑记录全都能沉淀下来，来让新同事直接变为你的老同事。
- 交互方式变了
语音输入可以处理模糊的指令，Steering（插队）让你不用等它干完就能中途指挥，Side panel让你和它同屏看东西。交互方式从发送指令等待结果变成了实时预览。
- 最大的突破是 Loop
Codex 可以定时（比如每30分钟）自动回来检查邮件、Slack、网页状态，自己读反馈、改代码、写草稿。它能帮你把一切都准备好，但绝不替你点击确认按钮，最终决策权永远是你自己。
- Goal 必须要能验收
低级的 goal 会让 Codex 瞎忙，而优质的 goal 必须带验收基线才行。
我是 cxuan，一个长期折腾 AI 工具和 Agent 工作流的人。更多真实使用记录、踩坑复盘和工具整理，可以在微信搜索公众号「cxuanAI」。
资料来源
- OpenAI 官方页面：Codex-maxxing for long-running work，发布于 2026 年 6 月 22 日。
- OpenAI 官方 PDF：OAI_WhitePaper_Codex-maxxing26.pdf。
- 本地素材：
codex-maxxing-assets/，包含原 PDF 和 27 页页面截图。
