写进 agents.md 的 Durable Object alarm 规则

要点

• 作者把 alarm 描述为持久定时器：没有请求也会唤醒对象，并按次计费。他写到似乎没有账户级硬顶，只能发告警邮件。
• 规则禁止：在 constructor 里 setAlarm；在 alarm() 的每个出口都 setAlarm；用“快过期就刷新”让一条链永远续上；间隔短于 60 秒的自我续订，除非用户明确要求并写明上限。
• 规则要求：没有剩余工作时直接 return、不再 setAlarm；续订前写清终止条件（次数、截止时间或存储里的 active 标志）；测试覆盖“无工作时 alarm 不再调度”；提交说明写明这条链如何停止。

原始来源

1. 2026-10-07

   原帖

   到 𝕏 阅读

   Viking

   @vikingmute · 𝕏 原帖

   和我之前的观点一致https://t.co/A4vwxe9f4a 不管用什么云服务一定要注意啊，Vibe Coding 别写出什么死循环了，尤其是用 Durable Objects，要不直接天价账单了，而且好像它没有价格上限，只能发告警邮件，所以要格外小心。 如果用，可以加一个 规则，同时最好改动要另外一个模型… https://t.co/lHsTeWDfJ9

   2026-10-07 02:05:08 UTC

2. 2026-10-05

   作者引用的此前帖子：他转引 yvonuk 的帖子，写到用云平台就有出现天价账单的概率，尤其是 Durable Objects；VPS 被刷最坏是机器打满、站点挂掉。

   到 𝕏 阅读

   Viking

   @vikingmute · 𝕏 原帖

   说的很中肯，虽然我是无脑 CF 吹，但是假如要做一个量大的产品的话，VPS 肯定比 serverless 贵，用云平台就会有天价账单出现的概率，尤其是用 Durable Objects，VPS 被刷，最坏是机器打满 站点挂掉。 而且 CF 的服务大多数都是 vendor locking，迁移不太方便，而且现在 VPS 配合 AI 加上类似 Coolify… https://t.co/2cNZZ58RPM

   2026-10-05 13:27:38 UTC

3. 2026-10-07

   其他用户 JasonC（@JasonC_Dev）回复：每次 setAlarm() 都按一次行写入计费；他建议预览环境先移除 Durable Object 绑定，再自行编写预算熔断。

   到 𝕏 阅读

   JasonC

   @JasonC_Dev · 𝕏 原帖

   补个更阴的：每次 setAlarm() 本身就按一次 row write 计费。 HN 上那个 8 天 $34k 的案例，炸点是 60 多个 preview 部署各自起了一套 DO，onStart 里无脑 setAlarm。 preview 环境先把 DO binding 拿掉，再自己写个预算熔断。别指望平台提醒你。

   2026-10-07 04:09:56 UTC

4. 2026-10-07

   其他用户 Kenny Chen（@KennyChinaTech）回复：应补上停用后再触发一次的测试；在 alarm() 里调用 deleteAlarm() 也不保证阻止重试。

   到 𝕏 阅读

   Kenny Chen｜AI 实战

   @KennyChinaTech · 𝕏 原帖

   停用后再触发一次的测试得补上，alarm() 里调 deleteAlarm() 也不保证阻止重试。

   2026-10-07 09:05:17 UTC