知识库一旦接入 OpenClaw，最容易被低估的问题不是资料太少，而是旧资料还在被引用。制度改了、价格改了、接口人换了、流程下线了，但旧文档仍然留在检索入口里，Agent 就可能给出过时答案。
知识库过期巡检要和 知识库过期审计、运行日志、工具输出校验 接起来。只有知道哪些资料被引用、引用后造成什么影响，才知道该优先清理什么。
先给资料加状态
每条知识库资料至少要有状态：有效、待复核、已过期、已下架。不要只靠文件夹名称判断，也不要让 Agent 自己猜某份文档是否仍然有效。
状态字段旁边要有负责人、最近确认时间和适用范围。比如同一份报价规则可能只适用于某个区域或某个历史版本，不能因为它“看起来还对”就继续全站检索。
引用频次决定巡检优先级
不是所有旧资料都一样危险。真正应该优先检查的，是最近被 Agent 高频引用、影响关键结论、且更新时间很久的资料。运行日志里如果经常出现某个旧文档，就要把它推到巡检前面。
这比平均扫描所有文件更有效。少量高频、关键、过期的资料，往往比大量无人引用的旧资料更容易造成业务错误。
冲突资料要拉出来确认
知识库里常见的问题，是新旧口径同时存在。Agent 检索到两份相互冲突的资料时，不应该自己选一个顺眼的答案，而应该标记冲突并交给负责人确认。
这类冲突可以进入 人工接管队列，也可以进入 异常看板。处理完成后，再把旧资料下架、降权或标注适用范围。
下架后要做回放验证
清理知识库不是删完就结束。下架或降权后，要用历史任务做一次回放测试，看 Agent 是否还能找到正确资料，是否因为资料减少而开始编造，是否把其他旧文档顶上来。
这部分可以复用 OpenClaw 回放测试。知识库变更本质上也是一次流程变更，应该有验证和回滚意识。
总结
OpenClaw 知识库过期巡检的核心，是把旧资料从答案入口挪出去。状态、引用频次、冲突记录、负责人确认和回放验证都建立起来以后，Agent 才不容易把历史口径当成当前事实。
