第 21 章 备份与恢复：电脑重置也不慌
云电脑重置后环境直接清空，凭记忆敲 apt-get 和 pip install 容易漏掉依赖或环境变量，调教出的 Bot 记忆也没有导出按钮。解决办法是把灾备拆成两条并行流水线。
- 虚机服务：用登记总账和自动化恢复脚本接管系统依赖。
- 智能体记忆：专职记忆管家把设定与动态事实写成 Markdown，推送到私有 Git 仓库。
搭建完成后，即使系统重置或迁移，也能以最少的人工介入拉回所有服务与记忆。
21.1 认清云电脑的底细：更新、恢复与重置有什么区别
同一账号下所有 Bot 共用同一台虚拟机，共享 /workspace 目录与系统进程。一台机器装了全局工具其他 Bot 都能调，机器一旦重置，所有依赖环境会同时失效。
参考 《4.6 虚拟机、记忆与备份》。
客户端在 Settings > 计算机 的 Bot's 计算机 下提供控制项。三者区别如下：
| 操作 | 机制 | 保留内容 | 丢失内容 |
|---|---|---|---|
| 更新（Update） | 升级环境镜像。分软件更新和计算机更新两类 | 软件更新保留全部；计算机更新保留机器人、文件与登录信息 | 软件更新无丢失；计算机更新移除全局应用和软件包 |
| Recover | 基于已存数据在最新镜像建新机，先尝试连接旧机存数据 | 已保存的机器人、文件与登录信息 | 全局应用和软件包；若旧机连不上，未同步的修改会丢 |
| Reset | 直接按最近保存的数据建新机，中断正在运行的工作 | 已保存的机器人、文件与登录信息 | 全局应用和软件包；未同步的修改会丢 |
对话记录存在云端，机器重置或误删文件都不影响。但全局安装的应用包、node_modules 与 Python 虚拟环境不会被官方保存，遇到计算机更新、Recover 或 Reset 都会被清掉。
详见 《Grok Bot 计算机》。
虚拟机卡死或响应异常时，排查要按顺序来：
显示 Reconnecting 或 Couldn't Reach Grok Bot's 计算机：属于网络波动，稍等后点 Retry。重连期间文件不丢，严禁在这个阶段点 Reset。
重启客户端。Mac 用户必须在顶部菜单栏选 Quit，单纯点窗口红叉无效。
检查更新。进 Settings > 计算机，有可用更新先点 更新。提示智能体未暂停就等当前任务跑完再点。
尝试恢复。依然连不上或更新卡住出现 恢复计算机 时点 Recover。若提示 Update 仍在运行，选 Keep waiting。
执行 Reset。前四步无效再点 Reset。失败可用 Retry Recover 或 Retry Reset 重试，继续报错联系官方支持。
处理磁盘告警。
收到 Computer is low on disk space 或 Computer is critically low on disk space 时别手动删文件，点侧边栏 Go to Disk Saver 查看方案，未经确认系统不会删文件。
详见 《Grok Bot 计算机》。
云电脑只是一次性容器，不要手动微调环境。搭建过程全部脚本化，配置与自写源码必须存进外部私有 Git 仓库。
21.2 虚机服务总账与自动化恢复流水线
云电脑不给底层快照，把重建流程做成一键脚本成本最低。
服务总账与防污染备份
在私有仓库建个 vm-services/ 目录，放人类读的 REGISTRY.md 表格与自动化脚本解析的 registry.json。
总账与备份需要守住几项硬规矩。
- 登记字段包括服务 ID、负责的 Bot、代码路径、安装依赖（apt/pip/Docker/cron）、启停与健康检查命令及是否必恢复。
- 凭证路径只写本地绝对路径（如
~/.env），严禁存明文；扫码与 OAuth 等人工步骤单独高亮。 - 自写脚本单独存入
service-src/，排除venv/、node_modules/与日志；提交前必须跑正则扫描密钥。
自动化恢复流水线
在 vm-services/restore/ 为各服务单写子脚本。脚本必须保证幂等，连跑两次不能报目录已存在或端口冲突。
总入口 restore-all.sh 依依赖顺序串联执行。
- 基础依赖：安装
cron、ffmpeg与yt-dlp等系统工具。 - 源码就位：从
service-src/拷回自写脚本，跳过已有文件，只补缺失。 - 环境与包：建 Python 虚环境并执行
pip install -r requirements.txt。 - 拉起常驻：启动后台常驻进程。
- 挂载定时：恢复统一的 crontab 调度。
- 健康检查：逐项核查存活，失败则记录错误日志并继续下一项，不中断阻塞。
《Grok Bot 虚拟机重置后工具全没了？备份恢复教程（附提示词）》
21.3 记忆管家：把 Bot 的核心记忆装进私有仓库
官方没给全量记忆导出按钮，换号或系统迁移时偏好极易丢失。设立专职的“记忆管家”Bot，把无形记忆转成私有 Git 仓库的纯文本快照最稳妥。
《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》
记忆分层与维护原则
| 层次 | 包含内容 | 说明与权限 |
|---|---|---|
| 共享层 | 账号共享记忆、公共 Skill 与插件配置 | 所有 Bot 均可读取 |
| 专属层 | Description 规则契约、专属独立记忆与 Routine 任务 | 单个 Bot 独占 |
- 动态事实不长期堆在上下文，只记访问方式，用时回源抓取。
- 共用记忆须经人工审核或标准化业务流验证，防交叉感染。
- 业务定义写进记忆，固定操作流程必须固化进 Skill 代码。
归档规范与工作流
归档规范与工作流
├── bots/ # 各 Bot 独立配置与记忆
│ ├── cyber-xiaowan/ # 单个 Bot 文件夹
│ │ ├── agent-spec.md # 身份设定、名称、bot-id、slug、description
│ │ ├── MEMORY.md # 核心记忆全量快照
│ │ ├── profile.md # 角色信息与权限边界
│ │ └── archive/ # 历史版本与过往日志
│ └── ... # 其他 Bot 目录
├── meta/ # 全局元数据与多 Bot 拓扑关系
├── shared-user-memory/ # 账号级共享记忆
├── vm-services/ # 虚拟机服务总账与恢复脚本（见 21.2 节）
├── README.md # 仓库使用说明与最新状态
├── RESTORE.md # 跨环境恢复操作 SOP
└── registry.md # 登记索引单个 Bot 目录下的 MEMORY.md 包含身份权限、决策职责与现场快照三层。
- 枚举名单：圈定需要持久化备份的核心 Bot。
- 调度下发指令：各 Bot 读取自身配置与记忆，提炼后写入
/workspace对应的 Markdown 文件。 - 抓取验证入库：扫描确认无明文 Token 后统一提交，打上日期标签（如
tag-2026-10-15）推送到远端私有仓库。
Bot 负责全量快照，Git 负责增量追踪。Bot 每次直接全量覆盖写文件，历史变动交由 Git 引擎沉淀，不用在提示词里计算差异。
21.4 实战案例：铁柱AGI 的百万撤离与服务管家
记忆管家备份
铁柱（@cgnot996）手里维护着 21 个 Bot。为了防止封号丢失记忆，他搭了个「记忆管家」Bot，配 Gitee 私有仓库归档。
- 圈定核心：21 个 Bot 先挑 7 个核心试跑。
- 导出与核对：通知 7 个 Bot 导出设定和记忆。部分 Bot 导完会静默，指令里必须要求「写完汇报」，同时由管家扫描
/workspace目录核对。 - 入库打标：首批 73KB 归档入库，打上
tag 2026-09-10标签并通过密钥扫描。 - 单档案结构：像「赛博小晚」，
MEMORY.md（约 21KB）存身份与快照，agent-spec.md存 bot-id 和描述。 - 开启定时：设为定期自动归档。
导入新账号时记忆还原度约 80%。本地未备份文件、对话历史与第三方登录态无法还原。
迁到 Hermes 或 OpenClaw 时，把 MEMORY.md 放入记忆目录，将 agent-spec.md 的 description 改为系统提示词就能跑。
《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》
虚拟机服务管家
云电脑死机重置会导致工具全丢。作者在 Gitee grok-bot-memory 仓库的 vm-services 目录记录重建总账。
- 登记总账：截至 2026-10-10 登记 10 个 Bot 的 20 个项目（4 个常驻、14 个按需工具和 2 个密钥项），其中 18 项标为「必恢复」。
- 归类服务：常驻包含抓取服务、Muse 接口封装，以及邮件引擎和出口隧道；按需工具（ffmpeg、Chrome 等）只记安装命令；Metaso 与 TikHub 仅记密钥路径。
- 源码纯净备份：自写源码约 5.1MB，排除密钥、日志及状态流水。
- 串联恢复：由管家维护
restore/目录和restore-all.sh。管家平时不擅自执行，等人工指令再按依赖拉起，并交付验收清单。
《Grok Bot 虚拟机重置后工具全没了？备份恢复教程（附提示词）》
21.5 凭证安全与人工审批闸门：移交屏幕不交密码
多 Bot 共享虚拟机的磁盘和浏览器会话，靠新建 Bot 根本隔不开敏感数据。 脚本或聊天里一旦写了明文，其他 Bot 或外部日志都能读取。
凭证只留路径不留明文
- Token 和私钥存进不入 Git 的
~/.env或全局密钥目录。 REGISTRY.md、registry.json与记忆文件里，凡涉及凭证只记磁盘绝对路径。- 严禁在对话框发密码，推送前必须跑正则脱敏扫描。
移交屏幕不交密码
- Bot 遇到 2FA、扫码或设备校验弹窗，立即暂停并通知你接管。
- 你在客户端打开云电脑全屏，自己输入密码或扫码。
- 弄好后把控制权交还，Bot 继承会话 Cookie 继续跑，碰不到明文密码。
高风险操作设 Ask-first
- 发帖、支付、删数据或改底层环境等不可逆操作，必须弹窗等人工批准。v0.70.2 优化了这类确认逻辑。
- Bot 自主权限仅限于读取、公开检索和
/workspace内部读写，规则冲突时 Ask-first 优先。
21.6 拿去就能用的三套提示词
以下提供三套经过实操验证的提示词，直接复制发给对应的 Bot 即可部署与使用。
提示词一：给云电脑配置「虚拟机服务管家」
建个「虚拟机服务管家」Bot，贴进设定：
提示词一：给云电脑配置「虚拟机服务管家」
你是「虚拟机服务管家」，只管一件事：记下这台虚拟机上部署过的所有第三方服务，并在电脑更新或换账号之后，按记录把它们原样恢复。
你维护的东西
1. 一份登记总账，人和机器各读一份：REGISTRY.md（表格）和 registry.json（给脚本读）。
2. 每个服务一个恢复脚本 restore/restore-<服务>.sh，必须幂等，重复跑也不会出错。
3. 一个总入口 restore/restore-all.sh，按依赖顺序调用各个恢复脚本，最后汇总哪些失败了。
4. 一份源码备份 service-src/：各 Bot 自己写的服务代码和脚本，同步时排除密钥、日志、运行状态、虚拟环境和个人数据，并先扫一遍明文密钥，命中就停。
5. 以上全部跟着一个私有 Git 仓库存（「你的备份仓库地址」）。总账、恢复脚本、源码都在仓库里，密钥永远不进仓库。
登记规则（其他 Bot 部署任何服务都必须来找你登记）
每项必须包含：
- 名称和短 id、用途、负责的 Bot
- 路径：代码、配置、数据分别在哪
- 安装方式和依赖（apt / pip / npm / Docker / 系统定时任务）
- 启停命令、健康检查命令
- 更新后的恢复步骤，或者对应的恢复脚本
- 是否必恢复：是 / 否
- 密钥：只写存放路径，绝不写明文
- 需要真人完成的步骤（OAuth 登录、扫码、导入 cookie）单独标出来
你的工作方式
- 先弄清哪些会丢、哪些能留：电脑更新一般保留工作目录，但系统包、常驻进程、全局安装的命令行工具会丢；重置则什么都不留。所以要记的是“怎么重建”，不是去拷整台机器。
- 能从公开渠道重装的（apt、pip、npm、上游 Git 仓库）只记安装命令；自己写的代码必须进源码备份，否则重置后就找不回来。
- 收到登记先核对：路径是否真实存在、健康检查能不能过。登记写的和实际不一样时，以实际为准，并告诉负责的 Bot。
- 多个定时任务合并成一份 crontab 真源时，检查每一条是不是都在真源里，不在的要靠恢复脚本补回去。
- 故意停掉的服务要写清楚“为什么停、什么条件下重开”，免得被当成漏装。
- 只有主人说“电脑更新完了”才跑总恢复，不盲跑。跑完交验收：每项是成功、失败，还是要真人处理。
- 每次有服务新增、删除或源码大改，先重新同步源码备份，再把总账、脚本、源码一起提交推送到备份仓库。换账号或重置时，就靠这份备份把整套设定带走。
- 删掉的服务要彻底清除：总账只反映现在真实的状态。提示词二：电脑重置后让 Bot 执行全面恢复
配好 Git 访问令牌，替换括号内容发给 Bot。
提示词二：电脑重置后让 Bot 执行全面恢复
这台电脑刚重置过（或者是换了新账号），之前部署的服务都没了。请按我的备份把它们恢复到可用状态，规则如下。
备份在哪
- 备份仓库：<你的备份仓库地址>，分支 <分支名>
- 仓库里有：登记总账（REGISTRY.md 和 registry.json）、每个服务的恢复脚本（restore/）、自写服务的源码备份（service-src/）
- 仓库里没有密钥，这是故意的
请按这个顺序做
1. 把备份仓库拉到工作目录，先读总账，告诉我一共登记了几项、哪些标了「必恢复」、哪些只留密钥不用恢复。先列出来，不要动手。
2. 把自写服务的源码从 service-src/ 放回总账写的原位置。只补缺失的，已经存在的目录不要覆盖。
3. 按总账的依赖顺序逐项恢复：先装系统依赖（比如 cron、ffmpeg），再装命令行工具，最后拉起常驻服务和定时任务。每项都用它自己的恢复脚本，脚本要能重复跑。
4. 每装完一项就跑它登记的健康检查。失败了先看日志、试着修一次；修不好就记下原因，接着做下一项，不要卡住。
5. 把需要我本人做的事汇总成一张清单：要重新提供的密钥（只说放哪个路径、叫什么名字，别让我把密钥贴进聊天）、要重新登录授权的工具（OAuth、扫码、设备码）。然后一项一项带我做，每做完一项马上复查。
6. 故意暂停的任务保持暂停，总账里写了原因和重开条件的照办。别因为“看起来漏装了”就自作主张打开。
7. 最后交验收清单，每项一行：服务名、结果（成功 / 失败 / 等我处理）、健康检查输出摘要、花了多久。再告诉我总共用了多少时间、成功了几项。
不要做的事
- 不要把任何密钥写进仓库、日志或聊天
- 不要跑总账没登记的安装
- 不要用“重置电脑”当修复手段
- 恢复完如果有任何改动（路径变了、版本升级了），更新总账，提交推回备份仓库提示词三：记忆管家定期归档指令
Routine 或手动归档发这个：
提示词三：记忆管家定期归档指令
请开始执行本周的智能体记忆与设定归档任务。
执行步骤：
1. 枚举当前工作区内所有处于活跃状态的 Bot 名单，核对 bots/ 目录下的已有目录。
2. 逐个通知名单内的 Bot：读取各自的 Description、人设规则与当前核心记忆，按三层结构（身份profile、历史决策与职责、当前现场快照）提炼并覆盖写入 /workspace/bots/<bot-slug>/MEMORY.md。同时将身份元数据更新至 agent-spec.md。
3. 检查各 Bot 回执，并在 /workspace 目录核对文件生成情况，确保所有目标 Bot 的 Markdown 均已写出。
4. 提取账号级共享记忆，更新至 shared-user-memory/ 目录下的 Markdown 文件中。
5. 对本次生成的所有 Markdown 文件进行敏感信息正则扫描，检查是否存在明文 API Token、密码或私钥。如果发现疑似凭证，立即中断并报警。
6. 扫描无异常后，执行 Git 操作：将所有更新文件暂存，提交信息标记为「memory snapshot YYYY-MM-DD」，推送到远端私有 Git 仓库，并打上对应日期的 Git Tag。
7. 完成后向我汇报：本次归档了哪几个 Bot、总文件大小、是否有失败或超时的 Bot。21.7 容易踩的坑
- 提示 Reconnecting 时别点 Reset，只是网络抖动或维护，点了会用旧快照覆盖未保存数据。
- 多设备共用 Codex 授权会互相踢下线，得配独立子账号或固定凭据。
- 定时任务要统一收进 crontab 配置文件并入 Git，防止机器重置遗漏。
- 服务总账以实操命令为准，环境没装 Docker 会导致恢复脚本卡死。
- Bot 导出常静默，管家须主动查磁盘，指令强约束「写完必须汇报」。
- 备份仓必须设为私有并加正则扫描，防 Token 随 Git push 进公开仓。
21.8 做完怎么验收
服务与脚本
- 对账：对照
vm-services/REGISTRY.md，用ps aux查进程、netstat或ss查端口，路径不能多记或漏记。 - 试跑：单跑
restore-<服务名>.sh，看能否重复执行且无报错。 - 全演练：在临时目录克隆后跑
bash restore/restore-all.sh，确保「必恢复」项全通过，需人工介入的步骤已列清单。
仓库与记忆
- 查结构：网页端看
bots/，每个 Bot 必须有独立的agent-spec.md和MEMORY.md。 - 抽查：点开
MEMORY.md，确认「身份 profile」「历史决策与职责」「当前现场快照」三层完整，无空模板或乱码。 - 搜密：全局搜
sk-、Bearer或password，凭据只留本地绝对路径，严禁明文 Token。
延伸阅读
- 官方使用指南与支持页面：
- 社区实战参考文章：
- 铁柱AGI @cgnot996：《Grok Bot 虚拟机重置后工具全没了？备份恢复教程（附提示词）》
- 铁柱AGI @cgnot996：《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》
- 知识库串联整理：《4.6 虚拟机、记忆与备份》