本文根据 @jxnlco 的文章编译整理，非逐字翻译；文中观点均属于原作者。
原文：Getting the most out of Codex 全文字符数：3952
大多数开发者第一次使用编码 Agent，都是让它检查代码仓库、生成 diff、运行测试，再创建一个 Pull Request。这仍然是 Codex 最核心的使用方式，但电脑上的大量工作本来就以代码为媒介：执行 Shell 命令、浏览网页、调用 API、导出文档、响应事件，以及触发自动化流程。
当这些操作界面逐渐向 Codex 开放，它就不再只是狭义的编码助手，而更像一个完成计算机工作的系统。Codex app 让这种变化变得具体：同一个线程可以持续保留上下文、调用工具、展示产物，并在多轮指令之间延续工作，而不是每次对话结束后重新开始。
要真正发挥 Codex 的能力，需要把几类功能结合起来：
- 用持久线程保存长期上下文；
- 通过语音、Steering 和 Queuing，让用户在任务进行时继续参与；
- 借助浏览器、Computer Use、MCP Server 和连接器，把行动范围扩展到代码仓库之外；
- 用线程自动化和 Goals，在用户离开后继续推进任务；
- 在侧边栏中直接审阅代码、文档、演示文稿及其他产物。
把持久线程当成工作区
持久线程是能够跨越多次使用、持续保存工作上下文的 Codex 线程。置顶线程让这些长期工作区随时可用，适合承载反复发生的工作流，例如“幕僚长”式助手线程、版本发布、文档审查或外部动态监控。
这类线程不是一次性的短对话，而是可以反复进入的工作空间。Codex 能在之后继续参考先前的决定、偏好和工作背景，省去每次从头重建上下文的成本。将线程置顶后，还可以用 Command-1 到 Command-9 直接跳转到已保存的线程。
用语音留住想法成形前的细节
语音输入的价值，在于它能记录一个想法尚未被压缩成精炼文字时的原始形态。Codex 内置的语音输入尤其适合那些说出来很自然、写出来却很零散的模糊想法：
我记得 Slack 里好像有个叫 Ben 的人提过这件事。
具体细节想不起来了。
请帮我找一下。
对于能够搜索、收集上下文并汇报结果的 Agent，这些信息往往已经足够。任务尚未完全成形时，先进行两三分钟的口述，也比强迫自己立即写出完整需求更有效。
会议逐字稿和口述计划同样如此。与简短摘要相比，原始记录会保留不确定性、语气中的强调，以及尚未完成的思路，这些信息可能正是 Agent 理解真实意图所需要的素材。
Steering 与 Queuing：控制现在和下一步
语音输入与任务过程中的显式控制结合后，会变得更有价值。
Steering（中途引导） 是在 Codex 当前步骤完成前打断任务，并提供新的方向。当 Agent 正在走向错误路径时，用户不必等它全部做完再返工。例如审查网站时，用户可以一边在侧边栏标注页面，一边直接纠正 Codex：
- 把这个元素缩小一点；
- 这两个元素之间的间距不对；
- 这段文案写错了。
Queuing（排队） 则不打断正在执行的任务，而是把下一项工作加入队列。例如：
完成当前工作后，把预览链接通过 Slack 发给审阅者。
Steering 改变 Codex 现在正在做什么，Queuing 决定它接下来做什么。两者都让用户在任务展开的过程中保持参与。
从代码仓库扩展到整个工作流
线程获得连续性之后，下一个问题是它能够在哪些界面上行动。Codex 的操作范围可以分层向外扩展：
$browser适合在侧边栏的内置浏览器中检查和标注网页；@chrome适合依赖用户已登录 Chrome 会话的浏览器工作；@computer适合只能通过桌面图形界面完成的任务。
MCP Server 和连接器把同样的思路延伸到工作流的其他部分。Slack、Gmail 和 Calendar 很重要，因为许多真正需要处理的事情，最初以消息、邮件或日程冲突的形式出现，之后才可能变成代码任务。
Skills 则让重复流程可以复用。当一个工作流已经证明有效，就可以把它封装为 Skill，使 Codex 下次直接沿用，而不必重新摸索整套步骤。
移动端进一步打破了“必须守在电脑前”的限制。任务可以在 Mac 上启动，让文件、权限和本地环境继续留在原处；用户离开桌面后，再通过手机查看进度、回答问题、批准下一步或重定向线程。环境不必迁移，人在移动中仍能参与关键决策。
用线程自动化维持长期循环
自动化让 Codex 按计划执行工作。普通定时自动化适合每次从某个工作区重新开始的重复任务，例如日报或定期仓库检查；线程自动化则会按计划回到一个仍保有上下文的活跃对话。
线程自动化可以理解为定时唤醒同一线程的“心跳”。置顶线程仍要等待用户主动回来，线程自动化却可以每隔几分钟或几小时检查一次状态，持续运行直到满足条件，并根据进展调整检查频率。
一个“幕僚长”式助手线程可以每 30 分钟执行一次这样的任务：
检查 Slack 和 Gmail 中仍未回复、需要我关注的消息，并帮助我判断优先级。
如果有人向我提问，请尽可能深入地调查答案并起草回复，但不要发送。
用户回来时，收集上下文这一成本最高的部分往往已经完成，而最终发送什么仍由人决定。
线程自动化也适合持续处理反馈。它可以监视 Pull Request 评论、Google Docs 批注或 Slack 回复，在用户离开后继续推动相关工作。
例如，审阅者在 Slack 中发布了一段动画视频。线程自动化可以定期检查讨论，在收到意见后渲染新版，再回到同一线程回复并 @ 审阅者。如果某个集成无法完成最后的上传步骤，桌面自动化还可以通过 GUI 补上这一环。这个循环横跨 Slack 的反馈、代码库中的渲染，以及桌面端的最终上传，但仍由同一个工作流串联起来。
Goals 需要明确终点和验证器
Goals 最适合那些存在真实终点、Agent 可以长期推进的任务。仅仅写下“实现这个 Markdown 文件中的计划”，并不是一个足够强的 Goal；更好的目标应包含可测量的成功标准。
例如，把一个内部工具从 Python 迁移到 Rust 时，可以先创建新目录，再明确规定：只有新版实现的单元测试全部通过，迁移才算完成。
Goal 把持续执行与验证器结合起来。用户需要定义期望结果、停止条件，以及能够判断 Codex 是否正在接近目标的信号。常见的验证器包括：
- 测试套件；
- 性能基准；
- 缺陷复现步骤；
- 验证矩阵；
- 必须持续通过的端到端工作流。
目标可以定得大胆一些，但没有验证，它就只是一种愿望。
在侧边栏里审阅和修正产物
侧边栏让产物停留在生成它的对话旁边。用户不必先导出文件，再切换到另一个应用里去审阅。产物可以是代码，也可以是演示文稿、PDF、网页、数据表，或工作过程中生成的其他内容。
它尤其适合四类工作：检查产物、标注需要修改的地方、操作网页界面，以及审阅变更。Markdown、电子表格、数据表、文档和幻灯片都可以留在当前对话旁边直接查看、批注与迭代。
演示文稿或 PDF 可以一直打开在生成它的线程旁边，随时接受直接审阅和修正。
内置浏览器还允许 Codex 打开已经渲染的页面、控制页面，并直接响应用户在界面上的标注。网页由此同时成为输出和控制界面：Codex 可以创建产物，在侧边栏打开它，检查和调试，再围绕同一个对象继续修改。
以下几类载体尤其适合这种模式：
- 用
index.html制作轻量静态产物； - 用 Storybook 审查 UI；
- 用 Remotion Studio 制作程序化动画；
- 用浏览器演示文稿完成展示；
- 用数据应用承载分析流程。
一个 index.html 文件无需服务器，也能成为可长期保留的交互式产物。线程自动化还可以随时间刷新静态产物，让用户再次进入线程时，已经有新的内容等待审阅。
把共享记忆放到线程之外
长期线程如果能共享对话之外的记忆，会更有价值。这里的共享记忆，是存放在单一线程之外、可以显式检查和维护的持久上下文，使未来的工作能够从确定的位置继续。
一种可行方式是把长期线程锚定在 Obsidian Vault 中。它本质上是一组普通文件，便于检查、编辑、移动和长期保存，也可以通过云存储、Git、Dropbox、Google Drive 或其他适合自己工作流的方式同步。例如：
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/顶层的 AGENTS.md 可以规定 Codex 应如何更新这个工作区，怎样记录人员、项目、决定和仍未闭环的事项。重点不是复制某一种固定目录，而是告诉 Agent：长期上下文应放在哪里、哪些信息值得保留，以及什么时候不应该制造无意义的文件变动。
一份实用的规则可以包括：
- 把
~/vault视为长期工作记忆； - 优先维护权威笔记，避免笔记无限分散；
- 明确区分待办、人员、项目、每日摘要和临时记录；
- 保存决定、阻碍因素、负责人、日期和有用链接；
- 没有实质变化时，不要反复改动 Vault。
代码仓库保存代码，Vault 保存持续变化的上下文：涉及哪些人、发生了什么、哪里受阻、下一步需要跟进什么，以及那些不写下来就会随会话结束而消失的信息。重要背景不应只留在聊天记录里，而应被写到下一条线程能够重新拾起的位置。
原作者还提到，Codex 在 Settings > Personalization > Memories 中提供了官方自带的记忆功能，用于本地回忆偏好、重复工作流和已知陷阱。它是对显式写下的上下文的补充，而不是取代后者；Chronicle 也通过近期屏幕上下文帮助 Codex 建立记忆。
从代码出发，但不止于代码
Codex 仍然从代码起步，但围绕代码发生的更多工作，已经可以通过同一个系统触达：MCP Server、浏览器界面、桌面控制、线程自动化，以及可以直接审阅的产物。
这改变了人与 Agent 的控制方式。Steering 负责纠正正在进行的工作，Queuing 安排下一项任务，线程自动化在人离开时保持工作流活跃，Goals 则提供一个 Codex 可以持续追赶的明确终点。
于是，一条工作流可以从指令开始，经过实际执行，再进入产物审阅；即使中途离开代码仓库，它仍然能够在 Codex 中继续推进。