大多数团队第一次谈知识更新，都会把它当成一个数据同步问题：多久跑一次增量、什么时候重建索引、失败后是否补跑。可只要 AI agent 真开始面向客户输出，这个问题立刻会升格成服务承诺问题。因为用户真正经历到的不是“同步延迟 45 分钟”，而是“政策已经改了，agent 还在告诉我旧规则”“库存已经售罄，系统却还在推荐刚下架的 SKU”“法务刚冻结一条流程，自动化还是按昨天的世界继续走”。
这就是为什么 corpus freshness 不能只停在 ETL 面板上。知识是否够新，决定了系统在当前这次 run 里应该继续回答、先追问、转人工，还是直接阻断高风险动作。没有 freshness SLA，Knowledge Plane 看起来像在持续运转，实际上却是在把“旧知识仍可被回答”这种风险悄悄外包给用户和支持团队。
所以本文真正关心的，不是“同步能不能更快”，而是“对不同类型的知识，平台到底承诺多新才算可用；一旦做不到，runtime 应该怎样诚实地退化”。这才是知识层进入生产之后的硬问题。
建议配合 AI agent Knowledge Source Onboarding Contract、AI agent Knowledge Plane Architecture、AI agent Cache Invalidation 和 AI agent Reindex 与 Re-embedding Migration 一起看。
先给结论：Freshness 不是统一的“多久同步一次”，而是按业务代价分层的服务语义
| 内容类型 | 过旧后最可能出什么事 | 建议 freshness 承诺 | 失效时的默认动作 |
|---|---|---|---|
| 合规政策、风控规则 | 直接给出错误许可或错误拒绝 | 分钟级或事件驱动 | 无 proof 时停下或转人工 |
| 价格、库存、优惠口径 | 对外承诺失真 | 分钟级到小时级 | 标记不确定，必要时拒绝回答 |
| 产品文档、操作手册 | 指导步骤滞后 | 小时级到天级 | 可回答，但需带 freshness 说明 |
| 培训材料、历史案例 | 容易提供过时经验 | 天级到周级 | 默认低权重，不能作为唯一依据 |
只要团队还在用“所有来源统一每小时同步”去回答 freshness 问题，就说明它还没有真正把知识更新和业务后果绑定起来。不同内容类型的 stale 代价完全不同，freshness SLA 也就不可能是一个简单 cron 表达式。
Freshness 要从“同步成功”升级成“这次回答有无时效证明”
很多系统最大的问题，不是同步真的很慢，而是 runtime 根本不知道当前答案背后有没有 freshness proof。它只知道自己搜到了片段，不知道这些片段是不是从最新 source version 建出来的，不知道 ACL 或索引是否刚切过，也不知道上一次同步失败是不是已经让当前来源进入 stale 状态。
更稳的做法，是把 freshness 当成 evidence 的一部分，而不是 ingestion 的副产品。一个被 runtime 消费的知识片段，至少应该带上：
- source version 或 source watermark
- ingestion completion time
- index version
- freshness tier 和有效窗口
- 当前是否命中 stale warning 或 stale block 条件
这样系统回答问题时，才不是盲目相信“索引里有什么就用什么”，而是能在 source 时效不明时切换到保守路径。
同步策略的真正选择，不是快与慢，而是“更新信号从哪里来”
| 同步方式 | 看起来的优势 | 最适合什么 | 最大风险 |
|---|---|---|---|
| 定时批量同步 | 实现简单、便于运维 | 低风险文档与长尾知识 | 关键更新会在窗口内继续被旧索引消费 |
| 事件驱动同步 | freshness 最强 | 合规规则、价格、库存、审批策略 | 上游事件质量不稳时容易出现假新鲜 |
| 混合模式 | 关键源事件驱动，其余批量兜底 | 多数生产 Knowledge Plane | 需要 runtime 理解不同来源的 freshness 证明 |
团队常见误判是觉得事件驱动一定更高级。现实里，事件驱动只是在上游事件本身可信、可重放、可对账的前提下才更好；否则它会制造另一类幻觉：看起来更新很及时，实际上丢事件后 runtime 还会以为自己看到的是最新世界。
Freshness policy 必须直接进入 runtime，而不是只留在数据平台
知识层一旦进入高风险场景，freshness policy 最值钱的作用不是“同步做得更漂亮”，而是影响回答逻辑。一个可执行的 runtime policy 至少应该区分三种结果：
| freshness 状态 | 说明 | 运行时动作 |
|---|---|---|
| fresh | 有时效证明且在 SLA 内 | 正常消费 |
| stale-warning | 可能略旧但业务可接受 | 回答时显式标注风险，限制高风险动作 |
| stale-block | 超过 SLA 或无 proof | 不再继续高风险回答，直接追问或转人工 |
这层动作非常关键。因为用户在乎的不是你的 ETL 看板是否发绿，而是系统在“知识可能旧了”的那一刻，有没有把风险从自己手里释放出来，而不是继续假装世界没变。
失败案例：紧急改了审批规则，agent 还在按旧版本放行，团队最开始甚至以为是 prompt 漂了
某团队在午间紧急收紧了一条采购审批规则，法务已经在源系统里更新配置，但 agent 下午仍然在一部分请求里给出旧判断。最早的排查方向全偏了：有人怀疑 prompt 缓存没刷新，有人觉得是模型随机性，有人怀疑 retrieval top-k 把旧材料排在了前面。
真正的根因后来很简单：这条 source 只有小时级批量同步，没有事件驱动；更糟的是，runtime 也不判断 freshness proof，只要搜到旧片段就继续生成结论。于是系统并不是“偶尔答错”，而是在规则刚变更后的窗口期里系统性地活在旧世界。
修复后，团队做了三件事：
- 高风险规则改成事件驱动 + watermark 对账。
- runtime 消费证据时必须检查 freshness tier 和 source watermark。
- 一旦命中 stale-block，agent 不再继续自动放行，而是进入人工确认。
这个改动直接改变了平台气质。它不再把“旧知识误答”当成一个统计上的偶发错误，而是当成服务边界被打穿的显式事件。
真正成熟的 freshness 设计，还得回答“同步失败时怎么办”
很多系统把 freshness 理解成“同步成功后很好”，却没有认真设计同步失败或半完成时的退路。这恰恰是最危险的盲区。因为生产里更常见的不是彻底停止，而是半失败：一部分源更新了，另一部分没更新；新的 source version 写进 registry 了，索引切换却还没完成；ACL 映射已经变化，旧索引还在对旧权限世界作答。
所以 freshness 设计还必须有故障语义。系统至少要能回答：
- 这次同步失败后，是否还允许使用上一个成功快照
- 哪类来源允许 stale-warning 继续服务，哪类必须 stale-block
- 当前 source 处于 partial-ready 时，runtime 是否知道自己只该引用哪一层索引
不把这些问题制度化，团队迟早会在事故现场临时发明“先这么用着”的口径，而这种临时口径往往会变成下一次更大事故的种子。
如果你现在只能先补一层，先让所有高风险来源都带 freshness proof 再允许回答
很多平台会先想着做更复杂的增量 pipeline、更细的监控面板。更值得优先补的，其实是 freshness proof 本身。因为只要 runtime 还在消费“看起来像最新、实际上无法证明最新”的知识，系统就仍然会在关键时刻装作自己知道，却根本无法证明。
Knowledge Plane 真正成熟的标志，不是同步任务跑得多快，而是系统已经知道：什么时候自己知道的是最新的，什么时候只是在碰运气。把这件事讲清楚，freshness SLA 才从后台任务变成了面向用户的真实承诺。
Checklist
- 是否按内容风险而不是按统一计划定义 freshness SLA
- 每条 evidence 是否都带 source version、ingestion time 和 freshness tier
- runtime 是否能区分 fresh、stale-warning 和 stale-block 三种状态
- 高风险来源是否具备事件驱动或等价的快速更新机制
- 同步失败或半完成时，系统是否有明确的保守退化路径
- freshness 指标是否已经从 ETL 看板进入回答与执行策略
延伸阅读：
