推荐这篇文章，Jason Liu 用两句话把 Codex 的定时任务本质讲清了。大多数自动化语言比实际要完成的任务复杂得多，而他把一切归结为一个词：上下文。 Codex 中两种根本不同的定时工作 大多数自动化语言比它要完成的任务更复杂。 你想让 Codex 之后做某件事，或者持续检查某件事直到它改变。这听起来像一个功能。实际上是两种完全不同种类的工作，区别很简单： • Scheduled Task 每次运行创建一个新线程。 • Scheduled Message 每次运行回到同一个已存在的线程。 这就是整个模型。 当每次运行都可以从零开始时，用 Scheduled Task Scheduled Task 最适合的任务是：工作不需要创建它的对话就能成立。 例如： 每天早上 9 点，总结我需要从邮件、日历和团队消息中了解的内容。 明天的总结不需要记住今天的总结。它需要相同的指令、当前的信息，以及一个报告结果的新空间。 当一个任务应该跨多个项目运行时，或者当你希望每次运行在 Triage 中单独出现时，这也很有用。每次运行都是它自己的线程。schedule 是连接它们的东西。 当下一次检查需要同一个线程时，用 Scheduled Message Scheduled Message——有时候叫线程自动化——每次运行回到同一个已存在的线程。 例如： 每 30 分钟检查这个 PR。如果有评论，处理它们并保持 CI 绿色。PR 合并后停止。 下一次检查依赖于已经完成的工作。线程知道你说的是哪个 PR、哪些评论已处理、CI 中什么失败了、自从上次检查以来什么变了。 这是正确的形状，适用于： • 轮询更新 • 检查状态变化 • 持续研究或分类 • 有明确停止条件的工作 线程是连接各次运行的东西。 决策规则是上下文 问一个问题： 如果它明天跑，是否需要之前的对话？ 如果不需要，用 Scheduled Task。给它一个持久的 prompt，让每次运行从零开始。 如果需要，用 Scheduled Message。把工作留在一个线程里，让每次检查可以建立在之前的决定和结果之上。 schedule 很重要，但它不是主要决策。主要决策是：有用的上下文应该住在哪里。 做你自己的 loop skill Jason 不想每次都记住这些设置问题，所以他建议写一个小 skill，把粗略的请求变成正确的定时工作流。 给 Codex 这个 prompt： 创建一个可复用的定时工作 loop skill。当我给它一个请求时，首先判断每次运行是可以从零开始，还是下一次检查需要当前线程的上下文。 如果每次运行可以从零开始，帮我创建一个 Scheduled Task。 如果下一次检查需要当前线程，帮我创建一个 Scheduled Message。 从对话中推断你能推断的。只问那些会实质改变工作流的缺失问题： • Codex 每次应该做什么？ • 应该多久运行一次？ • 什么变化重要到值得报告？ • 什么时候应该停止？ • 什么时候应该问我？ 然后用一个简短持久的 prompt 创建定时工作流——这个 prompt 在之后运行时仍然有意义。 最好的自动化不从一个复杂系统开始。它们从知道下一次运行是需要一块白板还是同一个线程开始。 原文：Jason Liu, "Two kinds of scheduled work in Codex", 2026-06-28 #Codex# #Automation# #AI工程#