[Bug] 上下文压缩失败后切换模型无法恢复会话历史 / Model switch loses context after failed compaction

[voidcraft-dev]

问题描述

在 PI-Desktop v0.14.6（Windows）中，长会话发生自动上下文压缩失败后，切换模型或继续对话会导致新模型无法看到压缩点之前的历史内容。

这不是会话记录被删除：聊天记录仍然存在于本地 SQLite 和 session JSONL 中，但没有被恢复到后续模型的 context。新模型会说类似“之前的具体任务内容无法读取”。

已核实的证据

本机当前会话的持久化记录仍然存在，包含 500 多条消息。会话中有一条 compaction 记录：

{
  "failureCode": "CONTEXT_COMPACTION_FAILED",
  "fallback": "retained_tail",
  "retainedTail": [],
  "tokensBefore": 273641
}

该 checkpoint 的 summary 明确表示：

Older messages before this checkpoint are omitted from the next model request.
The complete transcript remains available to the user.

在此之前还发生过 provider 错误（上游返回 sensitive_words_detected）。随后切换到其他模型后，模型只能看到压缩点之后的短上下文，而完整 transcript 仍可在本地恢复。

为保护隐私，没有附加完整 session、数据库或 API 凭据。

复现步骤

1. 创建一个较长的 Agent 会话，使上下文接近模型窗口上限。
2. 让自动 compaction 运行；如果摘要请求因 provider 错误、超时或其他原因失败，观察 compaction fallback。
3. 继续对话，或在同一会话中切换 provider/model，触发 runtime 重建。
4. 询问新模型有关压缩点之前的具体任务或文件内容。
5. 观察模型表示无法读取之前的历史；但本地 session transcript 仍包含这些消息。

实际结果

• transcript/UI/本地存储中的历史仍然存在；
• compaction 写入了 retainedTail: [] 的失败 checkpoint；
• 后续模型请求不包含压缩点之前的历史，也没有可用摘要；
• 模型继续回答时会失去任务连续性。

预期结果

• 摘要失败时自动重试，或至少保留一个有界且非空的最近上下文；
• 不要写入会使后续恢复得到空 context 的 checkpoint；
• 模型切换和 runtime 重建应从 canonical transcript 或有效 summary 恢复；
• 如果恢复失败，应明确提示用户并提供从完整 transcript 恢复/新建会话的路径，而不是静默继续。

影响

长时间编码任务在 provider 临时错误或 compaction 失败后无法可靠继续，可能导致模型重复工作、误解当前任务或重新处理已经完成的工作。

环境

• PI-Desktop: v0.14.6
• OS: Windows
• 触发方式：长会话自动 compaction 失败后切换模型/继续会话

相关但不同的问题：#22、#203、#211、#39。

[muzimu217]

已定位根因，是 compaction fallback 链路上的三个叠加缺陷，本地已修复并自测通过（agent-runtime vitest 356/356、桌面回归 12/12），PR 马上提。

根因 1（正文观察到的 retainedTail: []）：createFallbackCheckpoint 的 tail 来自 Codex 形状的准备结果，而 completed_turn 模式按设计不保留任何裸用户消息（codexShapedPreparation 里 candidates = []）。fallback 摘要又只是"承接上次的通知文本"，不是真摘要。空 tail + 假摘要 ⇒ runtime 重建（切模型/重启）后，entriesWithCompaction 恢复出的 context 在压缩点之前什么都看不到——正是"500 多条消息都在库里，新模型却说无法读取"。

根因 2（失败被固化，从不自愈）：pi 0.85 的 prepareCompaction 会把上一个 checkpoint 的 summary 原样作为下一次的 previousSummary。fallback checkpoint 的"摘要"是恢复通知文本（含 [automatic context recovery: …] 标记）。下一次 compaction 触发时，模型走 UPDATE_SUMMARIZATION_PROMPT 去"更新"一个从未真正生成过的摘要——失败状态被永久固化。

根因 3（重建路径同样受污染）：fallbackPreparation 在终端 checkpoint 后重建更小 tail 时，previousSummary: terminal.summary 同样会把通知文本带入。

修复（三处最小侵入，均在 packages/agent-runtime/src/runtime.ts）：

1. createFallbackCheckpoint：shaped tail 为空时，从待摘要范围内按同一 token 预算保留最新的用户消息（复用 selectRetainedUserMessages），保证失败路径恢复出的 context 非空且有界；
2. prepareCompactionInput：previousSummary 含 fallback 标记时剔除，下一次摘要走全新 SUMMARIZATION_PROMPT 从 transcript 真正重建（等于自动重试真摘要）；
3. fallbackPreparation：同规则，通知文本不再被链条式携带。

对预期结果的覆盖：① 不再写入恢复出空 context 的 checkpoint；② 后续 compaction 自动重建真摘要；③ runtime 重建从 canonical transcript + 非空 tail 恢复。第 4 条（恢复失败时独立的用户恢复入口）本 PR 未动 UI，现有 contextCompaction.recovered toast 已覆盖 fallback 发生时的提示，独立恢复流程留作后续讨论。

分支：fix/compaction-fallback-restore