为什么定时任务会重新开始
独立运行刻意设计为新对话
定时任务的默认形态是相互独立的。每次运行都会全新开启，执行保存的提示词中描述的工作，并报告到 Scheduled（已计划）中，OpenAI 将其描述为一个收件箱：“带有发现的定时任务运行会显示在那里，未读指示器会显示何时有运行需要您的注意。”
对于任何幂等的工作——周报、夜间检查、月度总结——这都是一个很好的设计。但这也是分类任务会自我重复的原因。除了那个供您阅读而非供任务阅读的收件箱之外，文档中没有任何地方描述了可以将一次运行的结论保留给下一次运行使用的存储空间。
这里有必要精确说明，因为这是人们容易过度推断的地方。文档指出的是，每个独立运行都会启动一个新对话。它们没有指出任何关于运行会继承上一次运行结果的内容，也没有任何官方记录的、用于存放任务自身工作笔记的跨运行存储。如果您需要连续性，您必须自己进行安排——这就是本文其余部分要讨论的内容。
两种模式是不同的产品，而默认的是会遗忘的那种
还有第二种模式，它是解决累积性工作的直接方法：“当您希望 ChatGPT 按计划返回该对话时，请在现有对话中安排任务。定时任务将使用该对话现有的上下文，而不是每次都从新的提示词开始。”
文档明确说明了何时使用哪种模式。对于“应该继续使用相同上下文”的持续工作，请在对话内进行定时。当“每次运行都应该独立，或者发现应该作为独立运行显示在 Scheduled 中”时，请使用独立模式。其对话内使用场景列表包括“检查长期运行的操作直至其完成”、“提醒 ChatGPT 以固定节奏继续审查循环”以及“在不丢失上下文的情况下继续进行中的研究或分类对话”。
大多数人从未见过这个选择，因为从提示词栏创建任务会生成独立类型的任务。
事件触发器让界限变得更清晰，而不是更模糊
8 月 25 日新增的功能允许任务“在支持的 Gmail、Slack 或 GitHub 事件发生时”运行。分工非常明确：“触发器决定任务何时运行；保存的提示词决定每次运行做什么。”
这句话中没有任何内容是累积的。触发器触发，保存的提示词运行。两个限制强化了这一点：“一个任务可以使用多个事件触发器，但不能将事件触发器与基于时间的计划相结合”，以及“当多个匹配的事件几乎同时到达时， ChatGPT 可能会在一次运行中合并它们。”事件触发的任务也仅限网页端和移动端——“它们在 ChatGPT 桌面应用、Codex CLI 或 IDE 扩展中不可用。”
因此，响应性最强的定时任务版本也是最无状态的版本。这不是缺陷，这正是触发器的本质。
运行发生在哪里决定了它能看到什么
三个界面，三种触达范围。在网页端，“网页任务可以使用上传的上下文和连接的工具，但它们不能直接在您电脑上的文件夹中工作。”在桌面应用中，任务“可以与本地项目一起工作，并在项目目录或隔离的工作树（worktree）中运行”，但有两个硬性条件：“当定时任务需要本地文件时，请保持电脑开启且应用处于运行状态”，以及“当任务计划运行时，所选项目必须在磁盘上仍然可用。”CLI 和 IDE 扩展则完全没有定时任务管理界面。
一个每天早上读取您仓库的任务和一个每天早上读取您收件箱的任务不是同一种任务，它们会以不同的方式失败。
人们的尝试
将上周的发现粘贴到提示词中。 这能管用一周。然后提示词就变成了一个变更日志，每次修改都会变长，最后没人能分清哪一行是指令，哪一行是笔记。
在对话内定时且从不清理。 这是正确的模式，但缺乏维护。每次运行都会累积线程，最终有用的状态会被埋在二十个日常的“无内容可报告”的轮次之下。
缩短间隔时间。 对话内任务支持以分钟为单位的间隔，用于“主动跟进循环”，人们很容易将频率误认为是连续性的替代品。其实不然，这只会把额度浪费在无事可做的运行上。
假设项目（Project）保存了任务状态。 项目将相关的对话、文件和源资料保存在一起。这是一种组织方式，而不是任务写入数据的地方——关于项目共享和不共享什么，已在 why ChatGPT projects don't share memory 中进行了介绍。
得出定时任务无法进行累积性工作的结论。 它们其实可以。这种模式是存在的，文档也提到了它，缺失的只是一个可供读取的持久化存储地方——而不是缺失了功能。
解决方案：决定每次运行应该继承什么，然后给它一个可供读取的地方
首先对任务进行分类，因为选择模式是一个真正的决定，选错模式是大部分问题的根源。
如果每次运行确实是独立的——报告、检查、总结——请保持其独立性，让 Scheduled（已计划）作为您的收件箱。如果运行需要知道上一次发生了什么，请在对话内定时，并认真对待 OpenAI 关于提示词的建议：“使提示词具有持久性。它应该描述 ChatGPT 在每次定时运行时应该做什么，如何决定是否有重要内容需要报告，以及何时停止或向您请求输入。” 最后一句话是人们经常忽略的，而它正是阻止循环无休止报告的关键。
还有第二个值得使用的杠杆。文档建议将操作本身进行打包：“为了保持定时任务的可维护性以及在团队间的可共享性，请使用技能（skills）来定义操作并提供工具和上下文。当工作流不应依赖自动工具选择时，请在任务提示词中选择或调用特定技能。”技能可以在多次运行中稳定地保持流程。但它不会保存自昨天以来发生的变化。
这就剩下了模式和技能都无法涵盖的部分：累积的状态。MemoryLake 是一个独立于任何单一工具之外的记忆层，因此全新的运行在决定什么是新内容之前，可以有一些可供读取的信息。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建一个 API 密钥。一个凭证即可跨您连接的各种工具使用。
步骤 2：上传您的第一批记忆
简短的条目，每条记录一个断言。对于循环任务，有用的条目是那些能让“这是新内容吗？”变得可解答的条目：
已经处理过的内容。 您分类过的 issue、您忽略的警报及其原因、已经回答过的客户问题。这就是阻止第四天重复报告的条目。
任务应该遵守的常规决策。 哪些标签代表忽略、哪些仓库已被冻结、谁负责哪项服务。如果不是这样，这些事实在您每次修改提示词时都需要重新粘贴进去。
阈值和定义。 什么算作紧急，什么算作噪音。除非您的判断被写在某个地方，否则运行无法应用您的判断。
外部指针。 仪表板、操作手册（runbook）、追踪器——这些是任务无法在收件箱或文件夹中找到的东西。
步骤 3：连接您的 AI 和智能体
连接您使用的工具。MemoryLake 可以通过 MCP 和 API 访问，且 ChatGPT 支持连接的工具，因此定时任务在每次运行时都可以咨询相同的记忆。Codex、Claude Code、Cursor 和 Cline 也能读取相同的记忆，当该任务只是人类在其他地方完成的某项工作中的一个步骤时，这一点至关重要。
三个坦诚的限制。这不会改变定时任务的运行方式——独立运行仍然会打开一个新对话，事件触发器仍然会针对每个事件触发。It is not a replacement for the in-chat mode，因为在对话内模式中，您需要的是真正的对话连续性。而且记忆是上下文，而不是强制执行：任何每次都必须为真的内容应该写在会报错的检查机制中，而不是写在智能体可能会也可能不会执行的笔记中。
这在实践中带来了什么改变
重复不再是默认行为。 运行可以在报告之前检查已经处理过的内容。
提示词不再是草稿纸。 指令保持为指令；状态存放在可以在不修改任务的情况下进行更新的地方。
事件触发的任务变得可用于实际工作流。 针对每个 pull request 评论触发的触发器仍然可以知道您的团队上周做出的决定。
您可以有目的地选择模式。 独立运行保持干净；累积运行获得持久的提示词和可供读取的地方。
循环 ChatGPT 任务的最佳实践
在编写提示词之前选择模式。 独立运行选择独立模式，任何累积性的工作选择对话内模式。文档说明了哪种是哪种；默认是独立模式。
使对话内提示词具有持久性。 每次运行要做什么、如何决定是否有内容值得报告，以及何时停止或询问。这三点都要写在提示词中。
不要用频率来代替状态。 以分钟为单位的间隔是为了主动跟进，而不是为了连续性。
预料到事件触发器会进行批处理。 多个同时到达的匹配事件“可能”会被合并到一次运行中，因此编写提示词时要考虑处理一批项目，而不是单个项目。
完成连接清单。 对于 Slack，@ChatGPT 必须存在于任务监控的每个频道中；不支持反应（reactions）、编辑、删除和私信。对于 GitHub，连接的应用需要拥有仓库的访问权限。
在调试前检查管理员权限。 在托管工作区中，访问权限由 允许事件触发的定时任务（Allow event-triggered scheduled tasks）权限控制。一个从未触发的任务可能是因为策略限制，而不是 bug。
注意桌面任务的本地条件。 机器必须开启，应用必须运行，且项目必须仍在磁盘上。工作树（Worktrees）可以使任务更改与正在进行的工作隔离开来。
将流程放在技能中，将状态放在记忆中。 它们是不同的东西——其区别请参阅 why agent skills aren't memory。
结论
重复并不是故障。独立定时任务“在每次定时运行时都会启动一个新对话”，这种独立性是一个记录在案的功能，旨在用于每次运行都应该独立的工作。当任务是累积性的而模式却不是时，麻烦就来了。
OpenAI 在同一页面中记录了替代方案：在现有对话中定时，这样“定时任务将使用该对话现有的上下文，而不是每次都从新的提示词开始”，并配合一个持久的提示词，说明要做什么、如何判断什么值得报告以及何时停止。将流程打包为技能，以便在多次运行中保持稳定。而对于事件触发的任务——最新且最无状态的形式——请接受这样一个事实：触发器加上保存的提示词就是该机制本身所能提供的全部连续性。
剩下的就是状态：已经处理了什么、什么算作紧急、团队已经决定了什么。将这些内容保留在任务提示词之外，放在一个全新运行可以读取的层中，第四次运行就不会再重复第二次的内容。这一论点的通用版本（适用于在结构上运行是无状态的智能体）请参阅 why OpenClaw forgets previous runs 和 memory for stateless MCP servers。