知识库引用多久会过期？用 1200 条引用实测：8 小时后三成已指向改过的文章

作者用 Python 重建了 osFoundry 的四个知识库 MCP 工具（基于 SQLite），模拟一天客服场景：400 篇文章、120 次提问、300 次人工编辑。结果发现 8 小时后 30.8% 的引用已过期，80% 的回答至少含一条过期引用；而只靠标题校验只能发现其中 41%。文章还对比了三种核查策略的成本，并实测把引用里的 updated_at 当作编辑版本号（compare-and-swap）的效果。

引用里该放什么：标题、ID 还是 ID 加更新时间

• 只引标题最直观，但文章改了内容、标题没变时完全看不出来，只能发现改名或下架
• 文章 ID 解决了改名问题，但依然无法反映内容变化
• ID 加 updated_at 三者兼备：抗改名、能发现内容变更，还能直接当编辑时的版本号
• osFoundry 桌面客户端里 edit_knowledge_article 的 expected_version 就是 date-time 格式，和引用里的更新时间是同一类值

模拟设置：一天客服知识库的还原

• kb_store.py 用 SQLite 实现四个工具，参数限制照搬真实服务器：query 2–200 字符，搜索 limit 上限 20，事件上限 100
• 400 篇文章、120 个问题、300 次人工记录，热度按 Zipf 分布（s=0.9）：前 10 篇文章吃掉 36.7% 的提问和编辑
• 编辑中 85% 改内容、10% 连标题一起改、5% 下架
• 脚本 Claude 每次提问取前两个搜索结果并保留引用，每小时核查一次；5 个 seed 跑完共 25.7 秒

引用过期有多快

• 8 小时结束时 1,200 条引用中 369 条（30.8%）指向已变更的文章，80.2% 的回答至少含一条
• 过期不等于错误——改的可能不是回答用到的段落，但不重读就无法确认，日期就是线索
• 热度是主因：把 300 次编辑均匀摊到 400 篇文章后，过期率降到 13.9%，回答污染率降到 46.7%
• 只查标题只抓到 369 条中的 152 条（41.2%），内容修改完全漏掉

核查方式：重读每篇还是轮询事件日志

• 对每个引用标题重新搜索：累计 2,426 次调用、3,342 KiB 数据
• 逐篇重读引用文章：2,264 次调用、3,445 KiB，成本随引用数线性增长
• poll_resource_events 从游标续读：全天 40 次核查只用了 40 次调用、153 KiB，每次核查一个调用
• 两种基于 ID 的策略都精确找出了同样的 369 条过期引用；轮询成本随变更数而非引用数增长，游标就是一个整数

把引用当编辑版本号：多久内可靠

• 读后 20 秒内用引用的 updated_at 提交编辑：150 次全部成功，0 拒绝
• 延迟 15 分钟后 20% 被拒，1 小时 38%，4 小时 56.7%
• 被拒是系统在正确工作：否则会用旧读取构造的内容覆盖别人更新的文本
• 补救很机械：重读、把改动套在新内容上、用新版本号重写，重试全部成功；幂等键重放 409 次均返回首次结果且不产生新事件

为什么只检索已发布文章

• 引用应指向有人确认过的答案，草稿不该出现在搜索结果里
• 桌面端文章的 Publishing 标签页控制发布状态，只有已发布文章可被搜索和读取