可恢复的工具结果折叠：怎样验证它比原生 compaction 更有价值？

[tt-a1i]

当前 Pi compaction / OpenPI context_pivot 已经能降低模型窗口占用。这里想讨论一个更窄的问题：已经离开窗口的工具证据，能否通过“小摘要 + 源引用 + 有界回读”更可靠地再次使用，且完整成本仍然划算？

本次是社区源码研究，不是性能实测，也不提议直接安装新的 Context Runtime。OpenPI 对照为 ed9dbc1018f890fd54375f5371990ddfee8af5df。

两个值得比较的机制

1. 总结后移出结果。pi-context-prune 在未来 context 投影中过滤已总结的 toolResult，原始 Session 留存；短 ref 可以恢复原结果。它也会跳过比原文更长的总结，避免无限重试同一范围。固定源码：pruner、indexer。
2. 先标记，集中提交。pi-fold 将 pending marks 与真正改变请求的 commit 分开，尝试减少反复改写前缀；peek 再按需读取原证据。它把原文和后代目录放进同一个总字节预算，而不是只限制正文。固定源码：context hook、bounded peek。

值得学的是可恢复引用、预算和变更边界。两个包都不能整体照搬：前者另发 summarizer 调用并复制索引数据；后者还接管 automatic compaction、overflow rollback 和九种工具操作。pi-fold 的 compaction hook。

也需要纠正比较口径：Pi 的原始 Session JSONL 不会因为退出模型窗口就等同于被删除。这里研究的是模型的恢复路径，不是另造一份 Session 来源。作者的节省比例和配合 Memory 的 Benchmark 尚未在 OpenPI 复现。

什么实验能判断有无价值

固定 Pi/OpenPI、provider/model、任务和 verifier，以当前 compaction/pivot 为基线，只比较上述两种结果投影策略，不加入新 Memory 或模型路由。

• 场景包含长构建日志、跨阶段追问，以及压缩后必须回看某条原始错误/后续纠正才能答对的任务。
• 记录任务成功率、事实准确率、所有模型调用的 input/output/cacheRead/cacheWrite、summarizer/child usage、wall time 和回读次数。上下文变短不能单独证明费用降低。
• 覆盖 Session reopen、branch/fork、取消、compaction/pivot 竞态及源内容不可读；恢复失败要明确失败，不能凭摘要补造“原文”。

必须保持的不变量：源引用属于当前允许的 Session/branch；来源与执行事实保持不变；tool call/result 的最终 provider 结构合法；正文、目录、参数数量和总结果共同受限；撤回/纠正不能被旧摘要覆盖；权限不能由记忆或引用恢复。

如果额外调用和 cache rewrite 使总成本上升，且没有质量收益，应停止。只有稳定对照结果通过，才开最小实现 Issue，优先复用 Pi context / Session entries / lifecycle，保留原生手动 compaction 退出路径。

关联：#190、#194、#313。与 #154 的 checkpoint/rewind 不同，本帖只研究工具证据的投影和恢复，不倒退执行事实。

研究记录：Pi 社区能力研究与候选清单（2026-09-08）。源码证据、运行验证与采用决策分别记录。