让 Codex 形成持续运转的工作循环：4 个核心实践

OpenAI Codex 团队的 Developer Experience Engineer Jason Liu 5 月 17 日在 X 上分享了一篇个人博客 Codex-maxxing，复盘他自己怎么把 Codex 从“写代码的 agent”用成“工作能持续运转的地方”。


文章本质是一份基于他本人重度使用的工作流 playbook——通过多个能力的组合，作者称工作单元从“一个 prompt 一个回答”变成了“持续运行的小型操作循环”。本文挑出其中几个对中文开发者最有借鉴价值的实践来介绍。

Heartbeats：让线程自己驱动自己

Heartbeats 是 Liu 文章里最有故事性的能力——它是线程内置的自动调度器，可以让线程按某个频率自我触发执行。

Liu 给出的几个具体用法：

• Chief of Staff 线程——每 30 分钟扫一遍 Slack 和 Gmail 未回消息，优先级排序后把研究好的回复草稿留在草稿箱里，等他亲自决定是否发送
• Amazon 退款——他遇到包裹被盗，Amazon 客服等待 25 分钟接入，他让线程“每 5 分钟检查客服是否上线，上线后切到每分钟检查一次以加快响应”。等他洗完澡，退款已经搞定
• 动画项目反馈循环——在 Slack 里贴出视频后让 Codex 每 15 分钟检查反馈，根据评论用 Remotion 重新渲染，再用 @computer 点击 Add file 按钮把新版发回 Slack 并 @ 评论者

作者认为这一类用法的关键不在于“它每隔几分钟看一次某个地方”——而在于循环可以跨工具边界。Slack 拿反馈、Remotion 做渲染、@computer 上传——三个原本独立的功能因为 Heartbeats 串成一个闭环。这是他认为 Heartbeats、connectors、computer use 不再像独立功能的拐点。

Goals：野心要配验证，否则只是愿望

Goals 是 Codex 较新的能力，作者承认自己也还在学怎么用好。他给出的核心判断是——弱 goal 是“按这个 Markdown 计划执行”；强 goal 必须自带可以被反复验证的成功标准。

作者原文里有一句被广泛引用的话——“Ambition without verification is just a wish.”（没有验证的雄心只是愿望。）执行的好坏，最终取决于你给的 goal 和 oracle。

他举的例子是上周尝试把 Python 的 Rich 库迁移到 Rust——因为原项目自带大型单元测试套件，他能把 goal 设为“迁移 Rich 到 Rust，且必须通过原库的所有单元测试”。这个测试套件本身就是 oracle——Rust 移植版没通过和 Python 版同样的测试就没完工。

作者特意把这种工作方式与“长对话 + Markdown 计划文档 + ‘执行这个计划’”做对比——后者只是把 prompt 写长了，并没有给 agent 一个能自我验证的目标。

Memory as files：让记忆能被 diff

当线程开始变长，Liu 发现传统的“对话历史记忆”不够用——记忆被困在线程内部，无法跨线程复用，也无法被审计。他的解法是用 Obsidian Vault 把记忆物化成文件：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

顶层放一个 AGENTS.md 写明指令——“在你了解到关于某人的新信息、在某个项目上有进展、或关闭一个 open loop 时，更新 vault 里对应的页面”。

Vault 同时作为 GitHub 仓库托管，这买来两个东西：一是 agent 能在云端工作；二是 diff 成为审计记忆的界面。每次 agent 更新 vault，Liu 通过 diff 就能看到它认为什么值得记。

他对这套设计的核心论点是——文件作为记忆比对话历史更“耐久”：即使线程死掉、compact 出问题、或贵到不想再用，有用的知识仍在 vault 里。pinned 线程因此开始像“不同工人读同一本笔记”。

Steering：边干边说，不必等

Steering 让用户在 agent 还在执行工具调用时插入下一条消息。Liu 举的例子是审一个网站时他可以一边看一边连续说：

• “这个再小一点”
• “这段文案不对”
• “这两个东西间距感觉不对”
• “做完后开个 PR”
• “等 preview 部署完成”
• “把 preview 链接发给 Slack 上需要审查的人”

不用等每一步完成才决定下一步。意图先排队，agent 按顺序消化。配合 Heartbeats，Liu 离开之后线程会继续监控 PR 或 Slack 反馈。这是他认为“工作单元变成操作循环”的具体机制——steering 解决“边干边修正”，Heartbeats 解决“人离开后线程不停”。

侧面板：让工作有地方“住”

Liu 特意把侧面板（side panel）拎出来作为他最兴奋的部分——他认为这不是“预览区”，而是“Codex 不再只是聊天应用、而开始变成工作发生的地方”的标志。

侧面板里能做三件事：检视 Markdown / Spreadsheet / CSV / PDF / Slides 等 artifact；操作内置浏览器（用于 index.html、Storybook、Remotion Studio、Slidev、Streamlit 等）；审阅变更并直接在对象上加批注。

Liu 推崇“最小可行 artifact”——很多场景他会让模型生成一个单文件 index.html（含 JS 与 CSS），直接在侧面板打开就能交互，不需要 server，比 Vite 应用更耐久。他甚至用 Heartbeats 让 index.html 随时间自动更新，每次回到线程就有一份新鲜的 artifact 等着。

真正需要记住的是

Liu 这篇文章的价值不在于“罗列了 Codex 8 个新功能”——而在于他给出了一种把零散功能组装成持续工作循环的心智模型。线程提供持久性、记忆提供跨线程的知识沉淀、Heartbeats 提供时间维度上的自驱动、Goals 提供方向感与验证、侧面板提供工作落脚的地方。每个能力单看都是局部优化，但组装起来确实改变了“工作 vs prompt 工作”的关系。

需要 cool down 的部分——这套工作流的搭建成本不低（一个 Obsidian Vault 加 AGENTS.md 指令本身就要先调好）；Liu 是 OpenAI Codex 团队员工，他熟悉 Codex 的能力边界与最佳实践，文章里的实践可能对他特别合用，对普通用户复制起来未必同等顺手；megathread 持续 compaction 的成本作者自己也提了——长线程不在缓存里时可能比新短线程更贵。

适合借鉴的方向是“把工作单元从一次性 prompt 改成持续循环”这个心智模型本身，而不是直接照搬他的 Vault 结构或 Heartbeat 频率。如果你目前的 Codex 用法仍是“提问—回答—关闭”模式，文章里的任何一个能力（Heartbeats / Goals / Memory as files / Steering）单独引入都可能让工作流升级一个台阶。