feat(calendar): 日历后端 —— 事件/提醒/重复规则 + iCal + 多收件人

三层分离:事件是日历实体,提醒是触发器,邮件是投递通道。
`from_name = "calendar"` 刻意既非人类名也非 Agent 名 —— 用创建者的名字
会让 Agent 以为人在实时找它,而人此刻可能在睡觉,模型据此判断
「要不要马上追问」,来源写错会让它问一个不在线的人。

日历提醒不扣会话预算:预算的语义是「这件事值得模型自主发多少封信」,
而提醒是人预先设定的定时任务,不是模型的自主行为。

**多收件人两种投递模式,都要**:
- separate(默认)= 各发一封、落各自会话、互相看不到
- together        = 首个为主收件人、其余进 cc_list、共享一条线索

「让三个 Agent 各自独立汇报」与「让 pi 主办、dsh 知情」是完全不同的任务
形态。默认 separate 因为失败模式更轻:together 用错会让本该独立判断的
Agent 互相看到回复而趋同,那种上下文污染事后无法分离。

抄送方也推 SSE。漏了这步的后果很隐蔽:cc_list 里有他们、查收件箱看得见,
但没有任何事件推给他们 —— 插件不会唤起会话,Agent 到下次补拉才发现。

recipients 存**原始地址串**而非结构化:session 位的 new/别名三态该在
触发那一刻解析,存结构化会让「.new」这种一次性语义在建事件时就被固化,
而重复事件每次触发都该重新决定落到哪条会话。

---

修掉的七个真问题:

**1. 默认提醒模板把时间烤成字面值。**
原来 Sprintf 出含字面时间的正文存进 reminder_text。对重复事件是错的:
AdvanceRecurrence 只推进 event_time,模板不动 —— 「每天 9 点」的提醒
从第二天起永远写着第一天的日期,且不报任何错。改为存变量形式。

**2. `{time}` 渲染成 UTC。**
DSN 带 _timezone=UTC,读回的 EventTime 是 UTC。直接 Format 会把人在
+0800 输入的 14:30 写成 06:30,而前端预览用本地时间 —— 两边差 8 小时
且都不报错。

**3. 同一提醒每 tick 重发一次(生产实测 4 封)。**
DueEvents 有 60 秒 lookahead(周期 30 秒,不提前看会迟到)。去重判据
原本是 `last_fired_at < event_time` —— 触发时刻本来就早于落在窗口内的
event_time,条件恒真。实测一条 12:53:17 的事件在 12:52:30 / 12:53:00 /
12:53:06 / 12:53:36 各发一封。新增 fired_for 列记录**已触发的
occurrence**,判据改为 `fired_for <> event_time`。

**4. 过期重复事件刷屏。**
AdvanceRecurrence 只推一步:一条 100 天前设的每日事件每轮都判定过期 →
发一封 → 只前进一天 → 下轮又过期。实测 30 轮触发 30 次,而周期是
30 秒。改成 advanceToFuture 一路推到越过当前时刻;跳过的 occurrence
不补发(三个月前那次站会提醒现在发出去毫无意义,只会淹掉该看的那封)。
带 maxAdvanceSteps=4000 上限:农历路径依赖外部库,没有上限就是个死循环
goroutine,而它跑在调度器里 —— 整个提醒系统会一起卡住。

**5. 越过 recurrence_end 不置 cancelled。**
留在 active 会变僵尸事件:DueEvents 每轮都捞到它(event_time 在过去),
但 fired_for 已等于 event_time 所以又不触发。

**6. 附件从未落盘。**
`data := make([]byte, header.Size); file.Read(data)` 两处错:单次 Read
不保证填满缓冲(大文件必然短读,sha256 算的是半截内容),而且文件内容
压根没写进 blob 存储。结果是附件「上传成功」、清单里看得见、
发提醒时取不到任何字节。改走 Blobs.Put。

**7. iCal TRIGGER 往返是断的。**
导出写 `-P15M`、导入找 `-PT%dM`,自己导出的文件自己都读不回来。更糟的是
`-P15M` 在任何合规客户端里都是「提前 **15 个月**」—— iCal duration 的 M
在 T 之前是月、之后才是分钟。而且用 maxInt(RemindBefore,15) 兜底,把用户
明确设的「到点提醒」(0) 悄悄改成提前 15 分钟。

---

其他修正:
- **PG schema 整块缺失日历两张表** —— DATABASE_URL 非空时所有 /calendar/*
  在 relation does not exist 上 500,而 SQLite 下一切正常,问题只在切外部库
  时才暴露
- DeleteCalendarAttachment 曾返回 501,让人「删整个事件来清附件」
- 导出忽略 from/to;导入只接受 multipart(命令行调用者收到含糊的
  「Missing file field」)
- 上传附件不校验事件存在 —— 会攒孤儿记录,而 ON DELETE CASCADE 清不掉
  它们(SQLite 的 foreign_keys 默认关)
- 农历规则 RRULE 表达不了,走 X-AGENTMAIL-RECURRENCE 扩展属性 + 公历近似
  兜底。**RRULE 分支不能覆盖已读到的农历值** —— X- 出现在 RRULE 之前时
  无条件赋值会把 lunar_monthly 打回 monthly,往返一圈农历规则悄悄退化
- 抽出 calendarCols 常量:原先四处手抄同一串列名,加一列漏改任何一处
  不会编译报错,只会运行时列错位(ListSessionsFor 上真的发生过)

测试:repo 20+ 例(到期判定/幂等/lookahead 不重发/过期不刷屏/农历推进/
多收件人/兜底链)、handler 20 例 iCal、scheduler 7 例模板渲染。
生产端到端验证并清理了数据。
This commit is contained in:
2026-09-04 06:28:03 +08:00
parent 4d211c84d6
commit 069bf03ae2
10 changed files with 3495 additions and 0 deletions

View File

@ -336,3 +336,94 @@ CREATE TABLE IF NOT EXISTS agent_platform_sessions (
CREATE INDEX IF NOT EXISTS idx_platform_sessions_ws
ON agent_platform_sessions(agent_name, workspace);
-- ─── 日历事件 ───
--
-- Outlook 风格:事件 → 提醒 → 邮件通知 Agent。
-- 事件本身是日历实体,提醒是定时触发器,邮件是投递通道。
-- 三者分离:同一条事件可以有多个提醒(提前提醒 + 当天提醒),
-- 同一条提醒只触发一封邮件(幂等由 fired_at 控制)。
CREATE TABLE IF NOT EXISTS calendar_events (
event_id TEXT PRIMARY KEY DEFAULT (gen_random_uuid()),
-- 事件标题UI 显示 + 邮件主题前缀)
title TEXT NOT NULL,
-- 事件描述UI 显示,可含 markdown
description TEXT NOT NULL DEFAULT '',
-- 用户可编辑的提醒消息模板。支持变量:{title} {time} {description}
reminder_text TEXT NOT NULL DEFAULT '',
-- 通知目标
agent_name TEXT NOT NULL DEFAULT '',
-- 收件人三维地址(空 = 用 agent_name 默认地址)
to_address TEXT NOT NULL DEFAULT '',
-- 时间安排
event_time DATETIME NOT NULL,
-- 提前多少分钟提醒0 = 事件触发时)
remind_before INTEGER NOT NULL DEFAULT 0,
-- 重复规则none / daily / weekly / monthly
-- lunar_monthly每农历月同一日/ lunar_yearly每农历年同月同日
--
-- 农历规则必须经 internal/lunar 推进,不能加固定天数 ——
-- 农历月 29~30 天不定、农历年 353~385 天(闰年多一整月),
-- 近似推进一年能偏半个月。
recurrence TEXT NOT NULL DEFAULT 'none',
-- 重复结束(空 = 永久)
recurrence_end DATETIME,
-- 收件人列表JSON 数组,每项是完整三维地址串)。
--
-- 存原始串而不是结构化地址session 位的 new/别名三态该在**触发那一刻**
-- 解析。存结构化的话「.new」这种一次性语义在建事件时就被固化
-- 而重复事件每次触发都该重新决定落到哪条会话。
recipients TEXT NOT NULL DEFAULT '[]',
-- 多收件人的投递方式:
-- separate默认= 各发一封、落各自会话、互不可见
-- together = 首个为主收件人,其余进 cc_list、共享一条线索
--
-- 默认 separate 因为它的失败模式更轻together 用错会让本该独立判断的
-- Agent 互相看到回复而趋同,那种污染事后无法分离。
delivery_mode TEXT NOT NULL DEFAULT 'separate',
-- 状态active / paused / cancelled
status TEXT NOT NULL DEFAULT 'active',
-- 最后一次触发的墙上时钟(给 UI 显示「上次触发于」)
last_fired_at DATETIME,
-- 已触发的那个 occurrence值 = 当时的 event_time。
--
-- 去重不能拿 last_fired_at 跟 event_time 比大小DueEvents 有 60 秒
-- lookahead落在窗口内的**未来**事件被触发后 last_fired_at(now) 仍然
-- 小于 event_time于是每个 tick 重发一次,直到 event_time 真正过去。
-- 生产实测:一条 12:53:17 的事件在 12:52:30 / 12:53:00 / 12:53:06 /
-- 12:53:36 发了 4 封相同提醒。
-- 按 occurrence 比相等则精确AdvanceRecurrence 改了 event_time 就再触发,
-- 没改就永不重发。
fired_for DATETIME,
created_at DATETIME DEFAULT (strftime('%Y-%m-%d %H:%M:%f','now')),
updated_at DATETIME DEFAULT (strftime('%Y-%m-%d %H:%M:%f','now')),
-- 创建者(人类用户)
created_by TEXT NOT NULL DEFAULT ''
);
-- 调度器每分钟扫描 active 事件,按 event_time + remind_before 排序取下一个
CREATE INDEX IF NOT EXISTS idx_calendar_next_fire
ON calendar_events(status, event_time) WHERE status = 'active';
-- 按时间范围查(日历视图)
CREATE INDEX IF NOT EXISTS idx_calendar_time_range
ON calendar_events(event_time, status);
-- 附件:事件触发时随提醒邮件一起发出
CREATE TABLE IF NOT EXISTS calendar_attachments (
attachment_id TEXT PRIMARY KEY DEFAULT (gen_random_uuid()),
event_id TEXT NOT NULL REFERENCES calendar_events(event_id) ON DELETE CASCADE,
filename TEXT NOT NULL,
sha256 TEXT NOT NULL DEFAULT '',
size_bytes INTEGER NOT NULL DEFAULT 0,
created_at DATETIME DEFAULT (strftime('%Y-%m-%d %H:%M:%f','now'))
);
CREATE INDEX IF NOT EXISTS idx_calendar_att_event
ON calendar_attachments(event_id);