Run 中段认知交班

wesgine 的 MidRunHandoff 机制——Run 进行中的上下文压缩与信息保全。

为什么需要中段交班

长 Run 会产生大量工具调用和结果，消耗上下文窗口。

当消息累积到接近窗口限制时，需要压缩历史以继续运行。

与终态 Settlement 的关系

两者使用相同的 SessionState schema（INV-CTX-45）。

信息保全优先级

首选：认知交班（MidRunHandoff / CognitiveSettlement）
回退：机械压缩（确定性 fallback）

认知交班由主对话模型做判断（INV-CTX-41）。

机械压缩在交班不可用或失败时提供确定性回退：

• 丢弃前用 ExtractToolEvidence 注入 Pinned system message
• 不做 LLM 判断

INV-CTX-44

信息保全首选认知交班。

交班不可用或失败时，机械压缩提供确定性 fallback。

不是"纯容量、保全由 SessionState 独占"。

压缩管线

Context 子系统的 CompressPipeline：

1. 检测窗口利用率
2. 判断是否需要压缩
3. 尝试 MidRunHandoff
4. 失败则回退到机械压缩
5. 提取 ToolEvidence 保留关键事实

对用户不可见

MidRunHandoff 的 LLM 调用不通过 SSE 推送到前端（INV-CTX-42）。

用户不会看到压缩过程产生的 assistant 消息。

相关不变量

• INV-CTX-44：信息保全首选认知交班
• INV-CTX-45：MidRun 与 EndOfRun 使用相同 SessionState schema
• INV-CTX-41：主对话模型产出
• INV-CTX-42：Settlement 产出不可见于用户

相关文档

• 认知结算 → cognitive-settlement.md
• 上下文压缩 → context-compression.md
• 上下文管理 → context-management.md