知识库更新看起来只是换文档，实际上可能改变 Agent 的回答口径。客服政策、产品限制、价格规则、合规说明一旦更新错误，影响会直接出现在用户面前。所以 OpenClaw 里的知识库更新，不建议直接全量发布。
更稳的做法是做灰度发布：先让少量任务命中新口径，观察回答质量、引用来源和人工反馈，再决定是否扩大范围。它和 知识库保鲜、评测集、回滚预案 是同一条链路。
先记录新旧口径差异
灰度之前，要写清楚本次知识库到底改了什么。是新增资料、删除旧规则、修改价格说明、调整适用范围，还是合并多个 FAQ。只写“知识库更新”没有复盘价值。
最好做一张新旧口径表：旧答案是什么，新答案是什么，为什么改，影响哪些问题。以后回答出错时，才能判断是检索命中新文档，还是 Agent 理解错了差异。
命中场景要先收窄
知识库灰度不要一开始就覆盖所有入口。可以先选内部测试用户、低风险客户、特定标签问题或只读咨询场景。涉及退款、合同、权限、价格承诺的内容，应该更晚放量。
这和 灰度发布 的原则一致：先验证低风险场景，再逐步扩大影响面。
评测样本要覆盖旧问题
新口径上线前，不只要测新问题，还要测旧问题。很多知识库事故来自“修了一个问题，改坏了另一个常见问题”。所以评测样本里要有高频旧问题、边界问题和历史失败样本。
如果 OpenClaw 已经有 失败样本库，可以优先抽取和本次知识库变更相关的样本，作为灰度前后的对比材料。
人工复核看引用和语气
知识库灰度期间，人工复核不只看答案对不对，还要看引用来源是否正确、是否把条件说完整、是否把内部口径说成外部承诺。Agent 的语气太肯定，有时比事实小错更危险。
复核结果要进入运行证据，而不是只在聊天里说一句“这条可以”。这样后面才能形成知识库发布复盘。
回滚条件提前写好
灰度发布必须有回滚条件。比如关键样本失败、引用旧口径、客户投诉增加、人工复核不通过、成本异常上升。触发后要能退回旧版本，并暂停继续放量。
这一步可以接上 SOP 版本库。知识库版本、评测样本和回滚点放在一起，才不会出问题后到处找材料。
总结
OpenClaw 知识库灰度发布的重点，是让新口径先在小流量里接受验证。新旧差异、命中场景、评测样本、人工复核和回滚条件都写清楚，知识库更新才不会变成一次盲目全量上线。
