原文标题：Codex-maxxing
原文作者：Jason Liu
编译：Peggy

编者按：AI Agent 正在从「写代码的工具」，变成一种新的工作操作系统。

本文作者 Jason Liu（OpenAI Codex 团队工程师）以自己使用 Codex 的经验为线索，记录了这一变化如何发生：从置顶线程、语音输入、共享记忆，到浏览器控制、远程操作、Heartbeats 自动循环和侧边面板，Codex 不再只是一个等待 prompt 的聊天窗口，而开始成为一个可以承载任务、记住上下文、生成产物并持续推进工作的空间。

最值得关注的，不是 Codex 能不能写出更好的代码，而是它正在改变「工作如何被组织」。过去，AI 的使用常常停留在「一问一答」：用户提出需求，模型给出结果，任务随对话结束而中断。但在这套新的工作流里，线程可以长期存在，记忆可以沉淀为文件，任务可以定期自动执行，用户可以随时介入、审阅和修正，最终形成一个小型的运行循环。

这意味着 Agent 的价值正在从「能力」转向「连续性」。它不只是帮人完成某个单点任务，而是在不同工具、文件、浏览器、Slack、Gmail、日历和本地应用之间建立连接，让工作在用户离开后仍然保持推进。对于知识工作者来说，这可能是 AI 工具真正进入日常生产流程的关键一步：不是替代某个动作，而是让更多工作不再死在一次 prompt 之后。

以下为原文：

Codex 不只是写代码，而是在接管工作流

在 Codex 出现之前，我就已经大量使用编程 Agent 了。不过，大多数时候，我是在专门为编程工作设计的界面里使用它们：生成 diff、修改代码仓库、交付代码。

大约从 11 月开始，我开始把它们推向知识工作场景。我用 Slidev 做演示文稿，把 Agent 当成带语音输入的笔记员来用，也一直在寻找其他可以由编程 Agent 协助生成的产物：一个 index.html、一个 PDF、一张电子表格、一套幻灯片。

最新一轮 Codex App 的升级，是我用过的第一个真正让这种更广义工作模式显得「原生」的产品。Codex 依然非常擅长写代码，但更有意思的变化在于，它开始给我的工作提供一个可以「安放」的地方。

真正改变我使用习惯的，是我学会了给工作建立一个运行循环：一个可长期保存的线程、共享记忆、能够操作我电脑的工具、可以随时介入和恢复任务的方式，以及一个能让我直接审阅产物本身的界面。

持久线程

第一个改变我行为的功能，是上下文压缩。

现在，我会为每一个重要的工作流保留一个置顶线程：

我的 Chief of Staff 线程

Agents SDK

OpenAI CLI

Codex for open source

一个专门用来监控 Twitter 的线程

这些都不是短对话。它们是我已经压缩了几个月的巨型线程。它们不断积累历史、偏好和过去做过的决定，而这些信息我不想每次回来时都重新交代一遍。

置顶线程快捷键

你可以通过 Command-1 到 Command-9，直接跳转到置顶线程。

这里当然有取舍。长期运行的线程并不是免费的。如果你之后再次打开它们，对话大概率已经不在缓存里，因此相比新开一个短线程，成本可能更高。但对于我真正关心的工作流来说，连续性是值得的。

语音输入

语音输入能让 Codex 获得更多我真实的思考过程。

它的好处并不在于速度，而在于 Agent 能拿到未经编辑的思考原貌。Codex 内置了语音输入，但我也会使用 Wispr Flow，因为系统级听写会改变我向其他工具输入上下文的方式。如果我正在规划一项工作，我可能会说：「我记得 Slack 里有个叫 Ben 的人提过这事，我不太记得具体是什么，你去找一下。」这句话如果打出来，会显得模糊又烦人，但说出来却非常自然。

转录文本也是如此。如果我想写一篇文章，我可以给某个人打电话，录下对话，或者用手机上的 Granola 记录一次线下谈话，然后把转录稿作为起点材料。很多计划之所以会变得更好，是因为模型拿到了我混乱但真实的想法，而不只是被我打磨过的版本。

Steering：持续引导

语音输入在和 Steering 结合时会变得更有用。

Steering 允许你在一次工具调用之后，继续注入下一条消息。比如我在审阅一个网站时，可以一边看一边继续说：

把这个调小一点

这句文案不对

这两个元素之间的间距感觉不舒服

完成之后打开一个 PR

等预览部署完成

把预览链接发给需要在 Slack 上审阅的人

我不需要等每一步完成之后，再决定下一步做什么。我可以在 Agent 还在工作时继续追加意图，然后带着已经排好队的任务离开。

之后，Heartbeats 可以在我离开后继续监控 PR 或 Slack 线程。工作单位不再是「一个 prompt，一个回答」，而变成了一个小型运行循环。

记忆

一旦线程开始长期存在，它们就需要某种不依赖单一代码仓库的共享记忆。

关键不只是保存消息历史。一个长线程当然可以记住很多东西，但如果那些有用的信息没有被序列化到某个持久位置，它们就会被困在线程里。记忆系统的意义在于，把线程学到的东西转化成一种我可以检查、编辑、比对 diff、并重复使用的产物。

我的大多数长期线程都从一个 Obsidian vault 开始：

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

在最上层，我会保留 AGENTS.md 指令，内容包括：当你对某个人有更多了解、推进了某个项目，或者关闭了一个待办循环时，请更新 vault 里对应的页面。

这个 vault 就是 Agent「居住」的地方，它独立于任何单个项目。代码仓库存放代码；vault 则存放围绕我工作的滚动上下文：人物、决策、未闭环事项、每日笔记、项目状态，以及那些原本很容易在线程之间丢失的理解。

我也会把这个 vault 作为一个 GitHub 仓库来维护。这样做给我带来两个好处：

它可以在云端运行；

diff 成为审阅记忆的界面。

当 Agent 更新 vault 时，我可以阅读 diff，看看它认为哪些内容重要到值得被记住。这个审阅步骤很关键。我不希望常青线程悄悄在对话历史里积累一种模糊的「感觉」。我希望它把真正发生变化的事情写下来：这个人偏好什么，这个项目在等什么，这个决定已经做出，这个循环已经关闭。

这也是为什么我喜欢把记忆做成文件。文件会迫使 Agent 把经验压缩成一种能够脱离线程继续存在的形式。如果线程消失了、压缩得很糟糕，或者继续依赖它变得太贵，有用的知识仍然在那里。

到了这个阶段，置顶线程开始不再像聊天窗口，而更像是不同的工作人员在阅读同一本笔记本。

Codex 在 Settings > Personalization > Memories 中也有第一方记忆功能。我把它理解为一种本地召回层：它适合记录稳定偏好、重复工作流、项目惯例和已知坑点，但不能替代被提交进仓库的指令，也不能替代一个显式的 vault。Chronicle 在这里尤其有意思，因为它可以利用最近的屏幕上下文来帮助构建记忆。我还没有认真使用它，而且文档也明确说明，它是一个需要主动选择加入的研究预览功能，在权限、速率限制、提示注入和未加密本地记忆文件等方面都有真实取舍。但从方向上看，它指向的正是我关心的事情：工作应该留下结构化记忆，而不只是留下更长的聊天记录。

电脑与浏览器使用

一旦一个线程拥有了记忆，下一个问题就是：它能接触到什么？

在我自己的理解里，最有用的区分是：

$browser：用于我想检查和标注的本地网页界面；

@chrome：用于已登录的浏览器状态和多个标签页；

@computer：用于那些只能通过图形界面完成的工作。

如果我正在迭代一个本地应用，我想用 $browser。如果我需要在一个已登录的浏览器会话里操作，我想用 @chrome。如果完成任务的唯一方式是点击某个桌面应用，那我就需要 @computer。

在我的工作电脑上，Twitter 登录在 Safari 里。如果我让 @computer 在那里读取 Twitter，它工作时我就不能用 Safari 了。而当我希望 Agent 同时使用多个已认证标签页、但又不想接管我正在使用的整个应用时，@chrome 会更合适。

Connectors 则把这种能力延伸到了我真实工作的其他部分。我最常用的是 $slack、$gmail 和 $calendar，因为很多工作在变成代码之前，首先会出现在 Slack 线程、收件箱和日历里。

Skills 则让重复工作流变得可复用。Skill Creator 和 Skill Installer 是很好的起点。Skill Installer 允许你直接从 composer 添加 OpenAI 推荐的 skills。Codex pets 发布后，我用它安装了 Hatch Pet skill，但真正有价值的是这种通用模式：一旦你成功做过某件有用的事，通常就可以把它打包起来，让 Codex 下次不需要重新学习整个流程也能再做一遍。

持续推进工作

远程控制

远程控制让这些更长的工作循环变得可携带。

Codex 可以继续在那台已经拥有你的文件、权限和本地环境的机器上工作，而你则可以通过手机查看进展、审阅它发现的东西、回答问题、批准下一步，或者在不用回到桌前的情况下改变方向。OpenAI 把它描述为一种可以随时随地与 Codex 协作的方式。

当 Codex 已经在执行一个长期任务，而你又想保持推进势头时，这一点最重要。你可以启动一个任务，然后离开；当它抵达某个需要决策的节点时，再用手机进行引导。

这与置顶线程、语音输入和 Heartbeats 重要的原因是一样的：工作不再因为我换了地点而暂停。一个线程可以继续运行，而我只需要投入足够少的注意力，帮助它解锁下一步。

Heartbeats

置顶线程很有用，但它们仍然会等待你发出指令。Heartbeats 则让它们能够周期性运行。

Heartbeat 是一种线程本地自动化。你可以说：「每隔几个小时帮我看一下这个。」然后这个线程就可以为自己设定计划。一个线程可以有多个日程安排，可以一直运行直到某个条件被满足，也可以随着时间调整自己的执行频率。

Chief of Staff

我的 Chief of Staff 线程每 30 分钟运行一次：

每 30 分钟检查一次 Slack 和 Gmail，看看有没有需要我注意但尚未回复的消息。
帮我判断哪些事情最重要。
如果有人问我问题，尽可能深入研究答案，并为我草拟回复，但不要发送。

当我回到 Slack 时，很多回复往往已经在草稿里了。我仍然决定哪些内容要发送，但最费力的上下文收集已经完成了。

监控反馈

同样的模式也适用于审阅循环。Heartbeat 可以监控 Google Docs 评论、pull request 评论或 Slack 回复，并在反馈出现时继续推动工作。

我最喜欢的一个例子来自一个动画项目。我把一个视频发到 Slack 上，然后让 Codex 每 15 分钟检查一次线程，看看有没有反馈；如果有评论，就重新渲染一个新版本，并在该线程里回复、标记审阅者。Slack MCP 服务器无法上传文件，于是 Agent 使用 @computer 点击「Add file」按钮，仍然把修订后的渲染文件发了上去。

有意思的不只是它每 15 分钟检查一次 Slack，而是这个循环跨越了多个工具边界：Slack 用来收集反馈，Remotion 用来渲染，@computer 用来上传。当 Heartbeats、connectors 和电脑操作结合在一起时，它们就不再像一个个独立功能，而变成了一个无需我坐在那里也能持续运行的反馈循环。

申请退款

最近，我有一个包裹被偷了。Amazon 告诉我，大概要等 25 分钟才能和真人客服沟通。于是我创建了一个带 @computer 的线程，并告诉它：

每 5 分钟检查一次，看看客服人员是否已经加入这个对话。
如果他们加入了，尽你所能帮我争取退款。
一旦对方回复，就改为每分钟检查一次，这样你可以更快回应。

等我洗完澡出来，退款已经处理好了。

我的许多 Heartbeats 也会更新我的 Obsidian vault，把它作为一种显式记忆。

Goals

我还在学习如何更好使用的最新功能，是 Goals。

你应该给它设定更有野心的目标。一个弱目标是：「执行这个 Markdown 文件里的计划。」一个强目标则应该有真正的成功标准，让 Agent 能持续朝着它推进。

上周，我尝试把 Python Rich 库迁移到 Rust。由于原项目本身已经有一套庞大的单元测试，我就可以设定这样一个目标：把 Rich 迁移到 Rust，但它必须通过原 Python 库的所有单元测试。

这套测试给运行过程提供了一个真正的判定标准：Rust 版本只有通过与 Python 原库相同的测试，才算完成。

这不同于和 AI 进行一场漫长对话，积累一个 Markdown 计划，然后最终说一句：「实现它。」执行效果的上限，取决于你给出的目标和验证方式。没有验证的野心，只是愿望。

AI 真正进入工作流

侧边面板

Codex 里最让我兴奋的部分，是侧边面板。

人们很容易把它理解成一个预览发生的地方。但这种理解低估了它。侧边面板是 Codex 不再只是一个聊天应用，而开始成为工作发生之处的地方。

对我来说，它承担三件事：检查产物、操作网页界面、审阅变更。在这三种情况下，我都可以查看并评论 Agent 正在操作的同一个对象。

检查产物

Markdown、电子表格、CSV、PDF 和幻灯片都可以放在那里。

Markdown 可以评论。电子表格可以渲染公式，并支持单元格编辑，我会用它来管理 Codex 开源计划。CSV 会显示成表格，而不是原始文本。PDF 可以直接渲染，这对 LaTeX 尤其有用。幻灯片也可以在不离开应用的情况下创建和审阅。

关键不只是 Codex 能够生成这些产物，而是我可以在不打断循环的情况下检查和标注它们。

操作网页界面

应用内浏览器更有意思。Agent 可以看见它，通过 $browser 使用 JavaScript 控制它，而我可以直接在自己正在查看的内容上留下标注。

有几个网页界面，是我现在经常以这种方式使用的：

index.html，用于轻量级静态产物；

Storybook，用于审阅 UI 组件；

Remotion Studio，用于程序化动画；

Slidev，用于演示文稿；

Streamlit，用于数据应用。

最小版本往往是最好的。你可以让模型创建一个带 JavaScript 和 CSS 的单文件 index.html，在侧边面板中打开它，然后立刻开始交互。不需要服务器。我一直在尝试用 Heartbeats 随时间更新一个静态 index.html，这样每次我回到线程时，已经有一个新鲜的产物在等着我。

Thariq 有一篇很好的文章，讨论为什么相比 Markdown，他更偏好 HTML 作为输出格式。我认为这个直觉是对的。一旦输出变成一个小型应用，而不只是一个文档，人与产物之间的关系就改变了。

如果我需要更重的东西，也可以用 Vite 应用，但那样我就需要保持一个服务器运行。一个纯 index.html 要持久得多。

做动画时，我经常把 Storybook 和 Remotion Studio 并排打开。我可以留下类似「让这个弹一下」或「这个应该更大一点」的评论，而 Agent 可以检查我正在看的同一个浏览器状态，包括动画中的当前帧。

做演示文稿时，我经常使用 Slidev。Codex 可以检查幻灯片，发现被截断的内容，在不同页面之间切换，并在我审阅时回应标注。

我也期待这种方式未来在 Streamlit 和 Jupyter 等工具中变得更有用。不同的人本来就生活在不同的应用里。Codex 正在越来越多地进入他们所在的地方。

Codex 越是拥有可以记忆、回访、检查和行动的地方，我的工作就越不容易死在一次次 prompt 之间。这才是我真正关心的变化：不是 Agent 能替我写代码，而是当我离开之后，更多工作仍然可以继续推进。

[原文链接]

欢迎加入币营 Coincamps官方社群：

X 官方账号：https://x.com/coincamps

Telegram 订阅群：https://t.me/coin_camps