ADR-0009归档拆分实现——episodic/checkpoint archive两collection（issue #108 Q6） #156

New issue

Closed

opened 2026-08-18 02:57:27 +00:00 by KumaAgent · 1 comment

KumaAgent commented

2026-08-18 02:57:27 +00:00

Member

Parent

#108 Q6（issue #108 grill，2026-08-18 拍板：现在就实现）

What to build

ADR-0009"归档拆分"：episodic 与 checkpoint archive 拆两 collection；archive blob 分条化。这条此前
在 #101/#103 那轮被误判"作废"（把"checkpoint archive"误认成 LangGraph 的 checkpointer，实际它是
三因子语义召回的三个目标之一——画像/事件记忆/归档——跟 LangGraph 无关），复核推翻作废判定后确认应
按原计划实现。

原文（docs/adr/0009-memory-engineering.md「决策」节）：

归档拆分：episodic 与 checkpoint archive 拆两 collection；archive blob 分条化（治
整块召回）。

背景（同文件「背景」节，要修的病）：

旧实现缺陷：归档器把 ~60 条原文拼成单 blob 整块召回、episodic 与 archive 混同一 collection、
召回只按向量相似度（无 recency/importance/去重）。

Acceptance criteria

episodic 与 checkpoint archive 拆成两个独立 Qdrant collection
archive 内容按 blob 分条化写入（不再整块拼接~60条原文成单 blob），分条粒度实现期定
三因子语义召回路径（画像/事件记忆/归档，ADR-0009 07-06 更新节 + ADR-0015:39）继续把归档
当作召回目标之一，不受本次拆分影响——本票只改存储结构，不改召回逻辑本身
ADR-0009 自己 2026-07-08 更新节定的降级路径（"整批 delta 原样转存为低置信度 tentative
记录，不提炼，只保留原文"）继续是唯一会产生整块记录的地方，本票拆分不影响这条降级路径的行为
全量测试通过，补一条测试验证新写入的归档内容确实是分条化的，不是整块 blob

Not in scope

不改三因子召回的打分/排序逻辑
不改 delta 压缩降级路径的行为

## Parent #108 Q6（issue #108 grill，2026-08-18 拍板：现在就实现） ## What to build ADR-0009"归档拆分"：episodic 与 checkpoint archive 拆两 collection；archive blob 分条化。这条此前在 #101/#103 那轮被误判"作废"（把"checkpoint archive"误认成 LangGraph 的 checkpointer，实际它是三因子语义召回的三个目标之一——画像/事件记忆/归档——跟 LangGraph 无关），复核推翻作废判定后确认应按原计划实现。原文（`docs/adr/0009-memory-engineering.md`「决策」节）： > **归档拆分**：episodic 与 checkpoint archive **拆两 collection**；archive **blob 分条化**（治 > 整块召回）。背景（同文件「背景」节，要修的病）： > 旧实现缺陷：归档器把 ~60 条原文拼成单 blob 整块召回、episodic 与 archive 混同一 collection、 > 召回只按向量相似度（无 recency/importance/去重）。 ## Acceptance criteria - [ ] episodic 与 checkpoint archive 拆成两个独立 Qdrant collection - [ ] archive 内容按 blob 分条化写入（不再整块拼接~60条原文成单 blob），分条粒度实现期定 - [ ] 三因子语义召回路径（画像/事件记忆/归档，ADR-0009 07-06 更新节 + ADR-0015:39）继续把归档当作召回目标之一，不受本次拆分影响——本票只改存储结构，不改召回逻辑本身 - [ ] ADR-0009 自己 2026-07-08 更新节定的降级路径（"整批 delta 原样转存为低置信度 tentative 记录，不提炼，只保留原文"）继续是唯一会产生整块记录的地方，本票拆分不影响这条降级路径的行为 - [ ] 全量测试通过，补一条测试验证新写入的归档内容确实是分条化的，不是整块 blob ## Not in scope - 不改三因子召回的打分/排序逻辑 - 不改 delta 压缩降级路径的行为

KumaAgent added the

状态：智能体就绪

label

2026-08-18 02:58:09 +00:00

KumaAgent referenced this issue

2026-08-19 03:35:55 +00:00

Delta压缩连续失败降级——整批转存archive低置信度记录（从issue #156拆出） #165

KumaAgent commented

2026-08-19 03:38:06 +00:00

Author

Member

Understand 阶段三个独立 agent 一致核实：本票 AC 的前提与仓库实际代码不符。

arise_archive_collection（config.py:166）自代码写下第一天起（首个引入提交 8f32347，2026-07-08，原话 "Archive collection is name-only... there's no spec yet for what a 'checkpoint archive' consolidation job would produce, and none of the ACs require one"）就只是占位名字，从未被创建（ensure_vector_schema 只建 episodic/skill/learned_sticker 三个 collection）、写入、召回过——不是"episodic 与 archive 混同一 collection 需要拆分"，而是"archive 这条存储路径要从零建"。ADR-0009"背景"节描述的整块 blob 缺陷指的是立项前研究对照的旧 dxkuma 实现，不是本仓库自己的历史状态。

更关键的是 AC 第四条依赖的数据来源：ADR-0009「2026-07-08 更新」节设计的降级路径（连续失败→整批 delta 原样转存为低置信度 tentative 记录）,被 ADR-0009 自己「2026-07-30，issue #94」更新节明写"没有实现"（判定"连续"需要跨重启存活的失败计数，"属独立决定"），至今（issue #94 之后 #116/#125/#126/#127/#134/#137/#146 等提交）也没有任何一次触碰这个分支。即使建好 archive collection，目前也没有任何代码会产生内容写进去。

已与用户确认：类比 #154/#163 的拆分模式——

本票（#156）范围收窄为：只建 archive 存储结构——collection 创建（接入 ensure_vector_schema）+ 分条化写入 API（逐条 delta 原文对应一个 archive 记录，不拼成 blob）+ 存储层对称读 API。不接入三因子召回的打分/排序逻辑（与 AC 原有的"Not in scope"字面一致）——在没有真实产出方之前接召回是没有产出方可验证的死代码，且 AC 自己的 Not in scope 也明确排除了改动召回打分/排序逻辑。
产出方（连续失败→整批转存 tentative 记录的降级路径）拆到新票 #165（Delta压缩连续失败降级——整批转存archive低置信度记录），包含新增跨重启失败计数机制，以及"是否要把 archive 接入三因子召回"这个评估——因为只有 #165 落地后 archive 才第一次有真实数据，届时判断"接不接召回"才有意义。

AC 第三条（"三因子召回继续把归档当目标之一，不受本次拆分影响"）在当前范围下不适用——不是"维持不变"，而是这个能力目前完全不存在，接入召回的时机推迟到 #165（或其后续）。AC 第四条（"降级路径继续是唯一会产生整块记录的地方"）同理不适用于本票——这条降级路径本身就是 #165 的交付物，不是本票要"维持不变"的既有行为。

Understand 阶段三个独立 agent 一致核实：本票 AC 的前提与仓库实际代码不符。 `arise_archive_collection`（`config.py:166`）自代码写下第一天起（首个引入提交 `8f32347`，2026-07-08，原话 "Archive collection is name-only... there's no spec yet for what a 'checkpoint archive' consolidation job would produce, and none of the ACs require one"）就只是占位名字，从未被创建（`ensure_vector_schema` 只建 episodic/skill/learned_sticker 三个 collection）、写入、召回过——不是"episodic 与 archive 混同一 collection 需要拆分"，而是"archive 这条存储路径要从零建"。ADR-0009"背景"节描述的整块 blob 缺陷指的是立项前研究对照的旧 dxkuma 实现，不是本仓库自己的历史状态。更关键的是 AC 第四条依赖的数据来源：ADR-0009「2026-07-08 更新」节设计的降级路径（连续失败→整批 delta 原样转存为低置信度 tentative 记录）,被 ADR-0009 自己「2026-07-30，issue #94」更新节明写"没有实现"（判定"连续"需要跨重启存活的失败计数，"属独立决定"），至今（issue #94 之后 #116/#125/#126/#127/#134/#137/#146 等提交）也没有任何一次触碰这个分支。即使建好 archive collection，目前也没有任何代码会产生内容写进去。已与用户确认：类比 #154/#163 的拆分模式—— - **本票（#156）范围收窄为：只建 archive 存储结构**——collection 创建（接入 `ensure_vector_schema`）+ 分条化写入 API（逐条 delta 原文对应一个 archive 记录，不拼成 blob）+ 存储层对称读 API。**不接入三因子召回的打分/排序逻辑**（与 AC 原有的"Not in scope"字面一致）——在没有真实产出方之前接召回是没有产出方可验证的死代码，且 AC 自己的 Not in scope 也明确排除了改动召回打分/排序逻辑。 - **产出方（连续失败→整批转存 tentative 记录的降级路径）拆到新票 #165**（Delta压缩连续失败降级——整批转存archive低置信度记录），包含新增跨重启失败计数机制，以及"是否要把 archive 接入三因子召回"这个评估——因为只有 #165 落地后 archive 才第一次有真实数据，届时判断"接不接召回"才有意义。 AC 第三条（"三因子召回继续把归档当目标之一，不受本次拆分影响"）在当前范围下不适用——不是"维持不变"，而是这个能力目前完全不存在，接入召回的时机推迟到 #165（或其后续）。AC 第四条（"降级路径继续是唯一会产生整块记录的地方"）同理不适用于本票——这条降级路径本身就是 #165 的交付物，不是本票要"维持不变"的既有行为。

KumaAgent referenced this issue from a pull request that will close it,

2026-08-19 05:48:58 +00:00

归档存储结构补齐：collection+分条化写入/读取API #166