任务上下文也有保质期：过期判断与主动刷新
你在用一个很长的 agent 会话处理一个项目。讨论了半小时后，你去吃了一顿饭，回来继续问 agent「刚才那个问题后来怎么处理的」。agent 很认真地回答了一个方案，但那个方案是你一小时前就已经推翻的——你后来又讨论了替代方案，最终选了另一个方向。agent 不知道，因为它用的是一小时前的上下文。
这种问题比「上下文不足」更隐蔽。上下文不足你会立刻察觉——agent 说「我不知道你在说什么」或者答非所问。但上下文过期时，agent 依然能流畅回答，只是答案已经错了。这种错误往往是「看起来对，实际错」，在长周期任务里尤其危险。
两个维度的问题
传统注意力机制解决的是「上下文不足」：容量不够，塞不进去，所以要用各种压缩、摘要、滑动窗口来保留最相关的部分。这是一个空间问题。
「上下文过期」是另一个维度的问题：容量够，内容也在，但内容已经不对了。这是一个时间问题。传统方案假设「已加载的上下文在会话期间一直有效」，这个假设在很多场景下不成立。
打个比方：上下文不足是冰箱太小装不下食材；上下文过期是食材放进去了，但放太久已经变质。你可以在冰箱里放一百种食材，但如果其中一半已经过期，做出来的菜还是有问题。
什么会让上下文过期
第一种：外部状态变化。你让 agent 读取数据库查询结果，过了十分钟数据库被其他进程改了，agent 的上下文里还是旧数据。你让 agent 看某个文件，分析期间同事把文件删了或移动了位置，agent 的推理基于一个已经不存在的快照。你调用第三方 API 获取价格，五分钟后价格变了，agent 还在用旧价格做决策。
第二种：用户意图变化。你跟 agent 讨论了一个方案，讨论到一半你改主意了，想换个方向。agent 的上下文里还保留着之前的讨论记录，它会「记得」那些已经被你推翻的想法，甚至在你明确否定后还在推理链里引用它们。这不是 agent 的错——它不知道哪些是「当前的意图」，哪些是「已经废弃的思考过程」。
第三种：时间敏感性。价格、库存、天气、股票、航班状态，这类数据天然有时效性。你在上午 10 点获取的数据，下午 2 点还在用，可能已经完全不对了。agent 不会自动感知「这个数据已经过了四小时，应该重新获取」。
第四种：跨会话依赖。你在 A 会话里让 agent 修改了配置文件，然后在 B 会话里问 agent 当前配置是什么。B 会话里的 agent 读到的可能是旧配置，因为它不知道 A 会话发生过什么。这种问题在多窗口、多终端、多人协作场景里尤其常见。
被动过期与主动过期
「被动过期」是指 agent 不知道数据已经过期了，一直用旧数据推理。这是目前大多数 agent 系统的默认状态：读取数据时记录内容，之后不再检查数据是否变化。直到用户发现结果不对，手动触发重新读取。
「主动过期」是指 agent 知道自己用的某个数据可能过期了，主动标记并触发刷新。这需要额外的机制：读取数据时不仅要记「是什么」，还要记「什么时候读的」「什么时候可能过期」。在推理过程中，agent 要能检查这些元数据，判断是否需要刷新。
从被动到主动，需要建立两套机制：过期检测机制和刷新触发机制。前者是感知层，后者是行动层。
如何实现主动过期
第一步：读取外部数据时，同时记录「数据时间戳」和「数据有效期」。数据时间戳是「我什么时候读到的」，数据有效期是「这个数据在多长时间内可信」。不同数据源有不同的有效期策略：API 返回的实时价格可能有效期 5 分钟；文件内容在手动修改前一直有效；数据库记录取决于表级别的更新频率；配置文件可能一天内有效。
第二步：在计划执行循环里，周期性检查已读数据的有效期。这不是每次推理都检查所有数据，而是在关键节点检查关键数据。比如在生成最终结论前，检查推理链中依赖的外部数据是否仍然有效；在执行写入操作前，检查读取的状态是否过期。
第三步：设置「数据新鲜度告警」。当某个关键数据的有效期剩余不足 20% 时，提示 agent 需要刷新。这类似 TTL 的设计，但不是自动过期删除，而是给 agent 一个信号：「这个数据快过期了，如果你想用它，建议先刷新」。
一个实际案例
agent 在做代码审查，读取了 config.py 文件的内容，开始分析配置项是否合理。分析进行了十分钟，期间同事提交了一个 commit，修改了 config.py 的几个关键配置。agent 的上下文里还是十分钟前的文件快照，它基于旧配置给出审查意见，可能已经完全错误。
主动过期机制应该这样工作：agent 在读取文件时记录文件的 git timestamp 或 mtime；在生成审查结论前，检查文件的当前 timestamp 是否与读取时一致；如果不一致，触发告警或自动重新读取。
这个检查的成本很低——只是读取文件的元数据，不需要重新读取完整内容。但收益很大——避免了基于过期数据的错误决策。
三种新鲜度检测方式
时间戳：最通用，适用于大多数文件系统。读取文件时记录 mtime，之后检查 mtime 是否变化。缺点是只能检测「文件被修改过」，无法检测「文件被修改后又改回来了」。
版本号：适用于数据库、API 这类有版本概念的来源。每次更新版本号递增，检查版本号是否变化即可判断数据是否过期。比时间戳更精确，但需要数据源支持。
哈希：最精确，适用于对数据完整性要求高的场景。读取数据时计算哈希值，之后重新计算并比较。成本最高，但能检测任何变化。
实际系统中往往混合使用：文件用 mtime 做快速检查，用哈希做精确校验；数据库记录用 updated_at 字段；API 响应用 ETag 或时间戳。
总结
上下文管理不只是「塞多少」的问题，还有「对不对」的问题。传统注意力机制、上下文压缩、滑动窗口，解决的是容量问题。但容量足够不代表内容正确。
在 agent 系统里建立上下文保质期的意识和机制，才能让长周期任务真正可靠。这不是一个可有可无的优化，而是从「能跑」到「可靠」的关键一步。
回到开头那个场景：如果 agent 在回答你的问题前，能主动检查「刚才那个问题」相关的上下文是否仍然有效，就能避免基于过期信息给出错误答案。这不是更聪明的模型能解决的，而是需要系统层面的机制设计。
上下文也有保质期，这个保质期需要被看见、被管理、被刷新。