OpenAI 的 Codex 团队的 Jason Liu，写了篇文章介绍 Codex 中两种定时工作的方式，翻译一下：

Codex 中两种定时工作

大多数自动化相关的说法，都比它真正要做的事复杂。

你想让 Codex 稍后做某件事，或者持续检查某个东西，直到它发生变化。听起来这像是同一个功能。实际上，这是两类不同的工作，区别很简单：

**Scheduled Tasks** 每次运行时都会创建一个新线程。

**Scheduled Messages** 每次运行时都会使用同一个已有线程。

整个模型就这么简单。

当每次运行都可以从头开始时，使用 Scheduled Task

如果一项工作脱离创建它的那段对话之后，依然能成立，那么它就适合用 **Scheduled Task**。

例如：

> 每天早上 9 点，帮我总结一下我需要补看的邮件、日历和团队消息。

明天的总结不需要记住今天的总结。它需要的是同一套指令、当前的信息，以及一个新的地方来汇报结果。

当一个任务需要跨多个项目运行，或者你希望每次运行都单独出现在 Triage 里时，这种方式也很有用。每次运行都是一个独立线程。把这些运行连接起来的，是这个日程安排本身。

当下一次检查需要依赖当前线程时，使用 Scheduled Message

**Scheduled Message**，有时也叫 thread automation，会在每次运行时回到同一个已有线程。

例如：

> 每 30 分钟检查一次这个 PR。如果有评论，就处理它们，并保持 CI 通过。PR 合并后停止。

下一次检查依赖之前已经发生过的工作。这个线程知道你指的是哪个 PR，哪些评论已经处理过，CI 哪里失败过，以及自上次检查以来发生了什么变化。

这种方式适合：

* 轮询更新* 检查状态变化* 持续研究或分拣处理* 有明确停止条件的工作

把这些运行连接起来的，是这个线程本身。

决策规则看上下文

只需要问一个问题：

> 如果这件事明天运行，它是否需要之前那段对话？

如果不需要，就用 **Scheduled Task**。给它一个持久、稳定的 prompt，让每次运行都能干净地重新开始。

如果需要，就用 **Scheduled Message**。把工作保留在同一个线程里，这样每次检查都能基于之前的决策和结果继续推进。

日程安排当然重要，但它不是主要决策点。真正的关键在于：有用的上下文应该放在哪里。

做一个自己的 loop skill

我不想每次都重新记住这些设置问题，所以我会做一个小 skill，把一个粗略请求转换成合适的定时工作流。

给 Codex 这个 prompt：

```textCreate a reusable loop skill for scheduled work.

When I give it a request, first decide whether each run can start fresh or whether the next check needs the current thread's context.

If each run can start fresh, help me create a Scheduled Task.If the next check needs the current thread, help me create a Scheduled Message.

Infer what you can from the conversation. Ask only the missing questions that materially change the workflow:- What should Codex do each time?- How often should it run?- What change is important enough to report?- When should it stop?- When should it ask me for input?

Then create the scheduled workflow with a short, durable prompt that will still make sense on a later run.```

最好的自动化，并不是从复杂系统开始的。它的起点只是弄清楚：下一次运行需要一张白纸，还是需要回到同一个线程。