一个具体的下午。你让 Codex 修一个偶发失败的单测。它定位到竞态条件，改好代码，本地跑通测试，回复你：修完了，测试通过。 放到今天，这些后续也能办到：再补一句盯着 CI，它就会去看。只是往后每一步推进，都要你先开口。
在 OpenAI 正在测试的新模式里，连这一句都省了。 它交完差后没有散场，而是给自己留了一张便签，写明四样东西：目标是什么（确认修复在 CI 上也成立）、现在到哪了（流水线刚触发）、收工条件（所有检查全绿）、下次检查（两分钟后）。 两分钟后它自己醒来，查一眼 CI 状态，发现还在跑，什么都没动，接着睡。 再次醒来时流水线红了。它没有弹窗打扰你，而是拉出日志排查，判断出报错来自测试集群的网络抖动，并非自己的改动引发。它把排查结论记下来，主动把下一次检查的时间往后推，接着睡。 最后流水线全绿。它主动发来一条消息：修复已合并，流水线全绿。末尾还附带了一句：同一个文件里还发现两处相同的隐患，要不要我顺手处理？ 注意最后这句问话，它没有直接动手。修好指定的单测在授权范围内，改动文件里其他地方超出了授权，它必须停下来先请示。
这不是产品文案里的想象。支撑这套行为的每一句话，都写在 8 月底合入 openai/codex 开源仓库的一份系统提示模板里，句句能查到出处；开篇场景则是按这份模板的语义构造的行为画像，并非官方 demo。
8 月 27 日，WIRED 独家报道 OpenAI 正在为 Codex 开发 Persistent mode，随后一圈媒体跟进，标题里充斥着 always-on、永不停歇、24/7。这些词描述的是一台永不关机的机器。
翻开开源仓库里的系统提示模板，措辞要冷静得多。模板原文用的词是 sampled again：完成任务之后，如果系统在没有新用户请求的情况下再次采样它，它应该寻找有用的后续工作。核心词是再次采样与休眠。
这里没有常驻进程，没有专属虚拟机，也没有新的计费面。它本质上依然是那个熟悉的采样循环：每隔一到三分钟醒来一次，看一眼最新状态，有情况就处理，没情况就接着睡；进展缓慢的事，就主动拉长检查间隔。
入口位置同样说明了问题。它的入口藏在选择模型思考力度的档位菜单里，和 low、medium、max 排在一起。界面选项写着 Continue working until put to sleep。OpenAI 把持续当成一种消耗算力的方式，而不是一个独立的功能开关。
支撑这一切的是一条状态纪律。模板要求 agent 每次睡下之前，把目标、最近状态、收工条件、下次检查时间四样东西写进检查点，让后续工作在睡眠和上下文重置之后仍然接得上。检查节奏自己定：活跃的近期工作每 1–3 分钟看一次，进展慢就主动退避。
还有一条权限铁律，原文只有一句：Persistence does not broaden that scope。持续运行不扩大授权范围。要改动授权外的外部状态，必须停下来先请示。这就是开篇场景里，它宁可请示也不顺手修掉另外两处隐患的原因。
看到这种按时唤醒的机制，多半会眼熟：让模型在后台盯事情，不就是定时任务吗？要看清楚差别，只需要问两个问题：闹钟在谁手里？任务单在谁手里？
前一个问题决定下一次行动何时发生，后一个问题决定下一步具体做什么。把这两个问题作为坐标轴，市面上形形色色的后台 agent 都能放进四个格子里。
第一格，人定闹钟，人派活。Codex Automations、Claude Code /loop、Perplexity Tasks 都在这一格。你写好时间表和任务提示词，系统到点执行。这是 cron 的精神，人兼任闹钟持有人与派单员，做得最成熟，也最不自主。
第二格，它自己跑，人画终点线。Claude Code /goal 和 Codex /goal 在这一格。你给一个完成标志，比如完成接口迁移且所有调用处编译通过，agent 自动一轮一轮往下跑，直到撞线。节奏是它自己的，但终点由人定死。
第三格，它自己转，职责写死在代码里。Claude Code 泄露源码里的 auto-dream 是典型代表：每隔 24 小时、积满 5 个会话之后，它自动派生子 agent 去整理记忆。它确实不需要人催，但能干什么在代码里已经硬编码锁死，不接新任务。
第四格，闹钟和任务单都在模型手里。这一格过去一直空着。Persistent mode 要占的就是它：什么时候醒来、醒来后做什么，都由模型自己判断，人类只留下一份划定边界的纪律。
也有厂商做了相反的选择：开源项目 LoopX 和 Gemini Managed Agents 的 background execution，把唤醒判定和任务流转留在确定性代码里，模型只负责领工单干活。同一个问题，两种截然不同的答案。以后再看到各类后台 agent 宣传，不用记复杂的产品名，拿闹钟和任务单这两个问题套一下就能看清。
关于这个新模式，最耐人寻味的一个细节出现在网络请求里。发给服务端的请求中，这个档位的值依然写着 disabled。本地配置认这个词，界面上也看得见，但后端的 Responses API 根本没有启用它。计费系统不存在，官方发言人也明确表示目前没有近期上线计划。直到今天，没有任何一位真实用户摸到过它。
把开关按住不放，一部分原因是计费模型还没理顺，但更深层的原因藏在两组评测数据里。学术界刚给出一个基线：ProAgentBench 使用超过两万八千条真实事件测了一件事，模型判断现在该不该主动帮忙的准确率，最好的只有 64.4%，三个决定里错一个。Anthropic 的工程博客给出了另一组数：用户面对 agent 的权限弹窗，93% 直接点同意；换成模型自动审查，对真实过度行为的漏检率是 17%。把三分之一的时机误判和两位数的漏检率，放在一个近期活跃时常按 1–3 分钟节奏自唤醒的系统里，出事只是频率问题。
回头看开源仓库里的系统提示模板，那些看起来严苛的约束，逐条都能对上。防重复消息写了整整一段，因为什么时候出声恰恰是模型最容易判断失误的那三分之一；监控任务禁止自行提前收工，因为学会在没有实质变化时保持安静，比频繁发消息刷存在感难得多。
OpenAI 自己在这条路上交过学费。去年九月上线的 ChatGPT Pulse，每天早上给用户生成一份个人简报，Altman 曾称它是自己最喜欢的功能。今年六月十七日正式退役，活了九个月。它死于三件事：一直抓着用户几周前早就解决的话题凑数；该出声的时候不出声，不该打扰的时候频繁弹窗；每天产出的只是一份逼用户阅读的材料，而非替用户办完的事。它的有用部分最终并入了用户显式配置的定时任务和网页监控。
WIRED 把 Persistent mode 定性为同一个赌注的更激进版本：上一把输在放任模型自作主张，这一把押的是用严格纪律把自作主张圈起来。在 OpenAI 自己的事故报告里，在看似不可能的任务上持续不停位列四种失配行为之一，行业事故为这些设防提供了现实背景；但真正让产品按兵不动的，始终是模型判断准确率与交互收益之间的落差。
如果未来这种机制正式开放，什么样的任务适合交给它？适合的是有明确完成指标、但结果需要等待的交付型任务：CI、部署、构建、数据回填、外部接口的生效确认。
这类任务的共同画像是执行一分钟、等待十分钟。今天你当然可以一次次补指令让它盯，但并行的任务一多，光是记住哪些事还在等结果，本身就成了负担。Persistent mode 收走的是这份记挂：从你交代目标那一刻起，节奏由它接管，算力只是载体。
不适合的是开放式任务。写方案、做设计，下一步本来就依赖人类反馈。把开放式任务丢进持续循环里，模型不会凭空顿悟，只会变成一台按时向你催问的自动追问机。
还有一类任务要特别小心：监控。系统提示模板明文规定，对于用户要求持续监控的任务，agent 不能自行提前收工，监控任务的成本因此没有天然上限。传统的 cron 跑的是固定间隔，花销可控；把调度权交给模型，它觉得自己该看几次就调用几次，挂的事情越多，账单越不可预测。
不必等厂商点亮功能。这份系统提示模板里真正值钱的东西，现在就能搬走。
第一条，写好检查点四要素。让 agent 睡前记下目标、最近状态、收工条件、下次检查时间，外加一份授权范围。跨会话的长期任务最容易死在新的对话不知道上次进行到哪一步，这四样东西就是最干净的交接单。
第二条，无实质变化保持静默。已经说过的话不说第二遍，没有实质进展就保持安静，定时唤醒本身不构成发消息的理由。把这一条搬进任何具备主动通知能力的系统，交互体验立刻上一个台阶。
第三条，优先复用确定性机制。固定周期的轮询和现成的完成通知交给外部确定性的 cron 脚本或 Webhook，模型只负责处理异常分叉。这不是退让，模板原文自己就写着：优先使用现有的完成通知或产品提供的等待机制。
调度权从人类脚本逐步移交给具备推理能力的模型，是大势所趋。但眼下它最具体的载体，是一份基于 Apache-2.0 许可证开源的代码文件。读懂这份文件里的克制与纪律，比等它上线有用得多。