工作流 | Feisky

烧了 20 亿 token 总结的 Codex 使用指南

Pengfei Ni — Wed, 03 Jun 2026 20:00:00 +0800

Codex 桌面版最近口碑爆了。我自己已经把很多工作都切到了 Codex 客户端的 Goal + GPT-5.5 上，一不小心就用了 20 多亿 token。

不过很多人第一次用 Codex，还是把它当一个更强的 coding agent，用来读仓库、改代码、跑测试、写 PR。这当然没错，Codex 的基本功能确实还是代码编程。但它的桌面客户端已经不只是编程工具了。Skills、Computer Use、浏览器操控、Gmail 和 Calendar 等等各种连接器和插件一路加上来，早就成了一个通用 Agent 客户端。甚至你还可以通过 ~/.codex/config.toml 配置文件给它接入 DeepSeek、Kimi 等第三方模型。

我让 Codex 扫了一下最近这个月的会话历史，总结了一些日常的使用方法，再加上自己的补充，整理成这篇分享给大家。如果你还不熟悉 Codex 桌面客户端的使用方法，可以参考 Jason Liu 最近写的 Getting the most out of Codex 文章（链接见文章最后），今天的文章假设你已经了解了 Codex 的基本用法。

1. 先给足上下文，再开始任务

AI Agent 最大的问题不是不会干活，而是太容易基于幻觉自信乱干。你不告诉它项目背景和规则，它就按自己的理解来，很容易过度自信，走向错误的方向。

要解决也很简单，写一个 AGENTS.md 放在项目根目录。Codex 每次打开项目会自动读这个文件，里面可以写项目背景、技术栈、代码规范、常见坑、测试方式，相当于给它一份新人上岗须知。如果任务涉及特定模块，还可以在 prompt 里直接指定“先读 docs/xxx.md 再动手”，让它从文档而不是从猜测开始。

Codex 桌面端有个置顶会话挺好用的，你可以把最常使用的会话固定在前面。不要把 Codex 的会话当成临时会话，而是一个持续的工作现场。Codex 已经能够自动帮你压缩会话上下文，再加上它的记忆功能，长时任务不需要新开会话，可以持续在同一个会话里持续下去。

这也是我觉得 Codex 最好用的一点，避免了很多上下文交接的问题，可以真正帮你干大活了。

2. 验证比生成重要得多

说实话，让 Codex 写代码，随便一个 coding agent 都能做个七八成。真正拉开差距的是验证，要拿真实的验证结果说话。

验证可以是很多东西：测试套件、benchmark、Web 界面截图、发布前 checklist 等等，也就是之前你自己手动做的所有操作应该都描述清楚，交给 Codex 让它去负责。

特别是在用 Goal 跑长任务的时候，这点更是必不可少。比如，“帮我把这个计划实现完” 看起来有目标，但其实病没有明确的停止条件。而好的 Goal 应该带上清晰的验证器：“完成后必须通过 xx 测试、浏览器检查和人工可审阅的变更摘要。如果验证失败，先修验证失败的问题，不要直接宣布完成。”

没有验证的 Goal，其实只是愿望。

3. 批量操作前加一道审查门

从我自己的使用历史来看，审查和清理类任务最容易翻车。Codex 默认倾向是搜到了就改，找到了就删。这时候，你需要主动在提示词里面拦一下。

具体做法是在 prompt 或 AGENTS.md 里加上审查规则。比如“批量修改前先列出所有命中并按类型分组（需要改 / 可能需要改 / 不该动），等我确认再执行”。清理旧分支也一样：“先输出 merged 和 unmerged 分支对比，标注哪些旧实现已被 main 覆盖，不要直接删”。

举个例子，代码库里搜到一堆旧 token 引用，不是所有命中都该删。有些是测试隔离需要的，有些是运行时继承的，真正有问题的可能只有几个。如果不加审查这道程序，Codex 可能会机械地全部清掉，然后测试挂一片（针对这个例子，加上上一步说的验证其实可以自动修复回来，但会浪费很多时间+token）。

这种不是高大上的 AI 能力，但特别体现人的判断，需要你把经常看到的坑告诉 AI，让它去主动规避。

4. 先配工具，再谈智能

模型当然重要，但真正决定 AI 能干什么的，是配置的工具、权限、上下文和验证方式。插件决定 Codex 能碰到哪些外部世界，Skills 决定它碰到这些世界时该怎么做。我自己常用的插件和 Skills 列在了文末附录里，这里只说一个最容易被忽略的点。

大多数人写 Skill，会把它当成说明文档：告诉 Codex 该做什么、按什么顺序做。这当然有用，但 Skill 真正值钱的部分不是流程，而是 Gotchas，也就是每次 Codex 犯错之后补进去的“别踩这个坑”。

比如：

这个数据源经常不可用，不要猜。
这个任务结束前必须跑某个验证。
这个工具第一次会失败，失败后应该换另一种方式。
这个类型的 review 不能机械接受，要逐条验证。
这个工作流适合先搜宽一点，再只打开高价值候选。

一开始写个十几行骨架就够了，用一段时间后它自然会长成一个成熟 Skill。好用的 Skill 不可能一次写好的，都是拿实际经验养出来的。

5. 用 Side Panel 边看边改

以前用 AI 做文档、网页、PPT，最烦的是上下文切来切去。AI 在聊天框里生成，产物在另一个窗口打开，发现问题又要截图回来描述。来回几次，人和 AI 都开始丢上下文。

Codex 的 Side Panel 可以把产物留在工作流里直接改。具体做法是：让 Codex 生成一个 index.html 或者打开一个 localhost 页面，它会在侧边栏渲染出来。你一边看渲染结果，一边在同一个线程里说“这个按钮太大了”“表格第三列数据不对”，不用截图，不用切窗口。

有两类任务特别适合这个场景。一类是前端和网页，直接在旁边检查样式、交互和移动端适配。另一类是文档型产物，报告、表格、PPT、数据分析页面放在旁边边看边改，比导出再反馈高效得多。

6. 重要上下文写到文件里

会话会压缩，模型可能会切换，对话里的重要决策和验证方式如果不主动写到外部文件里，就很容易会被丢掉。

我自己在做长任务的时候（特别是那种跨天的任务），会特意让 Codex 总结记录下 summary、checkpoint、handoff 文档和下次接手的入口说明。下一个会话或者新任务可以接着这些文件继续，不用从零开始。

要实现也很容易，不需要搞复杂的记忆系统。一个 TODO.md 写待办事项，再加几个文件夹分类放踩坑记录和项目状态，就够了。关键是可检查、可编辑、可删除。Codex 内置的 Memory 和 Chronicle 可以当快速回忆层用，但替代不了外部文件。只有写进文件里的记忆，才有机会变成系统。

7. 随时在线，随处接管

长任务跑着的时候，你不需要一直坐在电脑前。在 ChatGPT 手机端连上你的 Mac 或远程机器，可以随时给远端的 Codex 下任务，或者回复 Codex 需要你介入的问题。

一般来说，当你把任务定义清楚之后，就可以通过 Goal 来启动长时任务，然后等着 Codex 的通知就可以了。你可以在手机上随时能看到它的输出、审批命令、中途纠偏。不用坐在电脑面前盯着，同时关键决策又可以随时介入。

如果你有 Linux 服务器，Remote SSH 更值得配一下。Codex 会自动读取本地 SSH config 里的主机列表，连上之后直接在远程服务器里跑任务。日常运维、配置管理、代码部署，SSH 连上就能让 Codex 干活，电脑端/手机端都可以随时跟进。配合前面说的 AGENTS.md 和文件记忆，远程接入的时候上下文还在，不用重新交代背景。

8. 定时自动化：让会话自己醒过来

前面说的远程接入是“你主动去给 AI 下发任务”，而定时自动化是“让 AI 主动来找你”。

具体做法是给置顶线程设一个 Thread Automation。跟普通定时任务不同，Thread Automation 每次触发会回到同一个线程，带着上次的上下文继续工作。它知道上次检查到了哪里，哪些事项已经处理过，哪些数据源接不上。

我自己用得比较多的是两类。一类是信息聚合：每天早上自动检查未读邮件和 IM 消息，按优先级整理好，等我打开的时候直接看结论。另一类是监控类：定期检查 PR 列表、问题反馈或者关注列表，有新内容就整理摘要，没有就不打扰。

这儿有一点需要注意的是不要让自动化假装全知。没有就是没有，不要编造虚假信息；依赖不可用就直接报不可用，不要自作聪明。

9. 不只是代码：邮件、调研、文档也能跑

文章到这里，其实大部分的场景还都是跟代码相关的。但 Codex 桌面客户端接上 Gmail、Browser、Documents 这些插件之后，很多非代码任务也都能跑的不错。

我自己用得比较多的几个场景：让 Codex 过一遍项目和相关邮件，做图文并茂的汇报 PPT；给一个调研主题，让它用 deep-research 搜多个来源，整理成带出处的摘要；会议前把相关文档和之前的讨论丢给它，让它准备一份简要；写完公众号文章后让它排版成微信公众号格式并生成封面图。

这些任务的共同点是：以前要在好几个工具之间切来切去，现在可以在一个会话里串起来，省掉了大量的不同工具和上下文切换。

10. 别追求全自动，要把主动权留在人的手里

Codex 好用，也可以自动化很多任务，但并不意味着你就要完全放手让它全自动去自己玩。

恰恰相反，你越把它接进真实工作流，越会看到很多边缘问题：权限、登录态、数据源缺口、工具失败、上下文压缩、验证不充分、自动化误触发等等。

所以更合理的用法是：让 Codex 做上下文收集、执行、验证和初步整理，人保留判断、授权和最终责任。Codex 的 Steering（中途纠偏）和 Queuing（排队追加下一步）就是为这个设计的。真实的工作往往都是边看边改、边发现边调整，不是“人给一个完美需求，让 AI 一次性完成”。

也就是说，人不应该退到系统外面，而是站在系统里面，负责纠偏、验收和更新规则。

Codex 的语音输入也是一个让人留在 loop 里很好的设计。它不是让你口述代码的，而是在想法还没成型的时候随时输入给 Codex，或者在 Codex 走偏的时候随时修正它。语音输入不需要很完整，有错别字啥的都没关系，模糊指令对一个已经掌握足够上下文的 AI 来说已经足够让它理解你的意图。

附录：我常用的插件和 Skills

以下是文中第 4 条提到的工具清单，供参考。

常用插件：

Browser：本地网页、localhost、侧边栏里的页面检查和截图。
Chrome：需要登录态、真实 Chrome profile、远程网页操作时用。
Computer Use：只能通过桌面 GUI 完成的工作。
Gmail：搜索邮件、读取正文、筛选待办、草拟回复。
Documents / Presentations / Spreadsheets：文档、PPT、表格类 artifact。
Product Design：早期产品想法、原型、截图到交互稿。
Build Web Apps：前端应用、组件、浏览器验证。
HyperFrames / Remotion：视频、动画、程序化内容。
Superpowers：计划、TDD、系统化调试、验证、代码 review、开发分支收尾。
Codex Security：安全扫描、威胁建模、finding 修复。

常用 Skills：

brainstorming（Superpowers 插件自带）：头脑风暴和 SPEC 设计。
handoff：将当前对话整理成交接文档（用于新开会话接手）。
deep-research：多源搜索调研。
claude-skill：调用 Claude Code 写文档、做设计或者跟 Codex PK。
twitter-cli / xfetch：读取和搜索 X/Twitter 内容。
xiaohongshu-cli：搜小红书内容。
youtube-transcribe-skill：解析下载 Youtube 视频字幕。

Claude Code 动态工作流：让 AI 自己写 Harness，这事靠谱吗

Pengfei Ni — Wed, 03 Jun 2026 10:00:00 +0800

题记：本文编译自 Anthropic 官方博客《A harness for every task: dynamic workflows in Claude Code》，由 Anthropic 工程师 Thariq Shihipar 和 Sid Bidasaria 撰写。

Claude Code 的默认模式是单 Agent，一个上下文窗口搞定规划和执行。大多数编程任务这就足够好用了。

但是也有很多场景你怎么优化都跑不好。单 Agent 在长时间运行、大规模并行、需要对抗性验证的任务上，有三个已知的退化模式：

第一个是偷懒。让它做一轮安全审查，50 个检查项查到 20 个就宣布完成了。这不是幻觉，是 Agent 在长上下文里的行为退化。第二个是自我偏爱。让它评判自己的产出，它天然倾向于给好评，需要严格验证的场景里这是致命的。第三个是目标漂移。上下文压缩是有损的，每压缩一次，原始需求里的边缘条件、约束细节就丢一点。时间长了之后，Agent 在优化的目标可能已经偏离了你最初给它的任务。

这三个问题不是模型能力问题，是单上下文窗口同时承担规划和执行带来的架构局限。Anthropic 显然也清楚这一点，所以之前陆续搞了 Research、安全审计、Agent Teams、Code Review 这些定制 Harness，每个都是针对特定任务类型写死的调度逻辑。

上周他们把这个能力泛化了：Claude Code 现在可以自己写调度逻辑，针对当前任务实时生成编排脚本，也就是 Dynamic Workflows。

工作原理

动态工作流的核心思路是：用独立的子 Agent 各自占一个干净的上下文窗口，每个子 Agent 只干一件事，由一个确定性的 JavaScript 脚本来调度它们的执行顺序和依赖关系。

动态 vs 静态：区别在哪

之前用 Claude Agent SDK 或者claude -p 来编排多个 Claude Code 实例，本质上是静态工作流。你得提前写好脚本，考虑各种边界情况，写出来的东西往往比较通用。

动态工作流不一样。Claude Code 自己看任务，自己写调度脚本，针对当前这一个具体任务量身定制。Opus 4.8 的能力已经足够让它自己写出高质量的 Harness。

我自己试了一下，感受是：对于那些你本来就知道怎么拆分的任务，静态工作流更可控。但对于"我大概知道要做什么，但不确定最优的拆分方式"的场景，让 Claude Code 自己决定怎么调度确实省事。

六种调度模式

Claude Code 在构建动态工作流时会组合使用几种基本模式：

最基础的是分类路由，一个分类 Agent 判断任务类型，分发给不同的处理 Agent。也可以反过来，在最后加一个分类器决定输出格式。

用得最多的是扇出合并。把任务拆成很多小步，每个小步一个独立 Agent，最后一个合并 Agent 汇总结果。好处是每个子 Agent 有干净的上下文，互不污染。

对抗验证是直接针对自我偏爱问题的解法：每个生成 Agent 配一个独立的验证 Agent，专门挑毛病。生成过滤类似，先大量生成，再按标准筛选去重，只留通过验证的。

然后是锦标赛模式。N 个 Agent 用不同策略做同一件事，两两比较淘汰，留下赢家。最后是循环到完成，不设固定轮次，一直跑到满足停止条件为止。

这些模式可以组合。比如先扇出，每个分支内部做对抗验证，合并时再跑一轮锦标赛选最优方案。

实际能干什么

那这些模式实际能用在哪？原文列了不少场景，我挑几个觉得实用的说。

大规模迁移和重构

Bun 从 Zig 重写成 Rust 就用了工作流。核心思路是：把需要改的地方拆成独立单元（调用点、失败的测试、模块），每个单元派一个子 Agent 在独立的 worktree 里修，另一个 Agent 做对抗性 Review，通过了再合并。

这个场景我觉得价值最大。平时做大规模重构最头疼的就是改着改着上下文丢了，或者改了 A 忘了 B 也要跟着改。每个修改点一个独立 Agent，天然避免了交叉污染。

深度验证

如果你写了一篇技术文章，里面有大量事实性声明，可以用工作流让一个 Agent 先把所有事实性声明提取出来，然后每个声明派一个子 Agent 去核实。还可以再加一层，验证核实 Agent 引用的信息源本身是否可靠。

排序

对定性内容排序（比如按 Bug 严重程度排 1000 条工单），单次 Prompt 的质量会随数量急剧下降。工作流的做法是用锦标赛模式，两两比较。比较判断比绝对评分可靠得多，而且每次比较是一个独立 Agent，确定性的循环逻辑只负责维护对阵表。

规则遵守

有时候明明在 CLAUDE.md 里写了规则，但 Claude Code 跑着跑着就忘了。这时候，就可以用工作流做一个验证层：一条规则一个验证 Agent，每个验证 Agent 用怀疑论者的视角去检查是否违规。

反过来也行：扫最近的 session 日志和 Code Review 评论，找反复出现的纠正，聚类、验证（这条规则真的能防住之前的错误吗？），然后把确认有效的提炼成新的 CLAUDE.md 规则。

根因分析

调试最怕的是认定了一个假设就一路追到底。单 Agent 在一个上下文窗口里特别容易犯这个错误。工作流可以结构性地避免：分别从日志、文件变更、数据状态生成独立假设，每个假设面对一组验证者和反驳者。

这个模式不只适用于代码。销售数据下降、数据管道故障、任何需要事后复盘的场景都能用。

大规模分流

每个团队都有处理不完的支持队列。工作流可以对每条工单做分类、去重（跟已有的 ticket 对比）、尝试自动修复或升级给人。

这里有个有意思的设计模式叫隔离区：读不可信外部内容的 Agent 不允许执行高权限操作，高权限操作由另一个 Agent 负责。读和写分离，避免 prompt injection 导致的越权。

什么时候不需要工作流

动态工作流消耗的 token 显著更多，适合复杂、高价值的任务。

日常写代码，问自己一个问题：这件事真的需要 5 个 Reviewer 组成的评审团吗？大多数常规编程任务可能并不需要。

我的判断标准是：如果你能在 Prompt 里一句话描述清楚要做什么，而且做完之后你自己能快速验证结果，那就不需要工作流。需要工作流的场景通常有两个特征：任务可以被拆成独立的并行单元，或者验证成本高到你不想自己一个个检查。

用法和技巧

开启动态工作流的方法有两种：直接在 Prompt 里要求 Claude 创建工作流，或者用触发词ultracode。

描述调度模式的时候要具体。不是”用工作流做这件事”就完了，而是告诉 Claude Code 你想要什么样的验证方式、什么样的并行策略。上面那六种模式的名字可以直接用在 Prompt 里。

对于可重复的工作流（分流、监控、验证），搭配/loop 设置定期执行，/goal 设置硬性完成条件。工作流很容易跑飞，在 Prompt 里加一句“用 10k token”（大概一两轮对话的量）就能限制消耗。

工作流运行时按s 可以保存脚本，存到~/.claude/workflows 或者通过 Skill 分发给团队。

几个实际的 Prompt 示例

原文给了一组示例 Prompt，我觉得比理论解释更直观：

这个测试大概 50 次跑挂一次。用工作流复现它，形成竞争性假设，不找到经得起验证的根因不许停。
用工作流扫我最近 50 个 session，找到我反复在纠正的模式，把重复出现的提炼成 CLAUDE.md 规则。
拿我的商业计划，用工作流让不同 Agent 分别从投资人、客户、竞争对手的视角撕它。
这个文件夹有 80 份简历，用工作流按后端岗位排名，前 10 名交叉验证一遍。先用 AskUserQuestion 问我评分标准。
用工作流把我们的 User 模型全局重命名成 Account。

共同点很明显：都是可以拆分成独立并行单元的任务，并且都需要某种形式的验证或对抗。

写在最后

三个月前的《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，当时聊的是 Anthropic 用 Generator-Evaluator 模式做长时间全栈开发。那套架构需要人手动搭建，三个 Agent 跑 6 小时花 200 美元。

动态工作流的思路是把"搭建 Harness"这件事也交给 Claude Code 自己。不再需要你预先想好怎么拆分、怎么验证、怎么合并，Claude 看了任务之后自己决定。

这是不是靠谱？说实话，我的体感是：对于你已经有经验的任务类型，自己写静态工作流更可控；对于探索性的任务，让 Claude Code 自己决定调度方式确实能发现一些你没想到的拆法。两者不矛盾，动态工作流可以保存下来变成静态的。

不过话说回来，Harness 可能也像 prompt engineering 一样，是大模型发展过程中的一个中间状态。模型不够强的时候需要人写精巧的调度逻辑，需要多个 Agent 互相制衡才能把一件事做好；模型足够强了，这些逻辑就会被内化。今天你还在想怎么编排子 Agent，也许下一代模型根本不需要外部编排，自己就能在内部完成任务分解和对抗验证。当然，这个"也许"到底要多久，没人知道。