1. Codex 中的两种定时任务

📌 本文翻译自 Two kinds of scheduled work in Codex，作者 Jason Liu

大部分自动化的复杂度都超过了任务本身。

你想让 Codex 在未来的某个时间做某件事，或者持续检查某件事直到它发生变化。这听起来像是一个功能，但实际上对应两种不同的工作模式，区别很简单：

• Scheduled Tasks（定时任务）——每次运行时都会创建一个新线程。
• Scheduled Messages（定时消息）——每次运行时都使用同一个已有线程。

这就是整个模型。

[!info] 阅读导览
第 1 章 Scheduled Task（每次可重新开始） → 第 2 章 Scheduled Message（需要持续上下文） → 第 3 章 决策规则：上下文放在哪里 → 第 4 章 自己做一个循环 skill

2. 每次运行可以重新开始时，用 Scheduled Task

当任务不需要创建它的那个对话上下文也能正常执行时，Scheduled Task 是最佳选择。

2.1.1. 典型场景

例如：

每天早上 9 点，汇总我的邮件、日历和团队消息中我需要跟进的内容。

今天的总结不需要记住昨天的总结。它需要同样的指令、最新的信息，以及一个全新的地方来报告结果。

2.1.2. 跨项目与独立运行

这也适用于一个任务需要跨多个项目运行，或者希望每次运行在 Triage 中独立展示的场景。每次运行都是独立的线程，把它们联系在一起的是调度本身。

3. 下次检查需要上下文时，用 Scheduled Message

Scheduled Message（有时称为线程自动化）每次运行时都会回到同一个已有的线程。

3.1.1. 持续监控示例

例如：

每 30 分钟检查这个 PR。如果有评论，处理它们并保持 CI 绿色。PR 合并后停止运行。

下一次检查依赖于已经完成的工作结果。线程知道你说的是哪个 PR、哪些评论已处理、CI 中哪里失败了，以及自上次检查以来发生了什么变化。

3.1.2. 适用场景

这种模式适合：

• 轮询等待更新
• 检查状态变更
• 持续调研或分类
• 有明确停止条件的工作

把运行连接在一起的是线程。

4. 决策规则在于上下文

4.1.1. 核心判断标准

问一个问题：

如果明天再跑一次，它需要之前的对话吗？

如果不需要，用 Scheduled Task。给它一个持久的 prompt，让每次运行从零开始。

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

flowchart TD
    A[明天再跑一次，需要之前的对话吗？] -->|不需要| B[Scheduled Task<br>每次运行从零开始]
    A -->|需要| C[Scheduled Message<br>保持同一线程继续推进]

4.1.2. 调度 vs 上下文

调度本身很重要，但它不是主要决策。主要决策是有用的上下文应该放在哪里。

5. 自己做一个循环 skill

我不想每次都记住那些配置问题，所以我会做一个小型 skill，把粗略的需求转化为正确的定时工作流。

5.1.1. 构建可复用的 skill

给 Codex 这个 prompt：

为定时工作创建一个可复用的循环 skill。

当我给它一个需求时，先判断：每次运行是否可以重新开始，还是下一次检查需要当前线程的上下文。

如果每次运行可以重新开始，帮我创建一个 Scheduled Task。
如果下一次检查需要当前线程，帮我创建一个 Scheduled Message。

从对话中尽可能推断。只问那些真正会改变工作流的关键问题：
- Codex 每次应该做什么？
- 多久运行一次？
- 什么样的变化值得报告？
- 什么时候应该停止？
- 什么时候需要问我？

然后用一个简短、持久、在后续运行时仍然有意义的 prompt 创建定时工作流。

5.1.2. 简单开始

最好的自动化不是从一个复杂的系统开始的。它们始于一个简单的问题：下一次运行需要一张白纸，还是同一个线程？

[!success] 核心要点

• 两种模式：Scheduled Tasks 每次新建线程（从零开始）；Scheduled Messages 复用同一线程（延续上下文）
• 决策问题：明天再跑一次，它需要之前的对话吗？——不需要用 Task，需要则用 Message
• 本质：调度本身不是主要决策，上下文放在哪里才是
• 实践：做一个循环 skill，让 Codex 自动判断需求属于哪种模式，并生成对应的定时工作流