【AI】Codex 的工作流更新-v3 [Codex-maxxing for long-running work]

Codex 工作流更新-v3最近 OpenAI 的一篇博客 Codex-maxxing for long-running work 分享了关于长周期复杂任务的指南并针对我已有的工作流作出一些更新。长周期的复杂任务通常不是一次 prompt 改完代码就结束。它可能要经历调查、实现、预览、反馈、等 CI、继续修改、准备 PR、后续检查。该博客更像是总结了 Claude Codegoal和loop命令的思想 v2 现状v2 从项目初始化开始setup-light/setup-full生成AGENTS.md、CLAUDE.md和docs/记忆文件让 Agent 进入一个项目后知道行为规范。它不太关注于任务线本身比如预览页面谁来看用户反馈放在哪里PR review 几个小时后才来又怎么接着改这些长期任务流程问题是 v2 未涉及的。长时间复杂任务OpenAI 这篇博客把 Codex 看成一个 persistent workspace一件复杂任务有自己的线程、记忆、工具和审阅对象重要的有以下几点。Durable thread给长期任务一个固定会话维护会话的上下文、旧决策、待办和用户反馈容易丢失。Memory不只依赖聊天记录而是把项目状态、决策、开放事项写进可以查看、可以 diff、可以复用的文件。对应到当前工作流里docs/就承担了 memory 的作用跨项目 or 会话的个性要求则可以放进个人记忆或知识库。SteeringCodex 工作时用户可以继续补充 prompt。比如“先不要接短信登录”“这个错误提示太别扭”“等预览部署完再继续”。任务就不再是一次性指令而是可以边做边调整的任务队列。Thread automation定时任务比如等待部署、看 review 是否更新、检查支持工单有没有新回复。Side panel产物本身要进入审阅循环。Markdown、CSV、PDF、slides、本地页面预览都可以直接作为审阅对象用户的评论继续变成下一轮任务上下文。Goals目标要能有具体的量化标准如要写清楚页面、接口、测试、异常情况分别达到什么结果。这些点合在一起就能把任务进化成一个工作循环目标 - 线程 - 项目记忆 - 调用工具 - 产出 - review - 下一轮任务这张图可以作为本次更新的总览三层模型通过上述总结可以把工作流分成三层Thread保存一条长期任务的上下文Project memory保存 repo 内的事实也就是AGENTS.md和docs/*Execution surfaces接触真实工作界面比如 browser、Chrome、computer use、connectors、skills而 v2 正好属于 Project memory 这一层所以不需要做改进。另外长期任务容易越做越多所以边界要提前写清楚例如可以配置相关 Hooks哪些任务适合长期线程不是所有任务都要开长期线程。一次性命令、小改动、马上能验完的问题按 v2 的普通流程就够。更适合长期线程的场景会跨多轮修改需要用户看预览或多次反馈需要等待 CI、部署、review、第三方回复需要跨工具处理比如 GitHub 本地代码 浏览器后续可能沉淀成 skill中断后还要接着做Prompt 模板下次遇到复杂任务需要长时间工作流的场景可以直接这样编写 prompt可以手动引用loopgoal命令进一步约束 Agent确保执行正确这是一个长期任务线程任务名。 先读 AGENTS.md 和 docs/agent_workflow.md。 必要时再读 docs/project_status.md、docs/project_spec.md、docs/architecture.md。 目标 - 目标 1 - 目标 2 验收标准 1. 可以检查的结果 2. 需要运行的检查 3. 需要用户审阅的产物 执行规则 - 先调查不要急着改代码 - 改前说明方案和影响范围 - 改后运行相关检查 - 涉及 UI 时启动本地预览并给出地址 - 不要 push、发布、删除数据、发送消息除非用户明确批准 - 任务中断前更新 docs/project_status.md这里的关键是验收标准要能检查。不要只写“完成登录功能”而是写清楚哪些页面、哪些接口、哪些测试、哪些异常情况必须通过。Tools此外还要说清楚任务需要碰到哪些工具。可手动引用或在规范文档、prompt 中提示常见选择本地网页预览用 browser需要用户登录态用 Chrome必须点桌面软件用 computer useGitHub、Gmail、Slack、Calendar用对应的 MCP反复使用的流程整理成 skill需要隔一段时间回来查用 thread automationcheckpoint 的判断v2 里 checkpoint 更像 commit 前的项目状态检查这里 checkpoint 更像一次任务阶段记录。需要 checkpoint 的情况包括当前阶段已经完成任务要暂停要交给另一个 Agent后续需要接着做出现新的风险或阻塞行为、架构、依赖或项目状态发生变化与之前的 checkpoint 思想不同不是为了每次 commit 都按需更新记忆文档而是为了让任务之后能接上。如果只是普通小改动就不需要每次都更新一堆 docs。复盘v2 规定了 Agent 对项目的维护方式v3 则是面对复杂长期任务时总结的思想博客来源Codex-maxxing for long-running work