OpenAI 发了篇白皮书，叫 Codex-maxxing for Long-Running Work，讲怎么把 Codex 从一次性的对话工具变成一个能长期持续工作的系统。二十多页，核心是"Loop"这个概念——让多个功能组合成一个持续运转的工作流。
有几个概念我觉得挺有用的，结合自己的使用体验聊一聊。
持久线程
白皮书里说，给重要的工作固定一个线程，上下文、偏好、开放问题都在那里累积，直到问题解决完。不是每次开新对话重新来过。
我最早用 codex 的时候就是开一个会话用到底，后来发现上下文太长回复会变慢，就改成频繁开新会话。但每次开新会话都要重新描述背景，很烦。持久线程的思路是中间态——保持上下文，但不是无限制地堆。这个平衡点我还没找到，但方向是对的。
记忆
白皮书推荐了一个 vault 结构，独立于对话历史，专门存工作上下文：
vault/ TODO.md people/ projects/ agent/ notes/关键区别是：Git 管代码，vault 管工作上下文。vault 放在 GitHub 上时，每次改动在 diff 里都看得见。
我现在的做法还比较原始——在项目目录里建了一个 prompts.md，把常用的 prompt 模板和项目背景写进去，每次开新会话先把这个文件丢给 AI。虽然效果还行，但跟白皮书说的 vault 比起来，差距还很大。下一步打算试试 vault 的结构。
Steering
这是白皮书里我觉得最有意思的一个概念。它说的是：在 Codex 还在干活的时候，你就开始添加下一条指令。不是等它做完再给新任务，而是边做边调方向——"这个做小一点"、"文案不对"、"做完了就开 PR"。
我实际用 codex 的体验是，遇到耗时的任务，确实会等它跑完再看结果，然后发现方向偏了再让它重新来。Steering 的做法可以减少这种返工。但我还没试，因为习惯了等结果再反馈。这是一个可以改进的地方。
三个实际循环
白皮书举了三个例子，我觉得最有参考价值的是一个叫"幕僚"的循环：定时检查 Slack 和 Gmail，找需要关注的消息，搜索上下文，起草回复，最后由用户决定发不发。
这跟我想要的效果很接近。我也想让 AI 帮我做一些日常的监控和整理工作，不需要我时刻盯着。但目前用 codex 还没做到这个程度，主要是长任务挂了没人盯着我不放心。
不过总体来看，白皮书里的方向是对的。AI 不应该是你问一句它答一句的工具，而应该是一个持续在运转的进程。这个概念，我打算下一篇详细聊聊。
