快照只在建立那一刻成立

# 快照只在建立那一刻成立

结论

把「会变的输入」与「建立时机」耦合在一起，就会得到一个只在建立那一刻成立的状态： 会话级系统提示里算好的日期、按 threadId 恢复的历史、被当成现状的快照。 它在跨过某个边界（午夜、新 turn、下一条 trace）后静默失效，而没有任何一处报错。 判据一句话：这个值是在什么时候算出来的？它还会再算一次吗？

三处证据：每一处都是「算一次，然后长期复用」

旁证：派生数据只在写入时入队旧数据要单独回填 —— 入队时机（只挂新建事件）决定了 存量永远不在处理范围内；这也是「时机」与「值」被绑死的另一种形态。

综合判断

1. 失效是静默的，因为没有任何一层认为出错了。 会话提示照常注入、恢复照常返回历史、 观测照常显示 trace —— 每一环都「成功」，只有下游拿到的东西过期了。

2. 可迁移的动作：任何「初始化时算一次、之后被长期复用」的状态，先问三句 —— 「这个值什么时候算的？」「它依赖的输入会不会变？」「它还会再算一次吗？」 第三问答「不会」，就必须显式定义刷新触发点。

3. 修正方向固定：把「会变的输入」从建立时搬到使用时的钩子上逐次注入 （如 before_agent_start 覆盖 systemPrompt），而不是在初始化时算死。

与既有 synthesis 的关系

• 存量不会自动跟上新逻辑 —— 相邻但不同：那条讲已存在的对象没被新逻辑重新处理； 本条讲算好的值跨过有效期后没被重算。前者缺「重新处理」，后者缺「重新计算」。
• 活的能力取决于增量机制而不是生成质量 —— 同源：都在问「谁触发下一次」； 那条是选型判据，本条是失效判据。
• 判据要用真值而非代理 —— 快照是「当前状态」的代理，只在建立那一刻与真值一致。

为什么这是 synthesis

单看每一页，都是某个项目里的一次「明明配好了却不对」。 并排之后才看得出它们共享同一个机制：把一个会变的输入冻结在了建立时刻。

相关

• 随时间变化的上下文要逐轮注入 / 共享历史不等于共享活会话
• 观测平台不能当运行状态真相源 / 派生数据只在写入时入队旧数据要单独回填
• 存量不会自动跟上新逻辑 / 真源要按维度显式指定