Codex 长任务：让智能体在你睡觉时继续工作

2026年4月20日2 分钟阅读

Share with

笔记本装不下的那类任务

大多数 Codex 工作都很短。提一个问题，等二十秒，拿到一份补丁。一天来上一百次，笔记本应付得完全没问题。

真正把笔记本这套模型撑爆的任务，是另一种样子。一次通宵的重构，改写五十个文件、每跑一轮就执行一次测试套件；一次批量评审，智能体读完所有打开的 PR，写好总结发到 Slack；一次文档扫描，在代码库里走上两个小时，产出一份全新参考。这些不是聊天轮次——这些是作业，时长以小时计。

笔记本合上、Codex 进程随之消失——VPS 让任务继续跑

笔记本对这些任务的失败方式都一样。你合上盖子、切换 WiFi，或者电池在火车上没电，Codex CLI 进程就跟着走了。智能体辛苦攒起来的上下文瞬间蒸发。早上回来，只剩一个死掉的终端，和你原本想让它跑满的那六个小时，连个交代都没有。

对 Codex 来说，「长任务」到底指什么

只要下面有一条成立，Codex 任务就算长任务：

总时长超出典型的笔记本使用时段。 任何超过约 2 小时的东西，都会撞上睡眠、通勤，或一个让你合上盖子的会
任务必须熬过网络切换。 咖啡馆 → 家 → 办公室，意味着笔记本 IP 换三次；每一次切换都可能掐掉 Codex 会话
它依赖智能体之前积累的状态。 如果智能体花了一个小时读文件、做摘要，丢掉上下文等于丢掉这一个小时，而不只是最后一次请求
你希望智能体响应外部事件。 GitHub webhook、cron 触发器、落到 S3 的文件——它们不会等你重新打开笔记本

任务一旦跨过其中任何一条线，你就需要一台在你不在时仍然在线的主机。

四种能撑几个小时的模式

我们在 Office Claws 跑过的每一个长时 Codex 工作流，都落在下面四种里。没有一种在笔记本上能跑，全部都能在 VPS 上跑。

模式	典型时长	在笔记本上会坏在哪儿
通宵重构	4–10 小时	睡眠、电池、酒店 WiFi
批量评审 / 分类	30 分钟 – 2 小时	两个会议之间盖子合上
持续观察者	24/7	任何不是服务器的东西
定时任务	几分钟，但在凌晨 03:00	你在睡觉

贯穿始终的是：智能体得可达、得在跑、得握着上下文——在一个跟你什么时候敲键盘完全无关的时刻。

在 Office Claws 里，每一个智能体都跑在自己的 DigitalOcean droplet 上，用预先构建好的快照大约两分半钟就能开出来。Codex CLI 装好了，登录了你的 ChatGPT Plus 或 Pro 订阅，并通过 Tailscale 可达。Self-Hosted 方案下 droplet 每月 4 美元（应用本身每月 4.99 美元，我们前 100 位用户是 2.99 美元），Managed 方案下则打包进每月 14.99 美元里。

我们跑长任务的流程是这样的：

# From your laptop, over Tailscale — connects to the droplet
ssh office-claws-agent
 
# Start the task in a persistent session so it survives the SSH drop
tmux new -s refactor
codex "rewrite backend/services/* to use the new context shape; \
       after each file, run go test ./...; if tests fail, revert that file"
 
# Detach: Ctrl+b, then d. Close the laptop. Go to bed.

第二天早上 tmux attach -t refactor，完整日志就在那儿等着。智能体跑了一整夜。你的订阅覆盖了 token 费用。这八个小时的 droplet 花了你大约十二美分。

时间线：笔记本在 23 点合上，Codex 在 VPS 上跑一整夜，早上 8 点 diff 就绪

三个糟蹋掉这套方案的错误

我们见过的大多数故障都聚集在同样三件事上：

用普通 SSH 会话而不是 tmux 或 screen 跑 Codex。 SSH 一断，Codex 跟着就没了。长任务永远要裹在持久会话里——tmux、screen，或者 systemd 服务（如果你希望它完全无人值守）
让 VPS 的磁盘被塞满。 长重构会生成大量日志和测试产物。磁盘满了，任务第六个小时就会被杀掉。加一个 cron，每周截断一次 ~/.codex/logs
忽略 rate limit。 ChatGPT Plus 按滑动窗口内的消息数封顶。不停捶打 API 的任务会在第三个小时左右撞上限。如果真的是硬核的通宵工作量，升级到 Pro —— 即便是激进的负载，每月 200 美元的额度也几乎从没被耗光过

什么时候更该用定时任务

不是每个长任务都该做成交互式。如果作业本身毫无歧义——「每周一 06:00 汇总上周提交并发到 Slack」——就别折腾 tmux，直接在 droplet 上设一条 cron。Codex CLI 配合从 stdin 传入的 prompt，在无头模式下跑得很顺。VPS 变成调度器，失败时你收到邮件，也没有什么会话需要重新连上。

批量和定时负载的完整模式我们在另一篇指南里会讲，这里简版是：如果每次的 prompt 都一样、输出可被机器解析，它就属于 cron，而不是聊天窗口。

这会改变你的工作方式

一旦长任务不再需要笔记本，问题就变了。你不再问「我现在有时间跑这个吗？」，而是问「我希望明早看到结果，还是希望这周末之前看到？」。智能体变成后台 worker，而不是前台工具。笔记本变成一个接入口，通向一件在你打开它之前就已经在跑的事。

这就是把 Codex 放到 VPS 上的全部理由。Token 账单不变。模型不变。变的只是——你停下来的时候，时钟还在继续走。