据 OpenAI Codex 团队 Developer Experience Engineer、Instructor 库创建者 Jason Liu(jxnl) 5 月 10 日在个人博客发表的实战长文 Codex-maxxing,他系统拆解了 OpenAI Codex 近期更新后的 8 个核心用法。Instructor 是一个 Python 结构化 LLM 输出库,曾被 OpenAI 公开引用为其结构化输出功能的灵感来源。 需要先说明的一层利益相关:Jason 当前是 Codex 团队内部员工,这篇文章本质是内部最了解产品的工程师对外输出工作流 best practices,不是第三方独立测评。它的价值在于技术细节准确度高、踩坑路径真实;它的盲区在于结构性缺少跨产品对比视角(文章里没有出现 Claude Code、Cursor、Devin 任何一次)。读者应该把它当作"Codex 内部用法的权威说明",而不是"AI 编码 Agent 横向选型建议"。 以下是这篇博客的中文化深度拆解,补充国内可用的同类替代工具,并标出 Jason 没说的几条适用前提。
一、核心思想:从"一问一答"到"工作的归宿"
Jason 在 2025 年 11 月前主要用 Coding Agent 写代码、改 diff。真正改变他的不是模型变强,而是 Codex 最新一版给了一个让工作驻留的地方——能保留长线程、共享记忆、可以操作他的电脑、能在他离开时继续推进任务、能直接在侧边栏里检查产出物。
他给这套用法起了个名字:operating loop(运行循环)——任务的最小单位不再是"一个 Prompt 换一个回答",而是"一个会持续运转的小循环"。
这个判断对 ChooseAI 用户的实际价值是:评估 AI 工具时,真正的考察点不是模型能力,而是"工作流闭环"——线程能不能持久、记忆能不能落盘、能不能联到你的真实工作场景(Slack/Gmail/浏览器/桌面)、能不能在你不在的时候自己往前走。
按这套标准,目前同时具备这些能力的工具是:OpenAI Codex(本文主角)、Claude Code(命令行 + Skills + MCP + Hooks)、Cursor(IDE 内的 Background Agents)、Devin(更偏自治)。Jason 写的是 Codex,但底层方法论是通用的。 二、三件基础设施:持久线程、语音输入、中途引导
持久线程(Durable Threads)。Jason 维护着 5 个 pinned 线程,每个对应一个工作流:Chief of Staff(行政助理)、Agents SDK 关注、OpenAI CLI 跟踪、Codex 开源版、Twitter 监控。这些线程被他持续 compact(压缩) 了几个月,沉淀着历史决策、偏好和上下文。Codex 支持 Command-1 到 Command-9 直接跳转 pinned 线程。
代价:长线程不是免费的,重新回到老线程时对话已不在缓存里,单次成本高于全新短线程。Jason 的判断:对真正在乎的工作流,连续性的价值高于成本。
语音输入(Voice Input)。Codex 自带语音输入,Jason 额外用 Wispr Flow 做系统级听写。他强调语音的价值不是速度而是颗粒度——AI 拿到的是未经修剪的原始思考,例如"我记得 Slack 里有个叫 Ben 的家伙提过一嘴这事,你去找一下"——这种话打字打不出来,说出来很自然。中文用户可以对照的方案:讯飞输入法 + Wispr Flow 或 腾讯听听,或者直接用 Mac 自带听写(中文识别已可用)。
中途引导(Steering)。Codex 允许在工具调用过程中插入下一条指令而不必等当前步骤完成。Jason 给的例子是在审一个网页时一边看一边说:"把这里改小""这段文案不对""间距不对劲""做完开个 PR""等预览部署完发链接到 Slack"——意图被持续投喂,他可以走开。
这三件加起来,工作单元从"一次对话"变成了"一个被引导的运行循环"。
三、让记忆"长出来":Obsidian vault + AGENTS.md + Codex Memories
线程变长之后,记忆就需要从单个线程里外溢出来。这是 Jason 这篇文章里最具借鉴价值的一段。
他的做法:绝大多数长期线程的根基是一个 Obsidian vault,目录结构如下:
顶层放一个 AGENTS.md,写明给 Agent 的指令——例如:"当你了解到关于某个人的更多信息、推进了某个项目、或关闭了一个 open loop 时,去更新 vault 里对应的页面"。Vault 整体作为 GitHub 仓库管理,这件事买到了两个东西:(1) 可以在云端工作,(2) diff 成为记忆的审阅入口——Agent 写了什么进 vault,他能 review。
Jason 在这一段写了一句很值得划的话:"我不希望长线程在对话历史里悄悄积累 vibes,我希望它写下变了什么:这个人喜欢什么、这个项目卡在哪、这个决定怎么定的、这个 loop 已经关了。"
记忆必须被序列化成可读、可 diff、可复用的产物,而不是埋在更长的聊天记录里——这是该段的核心方法论。
对照:Codex 自带的 Settings > Personalization > Memories 与新推出的 Chronicle(屏幕上下文辅助构建记忆)是平台级方案,但 Jason 把它们定位为 "local recall layer",不替代显式落盘的 vault。Chronicle 目前是研究预览,Jason 引述官方文档提醒了几个真实 tradeoff:权限、速率限制、prompt injection 风险、本地内存文件未加密。这些是 ChooseAI 用户实操前需要心里有数的细节。
国内 ChooseAI 读者可对照的实操方案:
- Obsidian vault + 自定义 AGENTS.md 已经是社区里相对成熟的做法,Claude Code、Cursor、Codex 都能读
- 国内备选:飞书文档 + MCP 连接器(已支持)、语雀知识库(API 接入)
- 极简版:任意一个 GitHub repo + 一份 AGENTS.md + 几个 Markdown 文件,这就是最小可用的 Agent 记忆系统
四、Computer/Browser Use、Heartbeats、Goals:让任务自己往前走
这三件功能合起来构成了 Jason 文章的"长任务实操层"。
Computer/Browser Use 的三层区分。Jason 给了一个非常清晰的心智模型:
- $browser 用于本地网页 surface,适合检查与标注本地静态 artifact
- @chrome 用于已登录的浏览器会话(多个 tab 并行),适合让 Agent 在已登录态下操作
- @computer 用于只能 GUI 操作的桌面应用
举例:他工作机上 Twitter 登在 Safari,如果让 @computer 读 Twitter,Safari 就被占住了;@chrome 不会接管整个浏览器,适合多 tab 并行。这是一条很多 Computer Use 使用者第一次接触时会踩的实际坑。
外加 Connectors($slack、$gmail、$calendar)和 Skills(可复用工作流模版)——后者的核心模式是:做过一次有用的事,把它打包成 Skill,下次不用重新教。这跟 Claude Skills 是同一套思路,本质都是"工作流的工件化"。
Heartbeats(心跳)。线程内置的定时调度。三个 Jason 给的真实案例:
案例 1 — Chief of Staff(每 30 分钟跑一次):
每次回到 Slack,草稿已经在等他——他只决定哪些发,收集上下文的脏活已经做完。
案例 2 — 动画反馈循环:他在 Slack 发了个视频,让 Codex 每 15 分钟检查评论、有评论就重新渲染、然后发回 Slack 并 @ 评审人。关键细节:Slack MCP 服务器不支持上传文件,Agent 直接用 @computer 按 "Add file" 按钮把渲染结果传上去。这种跨工具边界自适应是 Heartbeats + Connectors + Computer Use 协同的真实价值。
案例 3 — 自动追退款:Amazon 客服排队 25 分钟,他设了个 Heartbeat:
洗完澡退款下来了。
Goals(目标)。Jason 说这是他还在学习用好的功能,但他强调一条原则——"野心要大,验证要硬":
弱目标:"按这个 Markdown 文件里的计划实现"。 强目标:包含一个 Agent 可以反复验证的成功标准。
他举的例子:把 Python 的 Rich 库迁移到 Rust,但必须通过原项目所有单元测试。这个 test suite 给了 Agent 一个真实的 oracle——Rust 移植版没通过 Python 版的全部测试,任务就没完成。
Jason 的原话非常值得划:"Execution is only as good as the goal and the verification you give it. Ambition without verification is just a wish."(执行的上限取决于目标和验证机制。没有验证机制的野心只是愿望。)
这条对 ChooseAI 读者的迁移启发:做 Agent 任务设计时,先回答"这个任务怎么算完",再回答"怎么做"。这跟 SWE-bench / Aider / Cursor Background Agents 上能跑通复杂任务的共同前提是一致的。
五、Side Panel:让工作和检查在同一个表面发生
Jason 文章后半段最兴奋的一段是关于 side panel(侧边栏)。他认为这个东西被低估了——很多人把它当成"预览的地方",但实际是 Codex 从聊天 App 变成工作 App 的关键。
侧边栏能干三件事:
检查 artifact:Markdown、CSV、PDF、Excel、Slidev 演示直接在侧边栏渲染。CSV 不再是裸文本是表格,PDF(含 LaTeX 渲染)可直接看,演示文稿不用切到 Keynote。他重点强调:Spreadsheets 支持公式渲染与单元格编辑,他用这个管 Codex 开源版的项目计划。
操作 web 表面:内置浏览器 + JavaScript 操作 + 在页面上直接标注:
Jason 引用 Thariq 的观点:HTML 比 Markdown 更适合做 AI 输出格式——一旦输出从"文档"变成"小应用",人机协作关系就变了。他自己在用 Heartbeats 定时刷新一个 index.html,这样每次回到线程,总有个新鲜 artifact 在等他。这个手法对内容创作者特别有借鉴:同样的逻辑可以套到数据看板、稿件预览、SEO 落地页生成上。
最小化原则:他强调"最小版本通常是最好的版本"——单个 index.html 比 Vite 项目+服务器更耐用,因为不需要保持任何服务存活。这条经验对 ChooseAI 读者做 Bing SEO 长尾页特别相关:静态 HTML > 动态服务,跑得久、查得到、改得动。
六、局限与上手建议
读完文章,有几个Jason 没明说但 ChooseAI 读者实操前应该想清楚的边界:
第一,Codex 平台依赖。文章里所有"持久线程""Heartbeats""side panel""Goals"都是 Codex App 内置功能。如果你的工作流在 Claude Code / Cursor / Windsurf 上,这套方法论可迁移,但具体实现需要自己拼:Claude Code 用 SKILL.md + Hooks + MCP,Cursor 用 Background Agents,Windsurf 用 Cascades——能力点能对上,但 UX 没 Codex 这套统一。
第二,成本不可忽视。Jason 自己提到长线程"不在缓存里时单次成本高于新线程"。Heartbeats 每 5/15/30 分钟跑一次,叠加多个 pinned 线程,月度账单需要心里有数。Codex 免费版能不能跑这套用法,文章没明说,大概率需要 Plus 或 Pro。
第三,Computer Use 的安全边界。Jason 文章里没强调,但这是 ChooseAI 中文读者必须知道的:@computer 一旦给了权限,Agent 能看到你的屏幕、点击你的应用、读取你的输入——国内常见的微信、企业微信、飞书桌面端如果含敏感对话,要么不开 Computer Use,要么单独开一个干净的工作账户。
第四,Chronicle 仍是研究预览。Jason 引用了官方文档说的"opt-in research preview with real tradeoffs around permissions, rate limits, prompt injection, and unencrypted local memory files"——本地未加密的记忆文件 + prompt injection 风险是真实的,生产环境慎用。
第五,Heartbeats 适用场景有边界。Jason 三个例子的共同特征:任务确定性高、外部世界状态可观察、失败成本低。让 Heartbeat 每 5 分钟追退款 OK,让 Heartbeat 每小时自动处理客户合同就是另一回事。
第六,语言与本地化。文章里所有工具几乎都是英文为主的产品:Codex、Wispr Flow、Slidev、Storybook、Remotion、Streamlit、Obsidian。中文工作流要跑这套,需要做的国产化映射:Slack → 飞书、Gmail → 钉钉邮件、Google Docs → 飞书文档/语雀、Wispr Flow → 系统输入法听写、Obsidian → 仍用 Obsidian(中文社区成熟)。
第七,作者身份带来的视角偏置。Jason 是 Codex 团队的 Developer Experience Engineer,这意味着文章对 Codex 内部细节(Command-1 到 Command-9、Chronicle 的 tradeoff、Codex pets、Hatch Pet skill、side panel 的三个 job)准确度极高,但结构性回避了与 Claude Code、Cursor、Devin、Windsurf 的横向对比。如果你的实际选型问题是"我应该用 Codex 还是 Claude Code",这篇文章给不出答案——它默认 Codex 是底座。读者如果在做选型,需要再读至少一篇来自 Claude Code 或 Cursor 重度用户的对应实战文。
七、给独立开发者与内容创作者的 5 步上手清单
把 Jason 这篇文章压缩成可立即上手的 5 步:
- 建立第一个 pinned 长线程:挑一个你最在乎的工作流(例如 ChooseAI 的新闻生产)开线程,坚持用 1 个月再评估
- 建一个 Obsidian vault + 顶层 AGENTS.md:写清楚 Agent 在什么情况下该更新哪些 Markdown 文件,vault 推上 GitHub 私有仓库
- 配一个 Heartbeat 实验任务:挑一个低风险、可观察、失败可逆的场景试水(例如每天早上 8 点检查关键 RSS 源,起草今日新闻清单)
- 给一个真实任务设强 Goal:不要只说"做 X",写明"做 X,直到通过 Y 验证"——这一条对 SEO 文章生产、产品迭代、代码迁移都适用
- 把侧边栏当工作主表面:从一个 index.html 开始,让 Agent 把任何能视觉化的产出物放进 side panel,而不是堆在对话里
如果这 5 步里你只能挑 1 件做,挑第 4 件——"野心要大,验证要硬"是这篇文章里成本最低、回报最高的方法论。
原文署名 Jason Liu,现任 OpenAI Codex 团队 Developer Experience Engineer,Instructor 库创建者。博客地址 jxnl.github.io/blog,Twitter @jxnlco,GitHub github.com/jxnl。该文 5 月 10 日发表,归档于 Applied AI / Personal 两个分类。
AI 速览
