结语：上下文纪律

阅读契约： 把本页当作迁移测试。设计任何 agent runtime 时，都追问谁拥有上下文、它活多久、如何被压缩、以及将来如何被重建。

核心教训不是 Codex 有一个聪明的摘要 prompt，而是一个严肃的 agent runtime 必须像数据库治理状态那样治理上下文：它需要 owner、生命周期、checkpoint、diff、projection 和 replay。

模式可以迁移：

• 把 raw 证据与 model-ready projection 分开。
• 在构造 prompt 之前先解析 turn envelope。
• 通过 typed fragments 渲染运行时事实。
• 给可选上下文显式预算与诊断。
• 把 compaction 当作 checkpoint 安装。
• 把 rollback 保留为事件, 而不是破坏性编辑。
• 让客户端观察上下文, 但不拥有它。

全书速查图

如果你只记住本书一张图，让它是这一张。它把 8 章压缩成一次阅读：

正向 turn 时从上往下读；resume、rollback、replay 时从下往上读。两个方向都经过每一个 owner，差别只在 ledger 是被读还是被重建。

Codex 并不完美

Codex 并不完美：有些 diff 路径仍不完整，估计较粗糙，遗留 compaction 兼容性带来复杂度。这些粗糙边缘反而让设计更有研究价值，它展示了一个真实产品从”prompt 拼接”压力演化为必须能 resume、分叉、压缩并解释自己的 runtime 时会发生什么。

正确的反应不是”设计错了”，而是”设计承认它哪里不完整”。这种承认本身就是一种架构模式：在显式冗余的正确性，与可能悄悄丢失必需状态的聪明优化之间，宁愿选择前者。

一句话带走

只带走一句话的话，请带这一句：不要问”我应该把什么放进 prompt？“，而要问”哪些 runtime 状态允许变成模型可见？谁拥有它？它应该存活多久？以后我怎么重建它？”

第一个问题让你拿到能跑的 demo。第二个问题让你拿到能撑住长期 agent 工作的 runtime。