Codex-Maxxing：让 AI Agent 成为你的工作操作系统
OpenAI Codex 团队 Jason Liu 的深度实践指南——从 coding agent 到知识工作操作循环。八个原语重构你与 AI 的协作方式。
Magazine Article
从"写代码的工具"到"工作生活的地方"——Jason Liu 如何把 Codex 从 coding agent 变成知识工作的操作系统。
Jason Liu 是 OpenAI Codex 团队的开发者体验工程师。他的身份注定了这篇文章的双重属性——既是内部人的深度实践指南，也是精心打磨的产品宣言。但抛开营销外衣，核心命题值得认真对待：AI Agent 不应该只是一个聊天框，它应该是一个持续运转的工作循环。
Jason 的转变发生在 2024 年 11 月。他开始把 coding agent 推向"知识工作"领域——用 Slidev 做演示、用语音输入当笔记工具、寻找各种 agent 能生成的产物。然后他发现了关键洞察：
改变我行为的，是学会给工作一个运转循环（operating loop）：持久的线程、共享记忆、能操作电脑的工具、能引导和恢复任务的方式，以及一个让我能审查产出物的界面。
What changed my behavior was learning to give work an operating loop: a durable thread, shared memory, tools that can act on my computer, ways to steer and resume the task, and a surface where I can review the artifact itself.八个原语：从线程到心跳
持久线程
每个重要工作流保持置顶线程，经数月压缩积累历史、偏好和决策。代价：长线程不在缓存时 token 成本更高。
语音输入
核心不是速度，是让 agent 接收"未编辑版本"的思考。用 Granola 录制对话转录稿作为写作素材。"凌乱版本比打磨版本效果更好。"
引导（Steering）
在 agent 执行工具调用时持续注入下一条指令。不需要等每步完成才决定下一步。可以同时排队多个意图。
Obsidian Vault 记忆
Agent 的"家"与代码仓库分开。顶层 AGENTS.md 指示 agent 自动更新 vault。Vault 是 GitHub 仓库，diff 成了记忆审查界面。
浏览器/电脑使用
$browser 检查本地页面，@chrome 操作已登录浏览器多标签，@computer 处理 GUI 任务。连接器扩展到 Slack/Gmail/Calendar。
心跳（Heartbeats）
线程级自动化——"参谋长"每 30 分钟检查 Slack/Gmail，起草回复但不发送。Amazon 退款：洗完澡钱已到账。
目标 + 验证
目标要有验证标准。迁移 Rich 到 Rust 的标准："必须通过原库所有单元测试"。测试套件就是 oracle。
侧边栏
不只是预览，是工作发生的地方。Markdown、电子表格、PDF、幻灯片都能渲染和批注。Agent 看到同一个浏览器状态。
Codex 越有地方去记忆、回顾、检查和行动，我的工作就越不会在 prompt 之间死去。这就是我关心的变化。不是 agent 能帮我写代码，而是更多的工作能在我不在的时候继续运转。
The more Codex gets places to remember, revisit, inspect, and act, the less my work dies between prompts. That is the change I care about.⚠ 压力测试：三个致命假设
- Agent 足够可靠 — 发错 Slack 消息的后果可能是灾难性的。Fortune 报道："90% 成功率但 10% 不可预测失败的 agent，比 80% 成功率但失败可预测的更糟糕。"
- Token 成本可控 — GitHub 已有大量 Codex sub-agent 成本过高且不透明的投诉（#12488, #12487）。一个每 30 分钟的心跳，月度账单可能相当可观。
- 开发者工作流可推广 — vault、diff、HTML、CLI……这套工作流完全基于开发者心智模型。非技术人员几乎无法使用。
✓ 利益相关分析
- 作者身份：Jason 是 Codex 团队成员——这是开发者布道，不是独立评测。天然会淡化成本、可靠性、治理问题。
- 价值所在：但正因是内部人，他对工具能力的理解最深。八个原语的思维模式确实有普适价值。
- 沉默的证据：文章不提失败案例、不提竞品（Claude Code、Cursor）、不提"agent 发错消息然后呢"的治理问题。
- 方向判断：从"一问一答"到"持续操作循环"的方向是对的，但 Jason 描述的是理想态，不是当前态。
Socratic Dialogue
以师生对话展开核心观点。学生代表用户，老师引导式提问。
学生（尾巴）：我刚读了 Jason 的 Codex-Maxxing。持久线程、心跳、Obsidian vault……这个工作流真的靠谱吗？
老师：先问一个问题——你觉得这篇文章最大的隐性假设是什么？
学生：可能是"AI Agent 足够可靠，能处理真实任务"？比如让 agent 跟亚马逊客服要退款。万一发错消息呢？
老师：准了。评论区有人指出——持久线程 + 工具权限，没有审批门，"连续性"就变成了"静默漂移"。Jason 自己也承认 Heartbeats 是研究预览版，有 prompt 注入和未加密本地记忆的风险。
学生：但 Obsidian vault 思路挺靠谱——让 agent 把学到的东西写进文件，用 git diff 审查。
老师：全文最扎实的部分。文件把记忆从脆弱的 chat transcript 变成了可 diff、可编辑、可复用的持久形态。文件强迫 agent 把经验压缩成能独立于线程存活的形式。你已经在用 CLAUDE.md + memory 做同样的事。
学生：说到成本——这篇文章几乎没提 token 费用。
老师：最大的沉默。一个每 30 分钟运行的心跳，月度 token 账单可能相当可观。steipete 的 $1.3M token 账单说明成本是真实存在的。从他身上学思维模式，不学工具栈。真正的增量是"目标+验证"——不要说"实现计划"，而是说"通过所有测试才算完成"。
学生：Jason 还说"HTML 是比 Markdown 更好的输出格式"——output 变成小应用而不是文档。
老师：跟 @Thariq（Anthropic Claude Code 团队）昨天说的"HTML 继续保持不败"呼应。当产出从文档变成可交互的 artifact，协作关系确实会变。但盲区是——不是所有工作产出都适合 HTML。数据分析、API 设计、系统架构天然适合代码和文档。
从"一问一答"到"持续运转的操作循环"——方向是对的，但 Jason 描述的是理想态。真正的增量不在工具栈，在思维模式：持久线程、记忆序列化、目标+验证、跨工具反馈循环。
Personalized Insights
基于你的身份（QA 背景、全栈开发者、重度 Claude Code 用户、关注 AI 创业）提炼最切合的行动建议。
1. 你的 memory 系统已经走了 Jason 的路——可以更激进
CLAUDE.md + memory + issue.md = 他的 Obsidian vault。但 Jason 用 AGENTS.md 指令让 agent 自动更新 vault——你的系统目前更多是手动触发。可以在 CLAUDE.md 中加入"会话结束时自动更新 memory"指令，让记忆积累更自动化。
2. "目标+验证" 直接移植到你的开发流程
你的 QA 背景让这个思路天然适合——下次用 Claude Code 做功能开发时，先写测试（定义 oracle），再让 agent 持续工作直到全部通过。Jason 说得好："野心没有验证只是许愿"。
3. 心跳思路可升级你的 cron 任务
你已有 daily digest、daily conversations 等定时任务。Jason 的心跳更进一步——条件驱动的节奏调整：没有新内容就不发，有爆款内容时提前推送。在 cron 任务中加入条件判断逻辑。
4. Jason 的"Coder 偏见"是你的警示信号
文章的工作流完全基于开发者心智模型——vault、diff、HTML、CLI。你的用户画像正好匹配，但如果做 AI 产品，目标用户可能不是开发者。需要找到开发者和普通用户之间的平衡点。
5. 治理缺口是你作为 QA 应该关注的
评论区指出的"治理层缺失"——审批门、回滚、范围权限——正是 QA 本行。AI Agent 从个人工具到团队工具，治理层是必选项。这可能是一个值得深挖的创业方向。
精选评论
来自 Jason 推文下的 60 条回复中最有深度的观点。
@sam_wise_
框架对了——Codex 作为"未完成工作生活的地方"。但缺的是治理层。持久线程需要记忆 diff、审批门、回滚、范围权限和明确的 oracle。否则"连续性"变成带工具访问权的静默漂移。
@cdiamond
什么时候该暂停问人 vs 自己跑——这个 check-in 启发式才是缺失的那块。长期运行的工作就是在这里悄悄失败的。
@Criticality47
AGENTS 文件加上 vault diff 是全文最有力度的部分。它给线程一个地方写下学到的东西，在线程变得太贵或太奇怪之前。
@kleneway
分享了一个 goal-maxxing 模式：往 research.jsonl 写 x 行然后输出 report.md，持续更新 goal.html。jsonl 按行计数方便，强迫模型先做深度研究再判定目标完成。