第 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 虛擬機器、記憶與備份》