第 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/ # 全域Metadata與多 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。同時將身份Metadata更新至 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 虛擬機器、記憶與備份》