多数开发者第一次使用 Codex，通常是从代码任务开始：阅读仓库、修改 diff、运行测试、打开 pull request。
这仍然是 Codex 的核心场景。但电脑上的很多工作本来就被代码和工具包围：执行 shell 命令、浏览网页、调用 API、导出文档、响应消息、触发自动化。随着这些能力逐渐接入 Codex，它就不再只是狭义的代码助手，而更像一个帮你完成电脑工作的系统。
Codex app 让这种变化变得更具体。一个 thread 可以保留上下文、调用工具、展示产物，并在多轮提示之间持续推进，而不是每次对话都重新开始。
想更充分地使用 Codex，关键是把这些能力组合起来：
- 持久线程，用来保存长期上下文
- 语音输入、steering 和 queuing，让用户仍然掌控过程
- browser、computer use、MCP servers 和 connectors，让 Codex 走出仓库
- thread automations 和 Goals，让任务在用户离开后继续推进
- 侧边栏，用来审阅代码、文档、幻灯片、网页和其他产物
- 共享记忆，把重要上下文写到线程之外
持久线程
Durable threads 指的是能在多次会话之间保留工作上下文的长线程。
Pinned threads 是一种很实用的入口。它适合放那些会反复回来的工作流，比如：
- Chief of Staff 线程
- 发布线程
- 文档审阅线程
- 外部监控线程
这些不是临时聊天，而是持续存在的工作空间。Codex 可以在后续继续回到同一个线程，沿用之前的决策、偏好和背景信息，避免每次都从零重建上下文。
快捷键也让它更顺手。Command-1 到 Command-9 可以直接跳转到已保存的线程。
语音输入
语音输入的价值在于，它能捕捉还没有被整理成正式文字的想法。
Codex 内置语音输入。它特别适合那些说起来很自然、打字时却很别扭的模糊起点：
|
|
对于一个能搜索、整理上下文并汇报结果的 agent 来说，这通常已经足够开始。
语音也适合两三分钟的想法倾倒。会议转录、口述规划笔记、未整理的原始记录，往往比一句摘要更有用，因为它们保留了不确定性、重点和没说完的思路。
Steering 和 queuing
语音和显式控制结合起来时，会更有用。
Steering 指的是在 Codex 任务执行过程中插入新的方向，让它在当前步骤结束前改道。
例如在审阅网页时，用户可以一边在侧边栏标注，一边打断当前任务：
|
|
Queuing 则不同。它不打断当前任务，而是把下一步工作排到队列里：
|
|
Steering 改变 Codex 现在正在做什么。Queuing 改变它接下来应该做什么。两者都让用户在任务展开时仍然靠近现场。
工具和可触达范围
线程有了连续性之后，下一个问题就是：它能操作什么？
Codex 可以一层层向外扩展：
$browser：适合侧边栏里的网页检查、标注和 review@chrome：适合依赖用户 Chrome 登录状态的浏览器工作流@computer：适合只能通过桌面 GUI 完成的任务
MCP servers 和 connectors 把同样的思路扩展到更多工作流中。Slack、Gmail、Calendar 很重要，因为很多任务最初不是以代码形式出现，而是以消息、邮件和日程问题出现。
Skills 则适合固化重复工作。当某个流程已经被证明有用，就可以把它打包成 skill，让 Codex 下次不必重新学习这套步骤。
从任何地方继续工作
Codex mobile app 改变了用户必须坐在电脑前的时间。
一个任务可以在 Mac 上开始，因为文件、权限和本地环境都在那里；随后用户离开桌面，只用手机继续确认、补充或改方向。
这在很多小场景里很有价值：Codex 跑长任务时，用户可以离开座位；如果它需要确认，可以在外面回复；如果方向错了，也能及时 redirect。真正留在原地的是本地环境，而不是用户本人。
自动化
Automations 可以按计划运行 Codex 工作。
如果一个周期任务应该从某个 workspace 重新开始，例如日报或常规仓库检查，可以用 scheduled automation。如果调度应该回到一个已有对话，并沿用它的上下文，就更适合 thread automation。
Thread automations 更像心跳式唤醒：按固定节奏回到同一个 Codex thread。
Pinned threads 需要用户主动回来，而 thread automation 可以每几分钟或每几小时检查一次，持续运行到满足条件为止，并随时间调整节奏。
例如，一个 Chief of Staff 线程可以每 30 分钟运行一次：
|
|
用户回来时，最耗时的上下文收集往往已经完成。真正要不要发送，仍然由人决定。
Thread automations 也适合反馈循环。它可以定期查看 pull request 评论、Google Docs 评论或 Slack 回复，在用户离开时继续推进周边工作。
比如一个动画工作流：reviewer 在 Slack 里发来视频反馈，thread automation 定时检查线程；如果有新评论，就重新渲染版本，并在同一个 Slack thread 里回复 reviewer。如果某个集成无法完成最终上传，桌面自动化还可以通过 GUI 补上最后一步。
这个循环会跨过 Slack、代码库和桌面应用，但对用户来说仍然留在同一个工作流里。
Goals
Goals 最适合那些有明确终点、并且 agent 可以持续推进的任务。
一个较弱的 goal 可能是：
|
|
更强的 goal 会有可衡量的完成标准。
例如，把一个内部工具从 Python 迁移到 Rust 时，可以先建好新目录，再把目标说清楚：新实现只有在单元测试通过后才算完成。
Goal 本质上是持续执行加验证器。用户需要定义结果、停止条件，以及判断 Codex 是否更接近目标的信号。
常见的验证器包括：
- 测试套件
- benchmark
- bug reproduction
- validation matrix
- 必须持续通过的端到端工作流
任务可以有野心，但没有验证条件时，它更像愿望，而不是 goal。
侧边栏
侧边栏把工作产物放在生成它的对话旁边。用户不必导出文件、切换上下文，再回头描述问题。产物可能是代码，也可能是 deck、PDF、网页、表格，或者工作过程中生成的其他 artifact。
它特别适合四类工作：
- 检查 artifact
- 标注需要修改的地方
- 操作网页界面
- 审阅变更
Markdown、表格、数据表、文档和幻灯片都可以直接在侧边栏里看。用户可以检查、标注、修改，而不用把这个过程变成另一轮交接。
如果是 deck 或 PDF，它可以一直停在产生它的 thread 旁边，随时接受 review 和修复。
浏览器也是类似的工作面。Codex 可以打开渲染后的页面，检查它，响应用户在页面上的标注，并继续修复同一个对象。网页既是输出结果，也是控制表面。
这些表面尤其适合放在侧边栏里：
index.html这种轻量静态 artifact- Storybook
- Remotion Studio
- 浏览器幻灯片
- 数据分析应用
一个单独的 index.html 文件就可以成为长期存在的交互 artifact，不一定需要服务器。Thread automations 也可以定期刷新静态 artifact，让用户回来时看到新的结果。
共享记忆
长线程很有用，但重要上下文不应该只存在于对话记录里。
Shared memory 指的是把持久上下文存放在线程之外，让未来的工作可以从明确、可审阅的地方继续。
一种稳定做法是把持久线程锚定在 Obsidian vault 里。实际形态可以很简单：一组普通文件，方便检查、编辑、移动和长期保存。团队可以把它放在 cloud storage、Git、Dropbox、Google Drive 或其他同步层里。
一个 vault 可能长这样：
|
|
顶层的 AGENTS.md 可以说明 Codex 应该如何维护这个工作空间：什么信息要写下来，写到哪里，什么时候不要制造噪音。
一个实用的 AGENTS.md 可以这样写：
|
|
不要照抄某个 vault 结构。更重要的是教会 agent：长期上下文应该放在哪里，哪些信息值得保留，什么时候不应该反复改动文件。
仓库存放代码。Vault 存放滚动上下文：相关人员、发生了什么、哪里卡住、谁负责、下一步是什么，以及那些如果不写下来就会在会话之间消失的细节。
Codex 也有第一方记忆能力，可以在 Settings > Personalization > Memories 中配置。它适合记录偏好、重复工作流和常见坑点，但它更适合作为显式 written context 的补充，而不是替代品。Chronicle 也在同一个方向上推进：从最近的屏幕上下文中帮助 Codex 建立记忆。
从代码向外扩展
Codex 仍然从代码开始。但代码周围的更多工作，现在也能被同一个系统触达：MCP servers、浏览器界面、桌面控制、thread automations 和可审阅 artifact。
这改变了使用 Codex 的控制方式。Steering 用来打断正在进行的工作。Queuing 用来排下一步。Thread automations 让线程在用户离开后继续活动。Goals 给长期任务加上明确终点和验证信号。
当这些能力连起来时，Codex 就能把一个工作流从指令推进到执行，再推进到 artifact review。即使任务已经离开代码仓库，它仍然可以留在同一个系统里完成。