运行维护指南
OpenClaw 最佳实践：日常巡检、备份、升级与任务验收
把一次跑通变成可以重复验证的工作流。先记录版本和任务成功条件，再安排巡检、备份、更新与故障处理。
本页对应 OpenClaw best practices 的长期运行需求，聚焦巡检、变更和恢复。网关权限与安全审计单独放在安全指南，避免把所有运维问题都归结为权限问题。命令按 2026 年 9 月 21 日上游文档核查。
1. 给实例留一份可重建的记录
记录安装方式、框架版本、容器镜像标签或提交、模型提供商、配置与数据目录、渠道和扩展版本。密钥只记录用途与存放位置，不把原文放进这份记录。出了问题，先比较这些信息是否变化，而不是立刻重装。
容器镜像使用经过验证的具体版本，升级时记录新旧标签及实际镜像摘要。手工进入容器安装的依赖在重建后可能消失，应把它们纳入可复现的部署配置。托管实例则记录平台显示的版本及所用配置入口。
2. 每个任务都定义可检查的结果
“帮我做日报”过于宽泛。更容易验收的要求是：读取指定的公开来源，按日期生成一份文件，给每条结论保留来源，缺少数据时说明缺项，未经确认不对外发送。这样既能检查结果，也能区分资料缺失、模型错误和发送失败。
- 输入：允许读取哪些来源，时间范围是什么，如何处理缺项。
- 输出：文件或记录保存在哪里，格式与必填字段是什么。
- 完成条件：哪些结果必须由程序或人工核对，哪些动作需要批准。
- 失败处理：最多重试几次、何时停止、如何通知负责人。
涉及发邮件、发布内容或写入外部系统时，为每次任务保留唯一标识和执行记录。重试前确认上一次是否已产生结果，避免网络超时后重复发送。框架能继续对话，不代表业务操作天然不会重复。
3. 分层巡检，不用聊天探活代替诊断
自建 OpenClaw 可以先查看版本、状态与网关健康快照。这些命令不需要给真实用户发送测试消息：
openclaw --version
openclaw status
openclaw health --json需要进一步检查渠道时，可以使用 openclaw status --deep。它会向网关请求探测，不是只读取本地文件。具体语义见官方健康检查说明。
| 检查层 | 需要回答的问题 | 通过后仍不能证明什么 |
|---|---|---|
| 主机与容器 | 进程是否运行，磁盘和内存是否足够 | 渠道授权仍然有效 |
| 网关与渠道 | 网关是否可达，渠道是否连通 | 模型有额度并能完成推理 |
| 模型与工具 | 提供商是否可用，工具凭据和权限是否有效 | 业务结果满足要求 |
| 任务验收 | 文件、记录或待审核草稿是否实际生成 | 未来每次运行都不会失败 |
端到端验证放在你自己的隔离测试环境，用中性数据并控制调用次数。不要借其他用户的会话、数据或模型额度检查系统。监控应访问真实健康状态，缓存的营销首页返回成功不能代表实例健康。
4. 给模型重试与费用设置边界
记录一次任务的调用次数、失败类型和总费用。区分请求过密、余额不足、模型下架和工具授权过期：这些问题不适合用同一种无限重试策略处理。连续失败时停止任务并通知负责人，比重复消耗额度更容易恢复。
为预览模型保留已验证的替代方案。切换前确认替代模型支持需要的输入与工具调用，并重新核对价格；同样的提示词不保证得到相同结构的结果。供应商侧的预算或密钥额度、框架的重试限制与任务自身的截止条件应分别检查。
5. 备份后做一次隔离恢复
先确认实际数据目录，而不是仅备份代码仓库。配置、凭据、工作区、会话状态、自定义扩展数据可能分开存放。运行中的数据库或状态文件需要按对应组件的备份方式处理；随手复制正在写入的文件，不一定能恢复。
- 升级前记录版本与目录清单，按官方说明生成并验证备份。
- 把备份放在原实例之外的受控位置，限制读取权限，并为包含凭据的内容加密。
- 在隔离目录或独立测试实例恢复，先关闭真实渠道、定时任务与外部写入。
- 检查配置能否加载、工作文件是否齐全，再用测试数据验证必要工具。
“备份命令成功”只是第一步。记录恢复所需步骤与时间，才能知道故障时是否真正用得上。官方升级文档也强调升级前验证备份。
6. 一次只变更一层，并准备回退
不要在同一窗口同时更换模型、升级框架、安装插件和迁移数据。先在测试环境完成一个变化，验证通过再进行下一个。对于支持该命令的自建安装，可先预览升级计划：
openclaw update --dry-run这不是正式升级命令，也不适用于代替 Docker 镜像更新。容器部署应按镜像替换流程执行；托管部署使用平台提供的升级入口。升级后重复状态、渠道和任务验收检查，再恢复定时任务。
回退不仅是换回旧二进制。若状态格式已经迁移，旧版本可能无法读取新状态，需要按该版本说明恢复兼容备份。保留旧版本与备份的对应关系，先确认恢复路径，再执行不可轻易撤销的迁移。
Hermes Agent 的对应做法
同样记录版本、模型、插件与配置环境，并备份实际使用的 Hermes 数据目录，默认是 ~/.hermes/。自建网关用 hermes gateway status 查看状态；需要重启时用 hermes gateway restart。多配置环境用户先确认命令操作的是目标实例，服务管理方式见官方网关说明。
Hermes 的模型与终端后端设置见官方配置说明。插件变更按Hermes 插件流程处理，不套用 OpenClaw 的更新或审计命令。托管用户从仪表盘确认可用操作与版本。
常见问题
OpenClaw 在线，为什么任务仍然失败？
进程在线、网关可达、渠道连通、模型可用和业务结果正确是不同层次。健康检查不能证明模型有额度或外部账号权限足够，需要按层检查，并用你自己的小型测试任务验证结果。
应该始终自动跟随最新版本吗？
长期任务宜使用已验证的具体版本。升级前阅读变更、验证备份并记录旧版本，在测试环境确认模型、渠道与工具工作正常后再替换。容器部署应按镜像更新流程处理，避免仅更新容器内部软件。
只备份工作目录够吗？
通常不够。还要识别实际使用的配置、状态目录、凭据与自定义插件数据，并按组件要求做一致性备份。恢复测试时应隔离真实渠道和外部写操作，避免重复发送消息或执行定时任务。
这些最佳实践适用于 Hermes Agent 吗？
版本记录、任务验收、备份恢复和费用监控同样适用。Hermes 使用自己的配置环境与命令，例如 hermes gateway status；OpenClaw 的 update、health 和 security audit 命令不能直接用于 Hermes。