不论 AI 是否存在，homelab 都必须正常运行
核心思想
借助 AI 完成自己的任务时，一定要有无 AI 的替代方案。AI（如 Hermes Agent）只是加速器，不是拐杖——它本身也是 homelab 里运行的一个服务，会挂、会升级坏、会依赖出问题。关键路径如果寄生在 AI 上，AI 挂了基础设施跟着停；而最需要备份、最需要恢复能力的时刻，往往正是 AI 出问题的时刻。
五层独立性检查框架
判断一个自动化是否"无 AI 也能运行"，逐层检查：
调度层
任务由谁触发？如果调度器寄生在 AI 进程内（如 Hermes gateway 内置的 cron scheduler），AI 进程起不来 = 任务永不执行。替代方案：系统 crontab，与 AI 完全无关。
执行层
脚本是否依赖 AI 推理？纯脚本（no_agent）、标准系统工具（vzdump、rsync、scp）都满足。内容生成类任务天然依赖 AI，但数据收集层必须独立——AI 挂了只是不生成，数据不能丢。
存储层
备份目的地是否与源数据同机？单机单副本意味着硬盘损坏 = 数据归零。至少一份异地，且上传逻辑不依赖 AI 进程存活。
系统层
应用层备份之上还要有更底层的兜底：PVE 原生 vzdump 快照，不依赖任何脚本和 AI。
恢复层
灾难恢复入口（bootstrap 脚本）能否在 AI 不存在时手动执行？配置和文档是否以人可读的格式异地保存？
实践案例：备份调度自举死锁
审计发现备份脚本本身是 no_agent 纯脚本（执行层独立），但调度寄生在 Hermes gateway 的 cron scheduler 里。而备份的正是 Hermes 自己的状态（state.db、记忆、会话历史）——Hermes 因任何原因起不来，备份就静默停止。这是自举死锁：最需要备份的时刻反而没有备份。
修复：备份调度迁到系统 crontab，Telegram 通知改为脚本内 curl（显式走代理），Hermes 死活不再影响备份。同类检查：日记同步、健康检查等 no_agent 任务也应同样处理。
教训一：审计必须验证实际状态，不能信文档
skill 文档声称"远程备份 opt-in 关闭"，实际脚本无条件上传，异地备份一直在推、各保留 14 份。基于过时文档下结论会得出完全相反的判断。审计时验证三样东西：
- 脚本实际逻辑（grep 调用点，而不是读文档描述）
- 远端真实文件（sftp / S3 列举，看时间戳和字节数）
- 调度实际配置（crontab -l、系统服务）
教训二：独立脚本必须显式处理网络环境
Hermes 进程环境里有 http_proxy 走代理，但系统 crontab 是干净环境。Telegram API 在国内被墙，curl 直连会静默超时（-s 加 check=False 还会把错误吞掉）。独立脚本里所有外网调用都要显式指定代理，且失败要可见（打印错误、非零退出码），不能静默。
落地检查清单
- 备份调度在系统 crontab，不在任何 AI 进程内
- 备份 ≥ 2 份异地 + 1 份本地
- VM 有 vzdump 定期快照（PVE 原生，应用层之上的兜底）
- 恢复脚本可 curl | bash 手动执行，文档人可读
- 所有外网调用显式走代理，失败不静默