ProjectKuma/arise
2
0
Fork 0
Code Issues 18 Pull requests 1 Projects Releases Packages Wiki Activity

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

New issue
Closed
opened 2026-08-19 03:35:09 +00:00 by KumaAgent · 0 comments
KumaAgent commented 2026-08-19 03:35:09 +00:00
Member
Copy link

Parent

#156——本票是从 #156 拆出的"archive 内容产出方"部分。

What to build

issue #156 实现期 Understand 阶段三个独立 agent 一致核实：arise_archive_collection
（config.py:166）自代码写下第一天起就只是占位名字（首个引入提交 8f32347 原话："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"），从未被创建/写入/召回。#156 已把
"存储结构"（collection 创建 + 分条化写入 API + 存储层读 API）单独落地，但没有任何代码路径
会产生内容写进这个 collection——ADR-0009「更新（2026-07-08 第三方项目对照 grill）」节设计的
降级路径（"Delta Buffer 压缩失败自愈降级……连续失败时整批 delta 原样转存为低置信度 tentative
记录（不提炼，只保留原文）+ 标记该 chat 待重试"）就是 archive 数据唯一说得通的来源，但
ADR-0009 自己「更新（2026-07-30，issue #94 实现期）」节明写"这一档没有实现"——判定"连续"
需要一个跨重启存活的失败计数（新列/新表 + 一次 schema 变更），"属独立决定"，至今
（issue #94 之后 #116/#125/#126/#127/#134/#137/#146 等提交）也没有任何一次触碰这个分支。

本票负责补上这条产出方：run_delta_compression_cycle（delta.py:823-965）压缩 LLM 调用
连续失败达到阈值时，触发"整批当前 delta 原样转存为低置信度记录"，调用 #156 落地的
archive 分条化写入 API（不提炼、只保留原文，逐条对应原始 delta 条目，不是拼成一个 blob）。

Acceptance criteria

  • 新增跨重启存活的连续失败计数机制（Postgres 新列/新表，一次 schema 变更）——只统计
    "连续"失败，中间只要有一次成功压缩就归零（ADR-0009 原文措辞"连续失败"）
  • 失败计数达到阈值 N 时，触发整批转存：调用 #156 的 archive 分条化写入 API，逐条原始
    delta 条目对应一个 archive 记录，不合并成单条 blob
  • 阈值 N 的具体数字按 ADR-0011 阈值三层分类标定（静态 config，不是硬编码常量）
  • 转存后该 chat 的连续失败计数归零、Delta 缓冲清空（不是"写回 Delta 缓冲"那条既有降级档
    ——issue #94 落地的"原样写回"是给未达到阈值的失败次数用的，两档并存、不冲突，阈值内重试、
    阈值外转存）
  • 评估是否要把 archive 接入三因子召回（#156 故意没做——在本票落地前 archive 永远没有真实
    数据，接召回是没有产出方可验证的死代码；本票落地后 archive 第一次有真实内容，是评估"要不要
    接召回"的合适时机，但接不接召回本身可以是本票的产出也可以是再拆一张新票，实现期判断）
  • 补测试：连续失败计数机制本身（跨重启存活、成功后归零）+ 达到阈值后确实转存且逐条分条

Not in scope

  • 不改 #156 已落地的 archive 存储结构本身（collection/写入 API/读 API 的形状）
  • 不改 delta 压缩正常路径（未失败、或未达到连续失败阈值）的既有行为，包括 issue #94 落地的
    "原样写回 Delta 缓冲"这一档降级路径——两档并存，本票只加"连续失败达到阈值"这一更严重的档位
  • 不强制本票必须把 archive 接入三因子召回——留给实现期按 AC 最后一条评估
## Parent #156——本票是从 #156 拆出的"archive 内容产出方"部分。 ## What to build issue #156 实现期 Understand 阶段三个独立 agent 一致核实：`arise_archive_collection` （`config.py:166`）自代码写下第一天起就只是占位名字（首个引入提交 `8f32347` 原话："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"），从未被创建/写入/召回。#156 已把 "存储结构"（collection 创建 + 分条化写入 API + 存储层读 API）单独落地，但**没有任何代码路径 会产生内容写进这个 collection**——ADR-0009「更新（2026-07-08 第三方项目对照 grill）」节设计的 降级路径（"Delta Buffer 压缩失败自愈降级……连续失败时整批 delta 原样转存为低置信度 tentative 记录（不提炼，只保留原文）+ 标记该 chat 待重试"）就是 archive 数据唯一说得通的来源，但 ADR-0009 自己「更新（2026-07-30，issue #94 实现期）」节明写"这一档没有实现"——判定"连续" 需要一个跨重启存活的失败计数（新列/新表 + 一次 schema 变更），"属独立决定"，至今 （issue #94 之后 #116/#125/#126/#127/#134/#137/#146 等提交）也没有任何一次触碰这个分支。 本票负责补上这条产出方：`run_delta_compression_cycle`（`delta.py:823-965`）压缩 LLM 调用 **连续**失败达到阈值时，触发"整批当前 delta 原样转存为低置信度记录"，调用 #156 落地的 archive 分条化写入 API（不提炼、只保留原文，逐条对应原始 delta 条目，不是拼成一个 blob）。 ## Acceptance criteria - [ ] 新增跨重启存活的连续失败计数机制（Postgres 新列/新表，一次 schema 变更）——只统计 "连续"失败，中间只要有一次成功压缩就归零（ADR-0009 原文措辞"连续失败"） - [ ] 失败计数达到阈值 N 时，触发整批转存：调用 #156 的 archive 分条化写入 API，逐条原始 delta 条目对应一个 archive 记录，不合并成单条 blob - [ ] 阈值 N 的具体数字按 ADR-0011 阈值三层分类标定（静态 config，不是硬编码常量） - [ ] 转存后该 chat 的连续失败计数归零、Delta 缓冲清空（不是"写回 Delta 缓冲"那条既有降级档 ——issue #94 落地的"原样写回"是给未达到阈值的失败次数用的，两档并存、不冲突，阈值内重试、 阈值外转存） - [ ] 评估是否要把 archive 接入三因子召回（#156 故意没做——在本票落地前 archive 永远没有真实 数据，接召回是没有产出方可验证的死代码；本票落地后 archive 第一次有真实内容，是评估"要不要 接召回"的合适时机，但接不接召回本身可以是本票的产出也可以是再拆一张新票，实现期判断） - [ ] 补测试：连续失败计数机制本身（跨重启存活、成功后归零）+ 达到阈值后确实转存且逐条分条 ## Not in scope - 不改 #156 已落地的 archive 存储结构本身（collection/写入 API/读 API 的形状） - 不改 delta 压缩正常路径（未失败、或未达到连续失败阈值）的既有行为，包括 issue #94 落地的 "原样写回 Delta 缓冲"这一档降级路径——两档并存，本票只加"连续失败达到阈值"这一更严重的档位 - 不强制本票必须把 archive 接入三因子召回——留给实现期按 AC 最后一条评估
Yushu closed this issue 2026-08-20 04:45:25 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/189-delegate-task-cancellation-shield
No results found.
Labels
Clear labels   
状态：人类就绪
Requires human implementation

  
状态：待拆片
Issue is too large or underspecified — needs to be broken down into smaller child tickets before work can start

  
状态：待评估
Maintainer needs to evaluate this issue

  
状态：忽视
Will not be actioned

  
状态：智能体就绪
Fully specified, ready for an AFK agent

  
状态：等待信息
Waiting on reporter for more information

No labels
状态：人类就绪
状态：待拆片
状态：待评估
状态：忽视
状态：智能体就绪
状态：等待信息
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ProjectKuma/arise#165
No description provided.