TECH OBSERVATION

 硅基旅人  /  EDITED BY 旅人

OpenAI 白皮书原封面，主题是 Codex 如何支持长线工作

它讲的不是功能，而是工作有了“居住地”

这份白皮书的题目是 Codex-maxxing for long-running work。直译有点别扭，大意可以理解为：如何把 Codex 用到长线工作里，让项目不被一轮聊天、一条命令、一次会话切断。

原文开头的判断很清楚：Codex 当然仍然擅长写代码，但更有意思的变化，是它给工作提供了一个可以“住下来”的地方。很多任务真正难的不是第一步，而是第二天还能不能接上，半路被打断以后还能不能恢复，多个工具、文件、反馈、审批能不能留在同一个上下文里。

白皮书用 Jason Liu 的实践做例子。他把 Codex 放进日常工作：做演示、整理 transcript、处理表格、操作浏览器、跟进重复性任务。这里的 Codex 不像一个单纯的问答框，更像一个工作台：你把上下文放进去，它帮你查、改、整理、等待、回到下一个动作。

Jason Liu 的日常工作流示例，Codex 被用在演示、转录、表格和浏览器任务里

第一层：线程要能长期存在

原文第一章讲 durable threads，也就是“耐久线程”。对重要工作来说，一个被置顶的线程可以变成项目的家：旧决策、偏好、待办、开放问题、上下文，都在这里慢慢积累。

这和“开一个新聊天问一次”不是同一种使用方式。比如 Chief of Staff 类任务，需要记住消息、会议、open loop；CLI 或开源项目相关任务，需要记住命令约定、仓库结构、review 偏好；社交反馈监控，需要记住哪些问题反复出现、哪些信号值得跟进。

白皮书也提醒了一个边界：长线程会携带更多上下文，运行成本可能比短线程更高。换句话说，不是什么事情都值得放进长期线程。真正适合的，是那些你知道未来还会回来、还会继续推进、还会需要旧信息的工作。

Durable threads：把重要工作流放进固定线程，积累上下文、偏好和开放问题

这里有一个细节很重要：原文把语音输入和 steering 放在 durable thread 后面讲。语音输入的价值不只是快，而是它能把人脑里还没整理好的东西带进上下文。

比如你可能会说：“Slack 里好像有个叫 Ben 的人提过这件事，我不太记得了，你去找一下。”这种话打字会显得散，但真实工作经常就是这么开始的。模型拿到这种“乱糟糟但真实”的输入，反而更容易知道该从哪里查。

Steering 则是另一件事：Codex 正在工作时，你可以继续补方向。页面看起来太大、文案不对、间距不舒服、完成后开 PR、等预览部署、发出去前先给我链接，这些都可以在循环中继续加进去。它让人不是等在终点验收，而是在中途持续调方向。

第二层：记忆要能打开、能修改、能审查

长线程解决的是“这段对话不断线”，但它还不够。白皮书第四章讲 memory，核心不是让模型悄悄记住更多，而是把记忆变成你可以打开、编辑、diff、复用的东西。

原文用了一个很好懂的区分：仓库保存代码，vault 保存工作周围的滚动上下文。比如人和人的偏好，某个项目卡在哪里，某个决定为什么做，哪些循环已经关闭，哪些还要继续。

这点和很多人对 AI 记忆的想象不一样。它不是让系统在聊天历史里默默积累模糊印象，而是把“发生了什么变化”记录下来。谁被提到了，就更新相关人物笔记；项目往前走了，就更新项目页；loop 关闭了，就标记关闭；做了决策，就写下决策和原因。

Memory vault：仓库保存代码，vault 保存项目周围的滚动上下文

如果 vault 放在 GitHub 里，记忆甚至可以变成一种可 review 的表面。你能看到 Codex 认为哪些信息重要到值得写下来，也能在 diff 里纠正它。

这其实是一条很现实的边界：长期工作的 AI 系统不能只靠“我记得”。它需要有可检查的记录。否则时间一长，人就很难知道模型到底保留了什么、误解了什么、把哪些临时判断当成了长期事实。

第三层：让线程接触真实工作表面

有了线程和记忆，下一步问题就变得很具体：这个线程到底能碰什么？

白皮书把几类表面分开：本地网页、预览和标注可以走 browser；需要登录态和多个认证标签页时，可以走 Chrome；只有桌面 GUI 才能完成的事情，再走 computer use；Slack、Gmail、Calendar、GitHub 等工作入口，则通过 connectors 接入；重复工作可以沉淀成 skills。

Computer and browser use：不同任务应该触碰不同的表面，browser、Chrome、computer use 和 connectors 分工不同

这个分类看起来像工具说明，其实更像权限设计。一个长期线程如果能做很多事，就更要清楚它在什么时候用什么表面、哪些动作需要人确认、哪些任务只能准备草稿不能直接发送。

Skills 也在这里变得有意义。一次工作流跑通以后，不必每次重新教 Codex。把说明、参考资料、脚本和检查规则打包起来，下一次就可以从更稳定的位置继续。

第四层：把任务变成可以回来的循环

白皮书第六、第七章讲 remote control 和 thread automations。它们共同解决一个问题：长任务不会一直等在人坐在电脑前的那一刻。

Remote control 的意思不是跳过 review，而是让你在另一个设备上也能靠近这个循环。任务在桌面机器上跑，因为文件、权限和本地环境都在那里；你走开以后，可以从手机查看进展、回答问题、批准下一步，或者让它换一个方向。

Thread automations 则像给线程加心跳。它可以每隔一段时间回到同一个会话里，检查 Slack、邮箱、PR、部署、文档、客服线程或者长命令，而不是每次从零开始。

Three examples of loops：长期工作来自上下文、工具、记忆、周期性和 review 组成的循环

原文给了三个循环例子：

• Chief of Staff：Codex 定期检查 Slack 和 Gmail，找出可能需要处理的消息，搜索上下文，草拟回复；真正发什么，人来决定。
• Monitor for feedback：Codex 监控 Slack 里的动画反馈，更新 Remotion 项目，重新渲染，准备 review 链接；创意判断和最终发布仍由人把关。
• Get a refund：Codex 检查客服是否接入，等对话变化后准备下一轮回复；任务可以在人离开时继续，但边界仍然清楚。

这三个例子共同指向一个变化：AI 不只是“帮我做完这件事”，而是“在条件变化时，帮我把下一步准备好”。真正的动作权，尤其是发送、批准、付款、发布这类不可逆动作，仍然需要人来确认。

第五层：把“完成”说成可验证的目标

第九章讲 goals。原文对比了弱目标和强目标：弱目标只是“按这个 Markdown 文件里的计划实现”；强目标会告诉 Codex 成功标准是什么，比如保持公共 API 兼容，用原来的单元测试作为成功检查，测试通过并记录差异后才算 ready for review。

这个差别非常关键。给 Agent 的目标，如果只是“照计划做”，它很容易变成机械执行；如果目标里有预期行为、评审标准、限制条件和完成定义，Codex 才能自己判断还差哪里。

Goals：好的目标不是让 Codex 照计划做，而是给它可验证的完成标准

原文提到一个 Rich-to-Rust 的例子：目标不是“把库迁移到 Rust”这么泛，而是迁移后要能通过原来的单元测试。测试套件就成了这次运行的真实标准。没有通过同一套测试，工作就还没有完成。

这也是把 AI 用在工程工作里的一个老问题：你不能只给愿望，还要给验收方式。越是长线任务，越需要把“什么叫做好了”写清楚。

侧边栏才是被低估的部分

最后一章讲 side panel。很多人会把它理解成预览窗口，但原文说这低估了它。侧边栏真正的意义，是把 artifact 也放进工作循环里。

Markdown、表格、CSV、PDF、幻灯片，都可以在里面被查看和评论。小网页、Storybook、Remotion Studio、Slidev、Streamlit、Jupyter，也可以变成可交互表面。你和 Codex 不是只在聊天里谈一个抽象对象，而是看着同一个对象，边改边评审。

Side panel：侧边栏让 artifact 进入同一个循环，评论也会变成下一步指令

这就是整份白皮书最值得带走的点：Codex 的方向不是把聊天框做得更聪明一点，而是把聊天、文件、浏览器、记忆、自动化、review 和 artifact 放到同一个工作场里。

一个项目能不能长期推进，很多时候不取决于第一步有多漂亮，而取决于第二次回来时还能不能接上。Codex 想解决的正是这个断裂。

最后说一句

这份白皮书没有给出某个惊天动地的新功能，它更像一份使用观念的说明书：不要只把 Codex 当成“问一次、答一次”的助手，而是把它当成一个可以承载上下文、工具和周期性动作的工作容器。

这也解释了为什么 memory、automation、browser、side panel 这些功能放在一起看时，比单独看更有意思。它们不是几个孤立按钮，而是在拼同一个东西：让工作从提示词变成循环。

完整原文在这里： https://cdn.openai.com/pdf/8a9f00cf-d379-4e20-b06f-dd7ba5196a11/OAI_WhitePaper_Codex-maxxing26.pdf