智能体上下文压缩后，持久化控制平面应证明什么？

我从今天 GitHub Trending 上拉取了一个项目的新副本，因为它解决了一个我在长时间编码智能体运行中反复看到的问题：在压缩或重启之后，任务可能仍然存在，但下一步动作、约束或验证状态却不再对得上。我不是维护者。我在 Python 3.14 上测试了提交 `2114afe`。该设计把目标、门禁、待办事项、证据、配额、运行历史和交接都放在聊天对话记录之外。这是正确的恢复面。一组聚焦的 869 个控制平面和投影测试在本地通过，同一提交的 Python 测试工作流也是绿的。有趣的部分在下一层。完整的公共冒烟工作流是红的。有些示例失败是因为工作流没有安装包；其中两个在我从已安装的 checkout 运行时通过了。三个控制平面冒烟测试仍然失败，因为它们期望 `skip` 决策，但实现返回了 `repair_bridge`。这让我得到了一个比“账本存活了”更严格的验收测试： - 在压缩或进程重启之后，智能体是否能恢复确切的下一步有界交付？ - 它是否保留用户的验收标准和权限边界？ - 回合是否以代码、测试或运行时证据结束，而不是又一层流程产物？ 外部状态可以降低重建上下文的成本。它无法解决提供商的上下文上限，而且如果每次恢复增加的模式多于交付内容，它本身也可能变成一种漂移。对于在多个回合中运行智能体的人：压缩之后，哪一个单一的断言捕获了最多的真实失败？