🧠 AI 追番总结 · 记忆功能
「AI 追番总结」任务默认无状态：每次执行时 LLM 只看到本次时间范围内的观影记录， 不会参考上一次总结的内容。设置记忆条数（memory_limit > 0）后，系统会把每次总结的 摘要保存到本地，并在后续执行时注入提示词，让总结更连贯、可引用历史结论。
使用场景
- 上下文延续：今天总结时会看到最近的摘要结论，例如上次说"芙莉莲追到 S1E10"， 这次就能接着自然过渡而不重复介绍。
- 避免重复：开启记忆后，已被历史总结覆盖的观看记录不再送入 LLM——程序按集级 消费标记精确识别已消费记录，其信息由摘要承继，总结只覆盖新记录，天然不重复。
- 同剧回忆（
related_limit > 0时）：今天的剧名自动反查历史总结（含已归档的冷层 记录），注入时冠以[同剧历史]标记，即使很久没看也能接上下文。 - 记忆生命周期：改名任务 → 历史记忆一并迁移；删除任务 → 记忆、归档与消费标记 在同一事务内清空，不留孤儿数据。
如何开启
「配置管理 → AI 追番总结」任务卡片中（对应 config.ini 的 [summary-*] 段）：
- 记忆条数（
memory_limit，默认0，区间0–1000）：0为关闭记忆特性 （不保存摘要、不注入最近 N 条摘要、不排除已消费记录）；大于0保存/注入最近 N 条摘要。 - 同剧关联条数（
related_limit，默认0，区间0–1000）：0为关闭；大于0按日期倒序注入最近 N 条同剧历史摘要（跨窗口回忆，含已归档冷层）。
同剧关联独立性：
related_limit独立于memory_limit生效——即使memory_limit=0， 只要related_limit>0仍会单独开启同剧关联注入。但同剧关联只能召回本任务曾写入过的 历史摘要（按剧名反查）：若该任务从未开启过记忆（从未写入过摘要），则无内容可注入。
注入方式：历史上下文以
## 历史执行上下文小节自动前置拼接在你的自定义 提示词之前（实现为单个 system 消息内追加，不会产生第二条 system 消息）。无需 修改自定义提示词。注入量 = (min(累计条数, memory_limit) + related_limit) 条摘要， 每条约 50–100 字（LLM 完整输出原文、不加截断），token 成本随条数线性增长。 可通过GET /api/summary/jobs/{name}/memory-stats查看当前累计条数与按配置的估算注入量（界面卡片展示规划中）。
每任务独立：记忆按任务隔离，没有全局开关。多用户场景下记忆为任务级混合 （与任务级混合总结一致）；如需按用户隔离，请为每个用户单独建任务。
预览与定时执行的差异
任务卡片上的**预览（测试按钮）与定时实跑（cron 触发）**走的是两条不同路径，行为有差异：
| 行为 | 预览（测试按钮） | 定时实跑 |
|---|---|---|
| 增量窗口 | 不启用，固定按 lookback_days 回溯 | 记忆开启且有历史时，起点 = 上次总结点 |
| 注入历史上下文 | 不注入 | 按 memory_limit / related_limit 注入 |
| 消费排除 | 不排除 | 排除本任务已消费记录 |
| 写入记忆 | 不写入 | 记忆开启时写入摘要并标记消费 |
因此，记忆开启（memory_limit>0）时预览会把已消费记录也一并展示（预览不查询消费 标记、也不做排除），而定时实跑会剔除本任务已消费的记录、只总结新增部分。预览结果仅供 参考，实跑实际送入 LLM 的记录可能更少。
记忆存在哪里
- 本地 SQLite（
data/sync_records.db的agent_working_memory表，超量自动归档到agent_working_memory_archive）。 - 不会发送到站内信/外部通知渠道，仅用于提示词注入。
- 摘要由 LLM 生成（一行短摘要 + 本次全文留档，完整输出不截断）。摘要提取失败 时仍写入一条「消费占位行」：无摘要、不参与提示词注入、不计入记忆统计，主总结全文 照常留档；该次执行同时被打上消费标记，因此下次不会重复总结这批记录（仅记 warning 日志，不单独发通知）。
出错时的行为
总结过程任何阶段失败都会通知你（唯一例外：摘要提取失败不通知，见下方说明）， 并按阶段区分提示文案，方便定位问题环节：
| 失败阶段 | 通知类型 | 提示重点 |
|---|---|---|
| 查询/构建（query） | summary_job_failed | 请检查任务配置 |
| LLM 调用（chat） | summary_llm_failed | 请检查 API 地址和密钥 |
| 记忆写入（store） | summary_job_failed | 记忆写入失败，下次将重新总结 |
| 通知投递（notify） | 不二次通知 | 投递层问题走通知重试/告警兜底 |
注意区分两种失败：摘要提取失败（LLM 生成一句话摘要失败）不会触发失败 通知——只要主总结成功就照常发成功通知，同时写入消费占位行、标记已消费，下次不重复 总结（仅记 warning 日志）；只有记忆写库失败（store 阶段 DB 异常）才发失败通知， 且本次未记录，下次将重新总结。
注意事项
memory_limit=0= 不注入最近 N 条摘要、也不写入（读写一致），重新设置后视为从未总结过 （消费标记不追踪关闭期间的观看记录）。- 删除任务会彻底清空该任务的记忆（热层、归档与消费标记在同一事务内清理）； 想保留历史再重建，可先给任务改个名再新建。
- 空记忆行为：开启记忆但尚无任何历史摘要时（如首次执行），任务正常生成总结， 不会注入空白的历史段落。
- 记忆的边界：注入的只是每次执行的一句话摘要（约 50–100 字，LLM 完整输出不截断）， 不含全文留档；历史记忆按任务最近 1000 条滚动保留（超出自动归档到本地冷层， 冷层参与同剧关联、不参与最近条数注入）。
- 同剧关联的精度：按记录的 Bangumi 匹配标题（
bgm_title）反查历史总结——匹配链路 固定时写法一致，命中精确；从未匹配过bgm_title的条目无关联锚点。