OpenClaw 接入外部系统以后，凭证轮换一定会发生。API 密钥到期、OAuth token 失效、员工离职、供应商要求重新授权、怀疑凭证泄露，都可能让工作流突然报错。如果没有轮换设计，Agent 不是直接中断，就是反复重试，把问题放大。
前面写过 OpenClaw 权限与凭证管理 和 连接器审计。今天补的是运行层问题：凭证真的要替换时，工作流怎样不停摆，证据怎样保留。
先建立凭证清单
轮换的前提，是知道有哪些凭证。清单里至少要有连接器名称、凭证别名、作用域、负责人、创建时间、过期时间、关联工作流和最近调用时间。没有清单，轮换就会变成到处找配置。
凭证清单不要记录密钥原文，只记录可管理信息。真正的密钥应该放在安全存储里，由工具层读取。
过期前提醒，而不是过期后救火
OpenClaw 可以把凭证过期时间接入定时任务。比如 30 天、7 天、1 天分别提醒负责人，超过期限自动把高风险写入切到只读或暂停。这样凭证过期不会在业务高峰时突然暴露。
提醒也要接入 异常告警。凭证问题不是普通失败，它通常会影响一批任务和多个工作流。
新旧凭证要灰度替换
不要把旧凭证删掉以后再测试新凭证。更稳的做法是先新增新凭证，用少量测试任务验证读取、写入、权限范围和错误返回，再切换真实工作流。连续通过后，再吊销旧凭证。
如果新凭证权限不足，工作流应该明确报“权限不足”，而不是让 Agent 继续猜。必要时可以进入 只读模式，先保留查询和建议能力。
吊销也要验证
很多团队只验证新凭证能用，不验证旧凭证是否真的失效。轮换完成后，要确认旧密钥无法再调用工具，相关缓存已经清理，日志里能看到切换时间和确认人。
如果轮换过程中发生失败，可以参考 恢复演练，先跑测试任务，再恢复可写流程。凭证替换本身也应该是一类可复盘生产变更。
总结
OpenClaw 凭证轮换的关键，是把密钥过期当成常规运维，而不是突发事故。凭证清单、提前提醒、灰度替换、失败降级、吊销验证和审计记录做好以后，Agent 工作流才不会被一个 token 拖垮。
