Codex 不断更新：8个特性把它用到极致

勇哥AI笔记

发布于 2026-05-26 14:58:07

文章被收录于专栏：技术人生黄勇技术人生黄勇

我日常主力开发就是Codex + WorkBuddy，最近发现它们更新了不少功能。

比如 WorkBuddy 任务列表里能显示执行时发起的子Agent执行内容：

Codex 不再显示上下文窗口的百分比，应该是改进了上下文压缩的功能，以前老是在自动压缩时任务卡死。

官方也发布了一条推特，讲述如何用好 Codex 的8个特性——长线程、语音输入、操控任务、工具、移动端、Goal 目标、自动化执行与共享记忆：

大多数开发者最开始用编程 Agent，就是用来看代码：检查仓库、生成 diff、跑测试、提 PR。

这仍然是 Codex 的核心功能。不过，电脑上的大量工作，其实就是通过代码来实现：

执行 Shell 命令、浏览网页、调用 API、导出文档、响应事件以及触发自动化操作等。

当这些功能都可以在 Codex 中完成之后，它给人的感觉就不仅仅是编程助手，而更像是一个帮你完成计算机工作的助手。

Codex 将这一转变成为现实。

一个 Thread 可以保持上下文、使用工具、展示产出物，并且可以跨多轮对话持续工作，而不是每次交换之后就重置。

要想充分利用 Codex 的各类功能，就必须将这些功能要组合起来用使用：

• 长线程/机制，保留上下文不丢失。
• 在任务处理流程中的时候，系统会处理语音输入、方向控制以及任务排队等相关操作。
• 浏览器、Computer-Use、MCP 服务器和连接器，以及那些能让 Codex 在存储库之外正常运行的连接组件。
• Thread 自动化与 Goals，用户离开仍然继续执行任务和目标。（Goals 命令从测试版变为了正式支持）
• 侧边面板，用户可以在里面审查代码、文档、演示文稿和其他相关内容。

侧边默认显示一些项目相关信息，如有文件更新，在此处显示变更。

持久线程

持久化线程：长期运行的 Codex 对话，在多次会话中保持工作状态的连续性。

固定线程是一种让重要信息始终易于查看的方法。对于那些需要定期处理的任务来说非常有用，比如：

• 助理线程（帮你在开发工作中做一些执行助理类的任务）
• 发版线程
• 文档审查线程
• 外部监控线程

这些是持久的工作空间。

Codex 可以在时间推移中不断回到这些线程，保留此前的决策、偏好和工作上下文，这些信息如果丢失了，就得从头再构建。

固定线程的快捷键让这一切变得实用。Command-1 到 Command-9 直接跳到已保存的线程。

语音输入

语音输入的价值在于，能快速记录你突然冒出来的想法，在它打磨成文字之前，尽管可能还是雏形。

Codex 内置了语音输入。

它特别适合那些说起来很自然、打出来却不够准确的模糊起点：

• 我记得 Slack 上好像有个叫 Ben 的人提过这事
• 我不记得细节了
• 你去找找看

对于一个能搜索、收集上下文、然后汇报回来的 Agent 来说，这通常就够了。

（我在用 OpenClaw 的时候，因为支持语音输入时，就经常记录一些时不时产生想法。在使用 Codex 就没有这个习惯。）

语音输入也很适合在想法还没完全成形之前，做一个两三分钟的思绪记录。

转录文本同理。

一段原始会议记录或口述的计划笔记，往往比一份简短摘要能提供更好的源材料，因为它保留了不确定性、重点和未完成的思路。

操控与排队

当语音和对一个进行中任务的明确控制配合起来，它显得更好用。

操控/转向（Steering）：在 Codex 当前步骤完成之前，用新的指示操控正在执行的任务。

操控在 Agent 正跑偏、需要在它跑完之前纠正时非常有用。比如在审查网站时，用户可以打断正在标注侧边面板的工作：

• 把这个缩小一点
• 这两个元素之间的间距不太对
• 这段文案是错的

排队（Queuing）：在当前步骤完成后，为 Codex 添加要执行的下一个任务。

排队与操控不一样。它不会打断正在进行的任务，而是把下一个任务排到队列里。

用户可能会说：

• 工作完成后，把预览链接发给审阅者，发到 Slack 上

操控改变的是 Codex 正在做的事。

排队改变的是下一步做什么。

两项功能都可以让用户在整个任务执行过程中始终能紧密掌控着整个流程。

工具与触达范围

一旦 Thread 有了连续性，下一个问题就是它能作用于什么。 Codex 可以逐层向外扩展：

• $browser：侧边面板中的应用内浏览器，Codex 可以在此检查并标注网页
• @chrome：已登录的浏览器状态和基于 Chrome 的工作流
• @computer：只能通过桌面 GUI 完成的工作

$browser 适用于侧面板浏览器审查。 @chrome 适用于依赖用户 Chrome 上下文的已登录浏览器工作。 @computer 适用于只能通过桌面 GUI 存在的任务。

MCP 服务器和连接器将同样的思路延伸到工作流的其余部分

Slack、Gmail 和 Calendar 之所以重要，是因为许多重要任务在变成代码之前，最初都表现为消息、收件箱事项或日程安排问题。

Skills 让重复的工作流变得可复用。

一旦某个工作流被证明有效，把它打包成 Skill，Codex 下次就可以直接运行，无需从头重新学习这套流程。

随时随地工作

Codex 移动端应用改变了用户必须在电脑前的限制。

一个任务可以在 Mac 上启动，文件、权限和本地环境都在那里，然后用户用手机就能继续跟进。

这些细节在关键时刻非常重要。

当 Codex 在跑一个较长的任务时，人可以离开桌子，在外面回答一个问题、批准下一步、或者在回来之前重新引导线程。

本地环境保持不变，用户不需要守着。

自动化

自动化让 Codex 按计划执行工作。

当重复性任务应该从工作区全新启动时，使用计划自动化，比如日报或定期仓库检查。

当计划应该回到一个活跃对话及其运行中的上下文时，使用 线程自动化。

线程自动化：心跳式的周期性唤醒调用，按计划回到同一个 Codex Thread。

固定的线程很有用，但它们仍然在需要用户亲自回来处理。

线程自动化可以每隔几分钟或每隔几小时检查某件事，持续执行直到满足某个条件，并随时间调整节奏。

一个助理线程可以每 30 分钟运行一次：

• 每 30 分钟检查 Slack 和 Gmail，找出需要我关注的未回复消息
• 帮我排列最重要的优先级
• 如果有人问我问题，尽可能深入研究并起草回复给我，但不要发送

当用户回来时，收集上下文的费时部分通常已经完成了。

人来决定发什么。

线程自动化也适用于反馈循环。

它可以监控 PR 评论、Google Docs 评论或 Slack 回复，在用户离开期间让周边工作持续推进。

举一个动画工作流的例子：审阅者在 Slack 中分享了一个视频。

线程自动化可以按计划检查该线程，在出现新评论时渲染更新版，并在同一个线程中回复并 @ 审阅者。

如果某个项目集成无法完成最终上传，桌面自动化可以通过 GUI 完成最后一步。

这个循环跨越了三个层面：Slack 用于反馈，代码库用于渲染，桌面自动化用于最终上传。

Goals

Goals：长期运行的 Codex 任务，有明确的终点线，Agent 可以持续朝它推进。

当任务有一个真正的终点线、Agent 能持续朝它推进时，Goals 才最强大。一个不明确的目标例子是：

• 实现这个 Markdown 文件中的计划

更好的目标要有可衡量的成功标准。

例如，一个工程师可能会把内部工具从 Python 迁移到 Rust：

建立新目录，定义目标，把终点线明确化：新实现必须通过单元测试才算完成。

Goal 将持续执行与验证器结合在一起。

用户定义结果、停止条件、以及判断 Codex 是否在接近目标的信号。

有用的验证器包括：

• 测试套件
• 基准测试
• Bug 复现
• 验证矩阵
• 必须持续通过的端到端工作流

抱负固然很重要，但没有验证，它只是一个愿望。

写这篇文章/goal 命令让大模型持续工作直到目标实现时，“/goal” 还是测试版。

侧边面板

侧边面板把工作成果留在了产生它的对话旁边。

用户不必导出产出物再切换上下文，可以在原地审查它。

产出物可能是代码，但也可能是幻灯片、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 视为持久工作记忆
• 偏好规范笔记而非笔记膨胀
• 显式路由 TODO、人物、项目、每日摘要和临时笔记
• 保留决策、阻塞项、负责人、日期和有用的链接
• 如果没有什么有意义的变化，不要扰动知识库

代码仓库存储代码。

知识库存滚动上下文：涉及的人物、变化了什么、什么被阻塞了、什么需要跟进、以及那些在两次会话之间本来会消失的信息。

重要的上下文不应该只存在于对话记录里。

把它写下来，放在下一个线程能找到的地方。

Codex 还有第一方记忆功能，在「设置 > 个性化 > 记忆」中。

它提供了一个本地回忆层，用于偏好、重复工作流和已知陷阱。

它们是对显式书面上下文的补充，而不是替代。

Chronicle 则朝同一个方向推进，帮助 Codex 从最近的屏幕上下文中构建记忆。

（Chronicle 会利用屏幕上的上下文信息来增强 Codex 的记忆。

当你向 Codex 发出指令时，这些记忆可以帮助它理解你一直在做什么，从而减少你重复说明上下文的需要。）

从代码向外延伸

Codex 仍然从代码出发。

但越来越多围绕代码的工作，现在可以通过同一个系统触达：MCP 服务器、浏览器界面、桌面控制、线程自动化和可审查的产出物。

这改变了控制模型。

操控打断正在进行的任务。

排队排列下一个任务。

线程自动化让 Thread 在用户走开时保持活跃。 Goals 添加了一个具体的终点线，Codex 可以持续朝它推进。

Codex 现在可以从指令携带工作流走到执行，再到产出物审查，即使工作离开了代码仓库也一样。

原文：Getting the most out of Codex

https://x.com/jxnlco/status/2057153744630890620