内容
大多数开发者最初把编码智能体用于代码：检查仓库、生成差异、运行测试，然后发起拉取请求。
这仍然是 Codex 的重心。但计算机上的大量工作其实已经由代码来中介：执行 shell 命令、浏览网页、调用 API、导出文档、响应事件，以及触发自动化。随着这些表面可供 Codex 使用，它开始不再只是狭义上的编程助手，而更像一个用于完成计算机工作的系统。
Codex 应用让这一转变变得具体。一个线程可以保留上下文，使用工具，呈现工件，并在多轮提示之间持续推进，而不是在每次交互后重置。
要更充分地使用 Codex，就要把这些能力组合起来：
- 可持久化线程，保留上下文
- 在用户仍参与的情况下进行语音输入、引导和排队
- 浏览器、计算机使用、MCP 服务器和连接器，让 Codex 的行动范围超越仓库
- 线程自动化和目标，在用户离开后继续工作
- 侧边栏，用户可在其中审阅代码、文档、演示文稿和其他工件
可持久化线程
可持久化线程：可长期运行的 Codex 线程，能在重复会话之间保留工作上下文。
置顶线程是让可持久化线程随手可用的一种方式。它们适合以下这类重复性工作流：
- 首席参谋线程
- 发布线程
- 文档审阅线程
- 专门用于外部监控的线程
这些是持久化工作区，而不是短暂聊天。Codex 可以在一段时间内反复回访它们，保留之前的决策、偏好和工作上下文，而这些信息原本都得从头重建。
置顶线程快捷方式让这一切变得实用。Command-1 到 Command-9 可直接跳转到已保存的线程。
语音输入
语音输入之所以有价值，是因为它能在想法被压缩成精炼文字之前，先捕捉到它最粗糙的版本。
Codex 内置语音输入。它尤其适合那些口头说出来很自然、但打字却别扭的模糊起点：
我觉得 Slack 里有人提过一个叫 Ben 的人。
我记不清细节了。
请去查一下。
对于一个能够搜索、收集上下文并反馈结果的智能体来说，这通常已经足够。
它也很适合在任务完全成形前，先进行两三分钟的思路倾倒。
转录文本也有同样的作用。原始会议转录或口述的规划笔记，往往比简短摘要更适合作为输入材料，因为它保留了不确定性、强调语气和未完成的思路。
引导与排队
当语音输入与对正在进行的任务进行明确控制相结合时，会更有价值。
引导：在 Codex 正在执行的任务完成当前步骤之前，插入新的方向并打断其进程。
当智能体正朝错误方向推进，需要在它完成之前纠正时，引导就很有用。例如，在网站审查过程中，用户可以一边在侧边栏中对界面进行标注，一边中断工作：
- 这个再小一点
- 这两个元素之间的间距感觉不对
- 这段文案错了
排队：把工作加入 Codex 的待办队列，等当前步骤完成后再执行。
排队则不同。它不会打断正在进行的任务，而是把下一个任务加到队列末尾。用户可能会这样说：
工作完成后，把预览链接发到 Slack 给审阅人。
引导改变的是 Codex 现在正在做什么。排队改变的是接下来应该做什么。二者都能让用户在工作展开的过程中始终贴近现场。
工具与行动范围
一旦线程具备连续性，接下来要问的就是它能对什么采取行动。Codex 可以分层向外扩展：
- $browser：用于侧边栏中的应用内浏览器，Codex 可在其中检查并标注网页界面
- @chrome：用于已登录的浏览器状态和基于 Chrome 的工作流
- @computer：用于只存在于桌面图形界面中的工作
$browser 适合侧边栏中的浏览审查。
@chrome 适合依赖用户 Chrome 上下文的已登录浏览器工作。
@computer 适合只能通过桌面图形界面完成的任务。
MCP 服务器和连接器把同样的思路扩展到工作流的其他部分。
Slack、
Gmail 和
日历 很重要，因为许多关键任务最初都以消息、收件箱条目或排期问题的形式出现，然后才会变成代码。
技能让重复工作流可以复用。一旦某个工作流证明有用，就把它打包成技能，这样 Codex 就能再次运行，而无需从头重新学习整个流程。
随时随地工作
Codex 移动应用改变了用户必须守在电脑前的情况。任务可以先在 Mac 上启动，因为文件、权限和本地环境都已就绪，然后在用户用手机查看时继续推进。
这在一些细小的时刻也很重要。有人可以在 Codex 运行较长任务时离开工位，到外面接个问题、批准下一步，或者在回来之前重新调整线程方向。本地环境保持不变；用户则不必一直在场。
自动化
自动化按计划运行 Codex 工作。若是应从工作区重新开始的周期性任务，例如日报或例行仓库检查，就使用计划自动化。若计划应回到一个带有运行上下文的活跃对话，则使用线程自动化。
线程自动化：按节奏定时唤醒，并回到同一个 Codex 线程的心跳式周期性调用。
置顶线程很有用，但它们仍要等待用户回来。线程自动化可以每隔几分钟或几小时检查一次某件事，持续运行直到满足条件，并随时间调整执行频率。
首席参谋线程可以每 30 分钟运行一次：
每 30 分钟检查一次 Slack 和 Gmail，找出需要我处理但尚未回复的消息。
帮我优先排序最重要的事项。
如果有人问我一个问题，请尽可能深入地研究答案，并为我草拟回复，但不要发送。
当用户回来时，收集上下文这部分最耗时的工作往往已经完成了。最终是否发送，仍由人来决定。
线程自动化也适合反馈闭环。线程自动化可以监控拉取请求评论、Google 文档评论或 Slack 回复，并在用户离开时持续推动周边工作。
设想一个动画工作流：审阅人在 Slack 中分享了一段视频。线程自动化可以按计划检查该线程，在评论到来时渲染更新版本，并在同一线程中回复并标记审阅人。如果某个集成无法完成最后的上传，桌面自动化可以通过图形界面完成这一步。
这个闭环横跨用于反馈的 Slack、用于渲染的代码库，以及用于最终上传的桌面自动化。
目标
当任务有一个真实的终点，而智能体可以持续朝着它推进时，目标最强大。一个较弱的目标是：
目标：具有终点的较长运行 Codex 任务，智能体可以在一段时间内持续朝其推进。
在这个 Markdown 文件中实现该计划。
更强的目标则具有可衡量的成功标准。
例如，一位工程师可以通过创建新目录、定义目标，并明确终点来把一个内部工具从 Python 迁移到 Rust：只有单元测试通过时，新实现才算完成。
目标将持续执行与验证器结合起来。用户定义结果、停止条件，以及指示 Codex 是否正在接近目标的信号。
有用的验证器包括：
- 测试套件
- 基准测试
- 缺陷复现
- 验证矩阵
- 必须持续通过的端到端工作流
雄心很重要，但没有验证，它就只是一个愿望。
侧边栏
侧边栏让工作始终伴随产出它的对话。用户不必导出工件并切换上下文，而是可以直接在原处审阅。输出可能是代码，也可能是演示文稿、PDF、浏览器页面、表格，或在过程中生成的其他工件。
它尤其擅长以下四项工作：
- 检查工件
- 标注需要修改的内容
- 操作网页界面
- 审阅变更
侧边栏让用户可以在原处审阅 Markdown、电子表格、数据表、文档和幻灯片。他们可以检查、批注并修改工件，而不必打断工作流。
批注
演示文稿或 PDF 可以继续在生成它的线程旁边打开，方便直接审阅和修正。
Codex 中的表格
应用内浏览器让 Codex 能检查渲染后的页面、控制页面，并直接对正在审阅的界面上的批注做出响应。页面或工件上的评论会保留在工作流中，而不会变成一个独立交接。
网页既是输出，也是控制界面。Codex 可以构建一个工件，在侧边栏中打开它，检查、调试，并在原处持续打磨同一个对象。
这些界面尤其适合：
- 用于轻量静态工件的 index.html
- 用于界面审查的 Storybook
- 用于程序化动画的 Remotion Studio
- 用于演示的基于浏览器的幻灯片
- 用于分析工作流的数据应用
单个 index.html 文件就可以变成一个持久的交互式工件，无需服务器。线程自动化还可以随时间刷新静态工件，让用户回来时看到新的内容在等待处理。
共享记忆
当长期运行的线程在单个对话之外共享记忆时，它们会变得更有用。
共享记忆：存储在单个线程之外的持久上下文，使未来的工作可以从明确且可审阅的内容继续。
一种持久化模式是把长期线程锚定在 Obsidian 知识库中。实践中，这意味着一个纯文件文件夹，便于检查、编辑、移动，并长期保存。团队可以把这个文件夹存放在云存储、Git、Dropbox、Google Drive 或其他适合其工作流的同步层中。
知识库可能长这样：
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
在顶层，AGENTS.md 可以定义 Codex 在了解更多关于人员、项目、决策和未闭环事项时，应该如何更新这个工作区。
不要照搬某一种固定的知识库结构。要教智能体：持久上下文应存放在哪里、应保留哪些上下文，以及何时不该制造额外变动。
一份实用的 AGENTS.md 可能会写道：
- 将 ~/vault 视为持久工作记忆。
- 优先使用权威笔记，而不是让笔记四处散落。
- 明确分流 TODO、人员、项目、每日摘要和草稿笔记。
- 保留决策、阻塞项、负责人、日期和有用链接。
- 如果没有实质变化，就不要折腾知识库。
仓库存放代码。知识库存放滚动上下文：相关人员、发生了什么变化、卡在哪里、接下来需要跟进什么，以及在会话之间原本会消失的内容。
重要上下文不应只存在于对话转录里。把它写到某个地方，让下一个线程可以接着用。
Codex 在“设置 > 个性化 > 记忆”中也提供了第一方记忆功能。它们为偏好、重复工作流和已知陷阱提供本地回忆层。它们是对显式书面上下文的补充，而不是替代。 Chronicle 则通过帮助 Codex 基于最近的屏幕上下文构建记忆，朝着同一方向推进。
从代码向外扩展
Codex 仍然从代码出发。但围绕代码的更多工作，如今都能通过同一套系统触达：MCP 服务器、浏览器界面、桌面控制、线程自动化，以及可审阅的工件。
这改变了控制模型。引导会中断正在进行的工作。排队会排好下一个任务。线程自动化会在用户离开时保持线程活跃。目标则增加了一个具体终点，Codex 可以持续朝它前进。
现在，Codex 即使在工作离开仓库之后，也能把一个工作流从指令推进到执行，再推进到工件审阅。