大多数开发者最初使用编程智能体时，场景无外乎代码生成：检查仓库、改动文件、跑测试、开 Pull Request。这是 Codex 最初的重心，也是它最被熟知的形态。但计算机上的大量工作早已由代码介导——执行 Shell 命令、浏览网页、调用 API、导出文档、响应事件、触发自动化。当这些都成为 Codex 可调用的能力时，它越来越不像一个狭义的代码助手，而更像一个完成"电脑工作"的操作系统。

这个转变在 Codex App 上得到了具体体现。线程可以保持上下文、使用工具、展示产物、跨提示继续而非每次交换后重置。这意味着 Codex 不再是"问完即走"的工具，而是有记忆的长期工作空间。

深度用好 Codex 需要将多个能力组合使用。

Durable Threads（持久化线程） 是第一个关键能力。长时运行的 Codex 线程在多次会话中保持工作上下文。被固定的线程适合反复出现的工作流：首席运营助手线程、发布检查线程、文档审查线程、监控线程。这些是持久工作区而非短对话，Codex 可以随时间回溯它们，保留之前的决策、偏好和工作上下文，否则这些必须从头重建。Command+1 到 Command+9 的快捷键让固定线程的切换变得实际。

Voice Input（语音输入） 的价值在于它捕捉想法的粗糙版本——在想法被压缩为精确文字之前。语音输入特别适合含糊的开头：自然说出来容易，但打字却很尴尬的场景，比如"我在 Slack 上听一个叫 Ben 的人提过这件事，细节不记得了，请去查一下"。转录文本也同样有效——原始会议记录或口述计划笔记通常比简短摘要提供更好的素材，因为它保留了不确定性、强调和未完成的思考线索。

Steering 和 Queuing让语音与显式控制结合。Steering 是打断正在运行的任务，在当前步骤完成之前注入新方向；Queuing 是在当前任务之后排队下一个任务。两者都让用户在工作进行中保持近距离监控。

工具扩展是其第三个维度。Codex 可以逐层向外扩展：$browser 用于侧边栏应用内浏览器，Codex 可以检查和标注网页；@chrome 用于需要登录状态的工作；@computer 用于只有通过桌面 GUI 才能完成的工作。MCP 服务器和连接器进一步扩展到 Slack、Gmail、Calendar 等工作流——因为很多重要任务首先以消息、收件箱或日程问题的形态出现，远早于它们变成代码。

Automations让 Codex 可以在 schedule 上自动运行工作。线程自动化（Thread automation）是心跳式的周期性唤醒，返回同一线程继续工作。比如一个首席运营助手线程可以每 30 分钟检查 Slack 和 Gmail 中的未回复消息，帮忙优先排序，准备回复草稿——用户回来时，最费时的上下文收集已经完成。

Goals适合有明确终点线的长期任务，它定义成功标准，Codex 可以持续向这个目标推进。一个实用的 verifier 可以是测试套件、基准测试、Bug 复现、验证矩阵或必须持续通过的工作流。"雄心很重要，但没有验证的雄心只是愿望。"

Shared Memory让长时线程在单一对话之外共享记忆。将持久化线程锚定在 Obsidian 库中是实践方式——~/vault 作为持久工作内存，AGENTS.md 定义 Codex 应如何更新它学到的东西：把人、项目、决策、开放循环和日期链接存储下来。"重要的上下文不应该只存在于对话记录里，把它写下来，让下一个线程可以接上。"

从代码出发，向外延伸到 MCP 服务器、浏览器界面、桌面控制、线程自动化和可审查的产物——Codex 的控制模型因此改变：Steering 打断进行中的工作，Queuing 排列下一个任务，线程自动化在用户离开时保持线程活跃，Goals 添加 Codex 可以持续推进的具体终点线。Codex 现在可以把工作流从指令带到执行再到产物审查，即使工作离开了代码仓库。

参考来源：X @jason（https://x.com/jxnlco/status/2057153744630890620）