缓存依赖失效

让源、授权与策略变化传播到相关缓存和在途结果。

缓存失效是数据和权限治理的一部分。来源更新、删除、ACL与群组变化、memory撤回、模型和prompt更新、索引切换与时间跨界，都可能让旧结果不再适用。TTL只能控制一段最长复用时间，不能替代这些事件传播。

建议维护依赖链：缓存结果依赖哪些source_version、资源、权限代次和策略。源事件触发相关键失效，写入新generation后再原子切换可读指针，减少新旧索引混用。对于无法精确追踪的依赖，可采用更粗范围失效，但应评估重建负载和冷启动影响。

权限撤回尤其需要处理在途信息。资料可能已经进入当前context、摘要、子Agent和待发布产物。清掉检索缓存并不会让模型忘记已见内容；应使受影响Run失效、取消或受控重建context，最后发布前再次检查来源资格。删除日志payload也不能当成撤回所有下游副本的证明。

Prefix cache由供应商控制，应用未必能逐条删除；这与自有检索或答案缓存不同。采购时核对保留、隔离和删除合同，不把本地清空等同云端零保留。业务侧可以停止继续发送旧前缀，并治理可控制的副本和引用。

失效事件可能密集发生，需有去重、重试和背压。避免每次小更新触发全库重算，也不能为降低成本而忽略关键ACL事件。缓存owner、依赖版本和最后校验时间应可观测。

测试撤销群组权限、删除文档、更新法条有效期、撤回学生观察和切换模型规则，检查从候选到产物的传播。验收不只看键是否消失，还看旧内容是否仍在prompt、子任务或最终回答里出现。失效正确性比单一命中率更能决定企业可信度。

实践重点：按lineage失效；撤回资料时重建受影响context并复核待发布产物。

验证抓手：覆盖源删除、群组变化、memory撤回与索引切换。

常见误区：只等TTL或只清索引，忽略已有摘要和子Agent。

Claude Code：Prompt caching；MCP：安全建议。

失效处理应有可查询状态和失败告警。关键撤回事件未传播完成前，相关高风险发布可暂缓，而不是默认继续读取旧副本。