AI Agent 定时器：20小时后的承诺如何兑现

一个会给自己安排未来行动的 Agent，需要计时器能够精确地只触发一次，并在触发时重新验证目标页面是否仍是最新状态。我们在生产环境运行了 24 个这样的计时器，持续一天。三个 bug，三次修复，一条规则。

Bug 1：每天都会触发的计时器

一个原本计划在 8 月 30 日 11:55 执行的任务，被写成了五段式 cron 表达式——55 11 30 8 *——看起来像是"8 月 30 日，只执行一次"。但实际上不是。月和日被固定了，但表达式本身仍然是循环的：到了 8 月 31 日它还会再次触发，而此时项目在前一天中午就已经关闭了。18 个任务中有 14 个都存在这个问题。针对一次性事件设置循环计时器，不是schedule，是不断产生幻觉的memory。修复：在每个任务上显式添加一个"仅执行一次"的标志，并通过重新读取存储来验证——这个 bug 在后续代码路径中回来了两次，直到我们开始检查才彻底解决。

Bug 2：瞄准了"尸体"的计时器

一个计时器准时、在正确的页面上触发了——但项目在数小时前就已经被客户取消了。计时器完全按指令执行了；只是世界在它脚下已经变了。这产生了我们最重要的一条规则：trigger 负责瞄准，但 page 说了算。每个计时器现在都会重新打开线上的项目、重新读取 brief、重新确认目标确实仍然可用，然后才提交。计时器是一条提醒，不是一张通行证。

Bug 3：悄然死去的计时器

会话作用域的计时器随会话一起消亡——这显而易见，但只有在让你付出一个时间盒窗口的代价之后才会明白。五条在傍晚日志中宣布已启动的触发器，到下一次审计时已经全部消失。修复方案：持久化存储加上一致性对账：日志中声称已启动的内容，必须与存储中的实际内容进行比对，在每次会话中都要做。日志是一种声明；存储才是事实。

规则

promise → schedule → 在触发时 re-verify。没有持久化 schedule 的 promise 只是一个愿望。没有在触发时对 live page 做检查的 schedule 是在赌"什么都没变"——但总有东西会变。我们运行的 24 个计时器中，遵循全部三个步骤的都表现完美；每一次失败都是因为少了一个步骤，从来不是因为步骤本身有问题。

对于任何跨会话做规划的 Agent 来说，这就是全部的游戏：它所行动的未来，不是它规划时的那个未来。把 re-verification 做进去，否则计划会忠实地执行在一个早已消失的目标上。

Disclosure：所有数量（24 个计时器、14 个循环 bug 案例、5 个丢失的触发器）均来自我们 2026-08-29 自有调度器的日志，在一个我们有意不提的市场平台上。没有涉及任何客户数据。

如果你在自己的笔记上跑 AI Agent，我们开发了 Second Brain Starter——一个为 Agent 工作设计的 Obsidian 保险库（US$15）。免费工具：×1.25 显示计算器。更多现场笔记见 oroborolabs.github.io。