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