Codex官方文章：如何把Codex用到极致

这是一篇来自 Codex 团队的分享，我是把全文翻译过来并且针对我个人用 Codex 的一些使用经验做了一篇总结，希望对大家有帮助。

原文：Jason Liu（@jxnlco）《Getting the most out of Codex》，2026-05-20 发布于 X（长文形式）。推文链接：https://x.com/jxnlco/status/2057153744630890620

大多数开发者第一次用编程 agent 都是为了写代码：检查一个仓库、生成一份 diff、跑测试、开一个 pull request。

这至今仍是 Codex 的重心。但电脑上的很多工作本来就以代码为中介：执行 shell 命令、浏览网页、调用 API、导出文档、响应事件、触发自动化。当这些界面逐一向 Codex 开放，它给人的感觉就不再是狭义上的编程助手，而更像一套用来完成电脑上各种工作的系统。

Codex 应用把这个转变落到了实处。一个线程（thread）能保留上下文、使用工具、呈现产物（artifacts），并跨多轮 prompt 持续下去，而不是每次交互结束后就重置。

想从 Codex 身上得到更多，就要把这些能力组合起来用：

持久线程（durable threads），保留上下文语音、操控（steering）、排队（queuing），让用户始终留在回路里浏览器、computer-use、MCP server 和 connector，让 Codex 在仓库之外也能动作线程自动化（thread automations）和目标（Goals），在用户离开时继续推进工作侧边栏（side panel），用户在那里审阅代码、文档、幻灯片和其他产物

持久线程

置顶线程（pinned threads）是把持久线程放在手边的一种方式。它适合反复出现的工作流，比如：

一个参谋长（Chief of Staff）线程（相当于是 Thread 的大脑）一个发布线程一个文档评审线程一个专门做外部监控的线程

这些是持久的工作区，不是简短的聊天。Codex 可以随时间反复回到这些线程里，保留此前的决定、偏好和工作上下文——否则这些东西就得从头重建。

置顶线程的快捷键让这件事变得实用。Command-1 到 Command-9 能直接跳进已保存的线程。

语音输入

语音输入的价值在于，它能在一个想法被压缩成打磨过的文字之前，捕捉到它粗糙的版本。

Codex 内置了语音输入。对于那些说出来很自然、打字却很别扭的模糊起点，它尤其好用：

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

在任务还没完全成形时，花两三分钟把想法一股脑倒出来，它也很合适。

转录文本同理。一份原始的会议转录，或者口述的计划笔记，往往比一段简短的摘要提供更好的素材，因为它保留了不确定、强调，以及没说完的思路。

操控与排队

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

当 agent 走错了方向、需要在它做完之前纠正时，操控就有用。比如在评审一个网站时，用户可以一边在侧边栏标注界面，一边打断它的工作：

把这个改小一点这两个元素之间的间距感觉不对这句文案是错的

排队不一样。它不打断进行中的任务，而是把下一个任务排进队列。用户可能会说：

操控改变 Codex 此刻正在做的事，排队改变接下来该发生的事。两者都让用户在工作展开的过程中始终贴近它。

工具与触达范围

一旦一个线程具备了连续性，下一个问题就是：它能作用于什么。Codex 可以一层层地向外延伸：

$browser，对应侧边栏里的应用内浏览器，Codex 在那里可以检查和标注网页界面

@chrome，对应已登录的浏览器状态，以及基于 Chrome 的工作流

@computer，对应那些只存在于桌面图形界面（GUI）中的工作

$browser 适合在侧边栏里做浏览器评审。@chrome 适合那些依赖用户 Chrome 上下文、需要登录态的浏览器工作。@computer 适合那些只能通过桌面 GUI 完成的任务。

MCP server 和 connector 把同样的思路延伸到工作流的其余部分。

Slack、Gmail 和 Calendar 之所以重要，是因为很多重要的任务一开始是以消息、收件箱条目或排期问题的形式出现的，之后才变成代码。

Skills 让重复的工作流可以复用。一个工作流一旦被证明有用，就把它打包成一个 skill，这样 Codex 下次能再跑一遍，而不用从零重新学习这套流程。

随处都能工作

Codex 移动版改变了「用户必须坐在工位前」这件事。一个任务可以在 Mac 上启动——文件、权限和本地配置都已经在那里——然后在用户用手机查看时继续推进。

这在一些细小的时刻很重要。一个人可以在 Codex 跑一个较长的任务时离开工位，在外面回答一个问题、批准下一个步骤，或者在回到座位之前给线程换个方向。本地环境留在原处，而用户不必。

Automation

自动化按计划执行 Codex 的工作。如果一个重复性任务应该每次从一个工作区全新开始——比如一份日报，或者一次定期的仓库检查——就用定时自动化（scheduled automation）。如果这个计划应该回到一个带着运行上下文的活跃对话里，就用线程自动化（thread automation）。

置顶线程很有用，但它们仍然在等用户回来。线程自动化可以每隔几分钟或几小时检查一次某件事，持续下去直到满足某个条件，并随时间调整节奏。

一个参谋长线程可能每 30 分钟跑一次：

当用户回来时，收集上下文这个最昂贵的部分往往已经做完了。发出什么，仍然由人来决定。

线程自动化也适合反馈循环。一个线程自动化可以盯着 pull request 的评论、Google Docs 的评论或 Slack 的回复，在用户离开时让周边的工作继续往前。

设想一个动画制作的工作流：评审的人在 Slack 里分享了一段视频。一个线程自动化可以按计划检查这个会话，在评论到来时渲染出一个更新的版本，并在同一个会话里 @ 那位评审者回复。如果某个集成无法完成最后的上传，桌面自动化可以通过 GUI 把这一步做完。

这个循环横跨三处：用 Slack 收反馈、用代码库做渲染、用桌面自动化完成最后的上传。

/goal

当一个任务有一条真实的终点线、agent 能持续朝它推进时，目标（Goals）最为强大。一个弱的目标是这样的：

一个更强的目标有一条可度量的成功标准。

举个例子，一个工程师可能要把一个内部工具从 Python 迁移到 Rust：建好新目录，定义好目标，并把终点线写明确——新实现在单元测试通过之前都不算完成。

一个目标把持续的执行和一个验证器（verifier）结合在一起。用户定义结果、停止条件，以及那个能说明 Codex 是否在靠近终点的信号。

有用的验证器包括：

一个测试套件一个 benchmark一次 bug 复现一个验证矩阵一个必须一直保持通过的端到端工作流

有野心很重要，但没有验证，它就只是一个愿望。

侧边栏

侧边栏把工作成果留在产生它的那个对话旁边。用户不必导出一个产物再切换上下文，而是可以就地审阅它。产出可能是代码，但也可能是一份幻灯片、一个 PDF、一个浏览器页面、一张表格，或者过程中产生的其他产物。

它尤其擅长四件事：

检查产物标注哪里需要改操作网页界面评审改动

侧边栏让用户可以就地审阅 Markdown、电子表格、数据表、文档和幻灯片。他们可以检查、标注、修改这些产物，而不打断整个回路。

那份幻灯片或 PDF 可以一直开在产生它的线程旁边，随时可以直接审阅和修补。

应用内浏览器让 Codex 可以检查一个渲染好的页面、控制它，并直接在被审阅的界面上响应标注。对一个页面或产物的评论留在工作回路内部，而不是变成一次单独的交接。

网页同时成为输出和控制界面。Codex 可以构建一个产物，在侧边栏里打开它，检查它、调试它，并就地不断打磨同一个对象。

下面这些载体尤其合适：

index.html，用于轻量的静态产物Storybook，用于 UI 评审Remotion Studio，用于程序化的动画基于浏览器的幻灯片，用于演示数据应用（data apps），用于分析类工作流

单单一个 index.html 文件，不需要服务器，就能成为一个持久的、可交互的产物。线程自动化还可以随时间刷新这些静态产物，这样当用户回来时，线程里已经有新的东西在等着。

共享记忆

当长期运行的线程能共享一份位于任何单个对话之外的记忆时，它们会变得更有用。

一个经得起时间的做法，是把持久线程锚定在一个 Obsidian vault 里。实际操作上，这意味着一个由纯文本文件组成的文件夹，它始终便于检查、编辑、移动，也便于长期保存。团队可以把这个文件夹放进云存储、Git、Dropbox、Google Drive，或者其他适合自己工作流的同步层。

一个 vault 大致可能长这样：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

在顶层，AGENTS.md 可以定义：当 Codex 对人、项目、决定和未了结的事情了解得更多时，它应该如何更新这个工作区。

不要照搬某一个确切的 vault 结构。要教会 agent：持久上下文应该住在哪里、应该保留哪些上下文，以及什么时候不要制造无谓的变动。

一份实用的 AGENTS.md 可能会写：

把 ~/vault 当作持久的工作记忆。宁可要规范的笔记，也不要笔记到处蔓延。明确地把 TODO、人、项目、每日小结和草稿笔记各自归位。保留决定、阻塞项、负责人、日期和有用的链接。如果没有发生有意义的变化，就不要去搅动这个 vault。

代码仓库装的是代码。vault 装的是滚动的上下文：涉及的人、变了什么、卡在哪里、需要跟进什么，以及那些否则会在一次次会话之间消失的东西。

重要的上下文不该只活在一份对话记录里。把它写在某个下一个线程能接着读下去的地方。

Codex 自己也有第一方的记忆功能，在 Settings > Personalization > Memories 里。它们为偏好、重复出现的工作流和已知的坑提供了一个本地的回忆层。它们是对显式写下来的上下文的补充，而不是替代。Chronicle 朝同一个方向使力——它帮助 Codex 从最近的屏幕上下文中构建记忆。

从代码向外

Codex 仍然从代码出发。但代码周围的更多工作，现在可以通过同一套系统触达：MCP server、浏览器界面、桌面控制、线程自动化，以及可审阅的产物。

这改变了控制模型。操控打断进行中的工作。排队把下一个任务排好队。线程自动化在用户走开时让一个线程保持活跃。目标则加上一条具体的终点线，让 Codex 能持续朝它工作。

现在，Codex 能把一个工作流从指令、到执行、再到产物评审完整地承载下来——哪怕这项工作已经离开了代码仓库。

我的想法

这篇介绍的很多功能我觉得非常实用。

老模型是一个 prompt 换一个 diff，agent 是你调用的一个函数。新模型是一个持久线程，你像带一个同事那样带它。steering 是当面打断，queuing 是交代下一件事，automation 是它自己按点干活，goal 是给它一份验收标准。文章列的那一长串，本质是一套管理下属的原语。

而且一个非常具有可品味性的在于 /goal 那一节，goal 没有验证，你的蓝图只是个愿望。这句不只对 Codex 成立。

Agent 落地的真问题不在能力，能力早就够了，缺的是一个能回答它有没有做对的东西。Python 迁 Rust 那个例子好就好在终点线可执行——单测通过，而不是感觉差不多。我自己的基本和文章的一致：给不出验证的任务，agent 的产出基本不能直接用。

但最承重的一节是共享记忆，它却被排在很靠后的位置。前面那一串能力，底色都是让一个线程能长期接着干；可只要上下文还只活在对话记录里，所谓长期就是假的——线程一长照样丢。

真正让线程持久的是那个 vault：一个纯文本文件夹，加一个 AGENTS.md 教 agent 怎么维护它。注意 AGENTS.md 里那条没有实质变化就别搅动 vault。

最后一点：vault 这个模式不是 OpenAI 独有的。Claude Code 有 CLAUDE.md，各家 agent 各自摸索，最后都收敛到同一件事——agent 的记忆就是仓库里的纯文本文件，能看，能改，有 version control 。agent 要变成能长期托付的东西，靠的不是模型多强，是它有没有一块外部记忆。

功能 OpenAI 会一直加，但那块持久的、纯文本的、你自己也在维护的记忆，得你自己搭了来维护。