Tool lifecycle across context epochs：Compaction、Resume 与 Provider 切换后的能力重投影

[tt-a1i]

这是 OpenPI 产品哲学总纲 #299 与 Tool Surface Economics #300 的后续专题。

#300 讨论了工具常驻、显式加载、Adaptive Gateway 与 Provider-native deferred loading 的成本。一个进一步的问题是：工具定义在 Session 中途被动态加载后，新的 Context epoch 会怎样处理它？

这里的 epoch 不只指 Compaction，也包括 Session reopen/process restart、branch/fork、model/provider switch，以及 authority/resource shrink。它们都会迫使 Runtime 把 canonical capability state 重新投影为模型可见上下文。

这不只是 Token 优化。它决定 Runtime 权威状态、模型可见能力和 Provider cache boundary 能否保持一致。

问题场景

部分新模型支持把动态工具定义追加到当前历史位置：

早期稳定 prefix
  → loader Tool Call / Tool Result
  → addedToolNames / tool_reference / tool_search_output
  → 新工具从这里开始可见

这样可以避免为了加入新工具而重写旧 prefix。

但当 Context 过长，Pi 会把较早历史替换为 summary，并只保留近期消息。此时需要回答：

1. 如果工具加载点仍在保留历史中，是否继续使用原来的 deferred load point？
2. 如果加载点已经被压缩掉，工具定义在哪里重新物化？
3. Compaction 后 Runtime 中已经激活的能力是否仍然有效？
4. Session 重开、进程重启、分支切换、模型或 Provider 切换时，哪些能力状态可以继承？
5. 如果权限、Trust、资源或 child boundary 已经收缩，怎样避免从旧 summary 或旧 tool reference 恢复出过宽权限？

当前 Pi 0.84.1 的可见行为

当前源码可以确认：

• 纯增量 setActiveTools() 会把新增工具名记录在 Tool Result 的 addedToolNames；
• 支持原生 deferred loading 的 Provider adapter 会根据保留下来的加载点，把定义放在 transcript 对应位置；
• Pi 0.84.1 新生成的 compaction 使用 summary + retainedTail 形成自包含 checkpoint，再接 compaction 后的新 entries；只有旧 Session 没有 retainedTail 时，才回退到 firstKeptEntryId 兼容路径；
• 如果含 addedToolNames 的 Tool Result 仍在 retainedTail，adapter 可以保留原 deferred load point；如果加载点被压缩掉，当前 active tools 会重新成为 immediate/top-level definitions。能力没有被卸载，但序列化位置改变，可能形成新的 cache prefix；
• Compaction summary 请求本身与下一次普通请求应被视为新的 cache comparison epoch，而不是旧 prompt cache 的延续证明。

这说明“压缩旧历史”和“卸载 Runtime 能力”不是一回事。但 Session reload、Provider switch、权限变化后的完整恢复合同仍需固定实验验证。

必须区分两类 Compaction

Pi semantic compaction

Pi 生成可读 summary，并把近期 AgentMessage[] 物化为 retainedTail。后续模型上下文由 Pi 重建，summary pass 自身的 usage 与下一次普通请求应分开记录。

Provider-native compaction

例如 OpenAI Responses 可能返回 opaque canonical compaction item，要求后续原样传入。它的可检查性、传输、usage、cache boundary 和跨 Provider 迁移合同不同，不能把 Pi 的 addedToolNames/retainedTail 行为直接外推过去，也不能把 opaque item 当作 Runtime 权限来源。

本帖当前可从源码确认的行为主要针对 Pi semantic compaction。Provider-native compaction 必须单独冻结 API、model snapshot 和 wire items 验证。

建议的所有权边界

Runtime 保存权威状态

包括：

• 当前真正加载的 capability group；
• 用户和配置授予的权限；
• Parent/Child authority intersection；
• 资源是否仍存在；
• 并发、调用和费用限制。

这些事实不能依赖模型 summary，也不能由 Provider tool reference 自动扩权。

Compaction Summary 保存语义进度

包括：

• 用户目标；
• 已完成工作；
• 关键决策；
• 仍需继续的任务；
• 必要的资源引用。

Summary 不应复制完整 Tool Schema，也不应成为权限来源。

Provider Adapter 重新投影工具定义

在每个新的 context/cache epoch，根据当前 Runtime 权威状态选择：

• 保留仍位于近期历史中的 native deferred load point；
• 在旧加载点已被压缩时重新物化当前 active tools；
• Provider 不兼容时使用明确 fallback；
• 模型或 Provider 改变时，不复用不兼容的 provider-specific opaque reference。

需要避免的失败形态

• Runtime 认为工具已加载，但模型看不到；
• 模型 summary 声称工具可用，但 Runtime 已撤销权限；
• Session 恢复后静默扩大工具面；
• Provider 切换后重放不兼容的 tool reference；
• Compaction 后工具定义丢失，却没有任何 observable boundary；
• 未检查 Provider usage 就预设 compaction 后首请求一定 cold 或一定延续旧 cache，或把 compaction 本身的 prefix 变化错误归因于 tool-surface mutation；
• 为了恢复工具，向 summary 塞入完整 Schema，重新制造上下文膨胀。

候选设计

A. 只依赖进程内 active tools

Compaction 不改变 active set；下一请求根据现有 active tools 重建定义。

优点是简单、Pi-native。缺点是进程重启和 Session 恢复没有持久合同。

B. 在 Session/Compaction 元数据中持久化能力投影

记录 capability 名称、tool-surface fingerprint 与来源，但不记录完整 Schema，也不直接记录执行权限。

优点是可恢复、可诊断。风险是形成第二份状态，必须与当前配置、Trust 和资源状态重新求交，不能盲目回放。

C. 恢复时重新派生

从当前配置、Session canonical state、资源状态和 authority boundary 重新计算工具面；旧记录只用于诊断差异。

这最符合 fail-closed，但需要明确哪些 capability 是用户授权，哪些只是模型在旧上下文中的临时发现。

可能的组合是：B 记录 receipt，C 负责权威恢复。

最小可证伪实验

固定 Pi/OpenPI、Provider、模型、cache key 和工具组，至少覆盖：

1. addedToolNames Tool Result 仍位于新格式 retainedTail；
2. 加载点已从 retainedTail 移除，active tools 重新成为 immediate/top-level；
3. 旧格式、只有 firstKeptEntryId 的 Session 兼容恢复；
4. compaction 后继续同进程 Session；
5. 保存并重新打开 Session或重启进程；
6. Pi semantic compaction 与 Provider-native opaque compaction 分别验证；
7. 切换支持/不支持 native deferred 的 Provider/模型/API；
8. compaction 前后收缩权限或删除资源；
9. Parent、Child、Fork 分别验证，不共享未经复核的 authority。

逐 turn 记录：

• Runtime loaded capability names；
• active/immediate/deferred tool names；
• tool-surface fingerprint；
• addedToolNames 与 Provider item 类型；
• compaction boundary 与 first-kept entry；
• cache read/write/uncached input；
• Session 恢复前后的 authority intersection；
• 任何重新物化、降级或拒绝的 receipt。

预期不变量：

模型可调用工具
⊆ 当前 Runtime 授权工具

Compaction 不应自动卸载仍有效的能力
Compaction 也不应恢复已经失效的权限

与现有工作的关系

• #156 负责逐 turn cache boundary、compaction 与 tool-surface 变化的可观察证据；
• #191 负责区分 prompt cache、context state、memory、compaction 与 replay 的所有权；
• Tool Surface Economics：稳定全量前缀还是渐进式能力加载？ #300 负责工具面的总体经济性；
• 本专题只讨论动态能力怎样跨越 Context lifecycle，暂不预设新的持久化控制面。

非目标

• 不建立 OpenPI-owned Provider prompt cache；
• 不持久化或模拟隐藏 KV state；
• 不把 summary 当作 Runtime 权威状态；
• 不因旧 tool reference 自动恢复权限；
• 不为缓存优化增加固定 Workflow；
• 不把 compaction、Session resume 或 replay 报告成 cache hit。

希望讨论最终回答：

在不引入第二套 Agent OS 或平行状态机的前提下，Pi 应提供什么最小原语，让动态工具在 compaction、恢复和 Provider 变化后能够 fail-closed 地重新投影，并留下可验证 receipt？

[tt-a1i]

补充与其他专题的边界：

• Compaction 后“是否应该恢复某项能力、恢复到什么权限”归 Capability Discovery and Authority #312；
• 恢复是否可靠、成本是否值得、什么 receipt 才算通过归 Evidence and Evaluation #313；
• 本帖集中讨论 canonical loaded set、模型可见投影、Provider 序列化以及 Session 恢复协议。