上下文有效期需明确
别名: 上下文过期时间 · 还记不记得上一轮 · context time-to-live
概念解释
早上在厨房说「还是那杯」，系统接的是三分钟前的燕麦拿铁；第二天同一句话，有的产品仍接昨天的单，有的已经当成没听过。用户无法从任何信号里读出这条规矩。上下文有效期（explicit context TTL）要求共同基础里的对象和槽位有一份可被学会的寿命：多久之内「还是那个」合法，过了这条线哪些指针失效。有效期是合同，不是内部缓存的顺便行为。它管的是对象还算不算在场，不是沉默多久该催一句——催问是另一套策略。
机制
人把最近的任务当成默认话题，直到一个可感知的边界把它合上：走出房间、开始下一段对话、隔了一夜。系统若用进程寿命、唤醒会话或固定三十秒去近似这些边界，两边的时钟会对不齐。TTL 太短，合法的回指被当成新意图，用户觉得系统「健忘」；TTL 太长，昨天的收货地址被写进今天的外卖，用户觉得系统「擅自记得」。有效期还应按对象类型分层：正在填的一张订单是短寿命；用户亲口设定的默认家地址是长寿命；一次性的验证码几乎是当轮。把所有槽塞进同一个会话时钟，短的会脏、长的会丢。合同要显式，是因为寿命本身看不见——不像屏幕上的表单关了窗口就没了。
怎么研究
用延迟探针：在对象被引入之后，隔 10 秒、2 分钟、一次会话断开、次日同一场景，让用户说「还是那个 / 同样的」。自变量是间隔类型（连续对话内的时间、会话边界、日历日），以及对象类型（当轮订单对长期偏好）。因变量：系统按旧对象执行的比例、当成新任务的比例、以及用户事后能否正确描述「你以为它还记得吗」。
日志上把含回指的话轮按距上次提及的时间分箱。若某一时间箱里成功绑定骤降，而产品没有对应的过期行为，TTL 是在暗处断裂。实验室若从不拆会话，测到的永远是「还在同一轮里」，会高估可保持的时长。
边界
医疗、支付这类对象的寿命受法规和安全约束，产品钟必须短于或等于那条硬限制，不能用「用户可能还想接着说」去延长。共享设备上，上一个人的上下文对下一个人应当是零寿命，TTL 在身份切换处被切断。专家对固定工位上的设备会形成超长默认（「还是昨天那条产线」），短 TTL 会误伤；那是要把这类对象升成命名的、可查看的偏好，而不是把当轮订单的钟也拉长。有效期说清楚之后仍然会有边界争议——争议该落在设置或第一次使用的说明里，而不是落在一次错误执行里。
怎么落地
- 为当轮任务对象、会话级对象、长期偏好分开写 TTL，并在内部状态里用不同的过期动作（丢弃、降为可恢复草稿、保留）。
- 用一次可听见的方式让寿命可学：例如会话结束时说「这次的单子我不再接着用」，而不是让用户用「还是那个」去试探。
- 过期后不要静默沿用，也不要假装从未有过；钟走完之后，丢失本身还要被说出来，但那是另一层动作——这里先保证钟是写明的。
- 验证：同一句「还是那个」分别在任务刚结束、隔两分钟、隔一次唤醒、隔夜各测一次。四种结果对不上书面 TTL，合同就不存在。