Schedule zh

定时提醒

上游持久化提醒系统在 Edge 中的适配状态。

上游参考：Schedule

上游提供了什么

定时提醒子系统提供在活跃会话中作为正常对话轮次投递的持久提醒。三种提醒类型：

• After — 延迟一次性提醒（如"30 分钟后提醒我"）
• At — 绝对时间一次性提醒，支持时区感知解析（RFC 3339 或本地日历输入，处理 DST 间隔/重叠）
• Every — 固定频率循环提醒（最小 5 分钟间隔）

所有提醒都是事件溯源的：schedule/change 事件（create、delete、dispatch）持久化在 session 日志中。进程内 owner 从持久化状态管理定时器。投递仅限 session 本地——没有外部通知渠道。一次性提醒优先；多个到期的循环提醒合并为一个 follow-up 轮次。

当前 Edge 状态

**未实现。**没有安装任何 schedule 相关包。上游 dsh-schedule 不在 Edge 的依赖中。

Cloudflare 支持能力

核心构建块已经存在于 Edge 中：Durable Object alarm。Edge 目前使用 ctx.storage.setAlarm() 管理 WebSocket 下行链路过期。同样的机制可以驱动定时提醒。

支持能力	Plan	可行性	备注
DO alarm	免费	高	Edge 已用于下行链路过期。每个 DO 一个 alarm——需要多路复用（最早优先调度，每次触发后重新设置）。
Cron Triggers	免费	中	全局 Worker 级 cron，非按 session。可以轮询 DO 检查到期提醒，但增加延迟和复杂度。
Queues	付费	低	带延迟投递的消息队列。对 session 本地提醒来说过度设计。

集成路径

最自然的方式：安装上游 Schedule 服务，将其进程内定时器替换为 DO alarm 适配器。上游服务已经处理了事件溯源、时区解析和 DST——只需替换定时器后端。DO alarm 在最早待处理提醒时间触发，handler 通过 agent.followup() 分发到期提醒，然后重新设置下一个。

关键约束：DO 同时只支持一个 alarm。适配器必须维护一个待处理提醒的排序列表，始终将 alarm 设置为最早的。这和 Edge 已经用于下行链路过期的最早优先模式相同。

架构总结

组件	状态	支持能力
Schedule 服务（事件溯源、时区、类型）	🚫 未安装	上游插件——可能直接复用
定时器后端	🚫 未实现	DO alarm 适配器（免费 plan）
提醒投递	🚫 未实现	agent.followup()——与 GoalRoundDriver 相同模式

TODO

(#110) **评估上游 Schedule 服务安装。**检查 inject 要求。该服务需要定时器后端——评估 DO alarm 适配器是否能满足上游接口。通过 agent.followup() 投递提醒，与 GoalRoundDriver 使用相同模式。所有功能可在免费 plan 上工作。