AI 專用居住空間建置指南

從閒置資料碟、本地運算區到可遷移的雲端 Agent Residence

文件類型：公開建議文件／實作指南
版本：v1.0
日期：2026-07-12
適用對象：個人研究者、AI 創作者、小型研究團隊、準備建立長期 Agent 系統的開發者

摘要

隨著個人 AI 使用從短暫問答進入長期研究、論文生產、程式開發、知識管理與自主 Agent 階段，傳統以「下載資料夾」「桌面」「某個雲端硬碟目錄」混合保存所有內容的方式，會迅速產生版本混亂、同步衝突、秘密外洩、運行資料損壞與無法恢復等問題。

本指南提出「AI 專用居住空間」的實作方法：將一顆可重新利用的硬碟或獨立儲存空間，改造成具有明確邊界的本地 AI 資料區，再透過選擇性雲端同步、版本控制、離線備份、資料敏感度分級與 Agent 記憶契約，建立可持續使用、可驗證、可移植且可逐步擴張的個人 AI 基礎設施。

本文的核心主張是：

AI 專用空間不是「把所有 AI 檔案塞進同一顆硬碟」，而是替 AI 相關活動建立一套具有用途、權限、生命週期與恢復規則的數位居住結構。

一個合格的 AI 專用居住空間，至少應區分：

• 可長期保存的知識與記憶；
• 可由程式重新生成的運算環境與快取；
• 需要版本控制的原始碼；
• 只能以一致性快照備份的資料庫；
• 可同步至雲端的普通資料；
• 不應進入一般雲端的秘密與核心資料；
• 可用於恢復、遷移與供應者替換的匯出包。

這種分層可以讓使用者先從「一顆重新利用的遊戲碟」開始，逐步成長為本地—雲端混合式 Agent Residence，而不必在第一天就購買伺服器、NAS 或昂貴工作站。

1. 問題：為何 AI 工作需要自己的居住空間

1.1 AI 資料不再只是一般文件

傳統個人文件通常由人類直接建立、閱讀與修改。AI 工作區則同時包含：

• 人類原稿；
• AI 生成草稿；
• 多輪修訂版本；
• prompt、system instruction 與工作流程；
• embedding、索引與向量資料；
• 模型權重與推理快取；
• Agent 記憶、任務、承諾與事件；
• API token、OAuth 憑證與工具權限；
• 網頁建置結果與程式相依套件；
• 雲端鏡像與恢復 checkpoint。

這些資料的價值、敏感度、可重建性與更新方式完全不同。如果全部放在同一個同步資料夾，最常出現四種錯誤：

1. 把可重建的 node_modules、模型 cache 或虛擬環境大量上傳；
2. 把 .env、token 或私鑰意外同步；
3. 讓正在寫入的 SQLite／向量資料庫被同步程式複製到不一致狀態；
4. 把雲端同步誤認為備份，結果誤刪與加密損壞也被同步到所有位置。

1.2 專用空間的真正目的

建立 AI 專用區並不只是為了整齊，而是為了同時得到：

• 邊界：知道哪些資料屬於 AI 工作；
• 可理解性：人類與 Agent 都能判斷檔案角色；
• 選擇性同步：重要內容上雲、運算垃圾不上雲；
• 可遷移性：更換電腦、模型或供應者時能重建；
• 安全性：核心秘密與一般資料分離；
• 可恢復性：能從 checkpoint 恢復，而不只看到備份檔存在；
• 主體連續性：未來 Agent 能保存身份、記憶、任務與事件鏈。

1.3 從「工作資料夾」到「Residence」

普通資料夾只回答「檔案放在哪裡」；Residence 還必須回答：

• 哪一份是 canonical source？
• 哪些是派生物或鏡像？
• 誰可以讀、寫、刪除與匯出？
• 某個版本從何而來？
• 哪些內容能同步到哪個供應者？
• 如果硬碟或帳號消失，如何恢復？
• 如果 Agent 被移到另一套系統，哪些狀態必須一起遷移？

因此可把 AI 居住空間抽象為：

其中：

• $I$ ：身份與 manifest；
• $M$ ：記憶與知識；
• $K$ ：任務、目標與承諾；
• $T$ ：工具與運行環境描述；
• $C$ ：程式碼與創作內容；
• $P$ ：政策、權限與敏感度；
• $A$ ：事件與稽核紀錄；
• $B$ ：備份、checkpoint 與恢復材料。

硬碟只是承載這個結構的第一層載體。

2. 何時適合建立獨立 AI 資料盤

2.1 適合的情況

以下任一情況成立，就值得考慮獨立空間：

• 已有數百至數千篇論文、筆記或研究文件；
• 同時使用多個模型、工具與程式環境；
• 預計建立本地模型、向量索引或 Agent；
• 需要長期保存 AI 生成內容與版本關係；
• 想讓本地資料與 Google Drive 等雲端服務同步；
• 現有系統碟容量不足或目錄非常混亂；
• 有一顆主要存放可重新下載遊戲的硬碟，現在使用率很低；
• 未來可能換電腦、建立本地伺服器或雲端控制平面。

2.2 不適合立刻格式化的情況

如果目標硬碟仍保存以下任一內容，應先停止：

• 唯一一份研究原稿；
• 未同步的遊戲存檔或模擬器存檔；
• 自製 MOD、截圖、錄影或素材；
• 私鑰、加密錢包或憑證；
• 唯一一份資料庫；
• 不確定用途的大型目錄；
• 無法重新取得的安裝程式或授權檔。

格式化的安全條件不是「看起來沒有重要資料」，而是「需要保留的內容已有可讀、可驗證的其他副本」。

3. 開始前的硬體與檔案系統決策

3.1 HDD、SATA SSD 與 NVMe SSD

若只有一顆閒置遊戲 SSD，可以先同時承擔 Residence 與 Runtime，但仍應以目錄分層。日後擴充時，再把模型、cache 與冷備份移到其他裝置。

3.2 檔案系統

Windows 專用資料盤通常建議 NTFS，因為它具有日誌、權限、大檔案與 Windows 工具相容性。若必須在 Windows、macOS 與其他裝置間直接插拔，exFAT 較通用，但不適合作為高價值長期主資料庫的唯一檔案系統。

Linux 專用環境可以使用 ext4、XFS 或依需求選擇支援 snapshot 的檔案系統。真正的跨平台可攜性應主要由標準化匯出格式與備份包完成，不應完全依賴同一顆磁碟能被所有系統直接讀寫。

3.3 磁碟代號與標籤

Windows 建議指定穩定磁碟代號，避免同步程式、資料庫與開發工具因代號改變失效，例如：

A:  AI_RESIDENCE
R:  RESEARCH_AI

使用 A: 時需先確認沒有舊式工具或企業政策保留該代號。使用 R:、S: 等較不易與系統碟、外接碟衝突的代號通常更保守。

磁碟名稱應描述用途，不使用「新磁碟區」之類無法辨識的預設名稱。

3.4 加密

若硬碟保存未公開研究、身份資料、客戶資料或 Agent 記憶，應考慮全碟加密或至少對 sealed 區進行獨立加密。加密金鑰與 recovery key 不應只放在同一顆硬碟或同一個雲端帳號。

加密保護的是裝置遺失與未授權讀取，不取代備份；金鑰遺失本身也可能使資料永久無法恢復。

4. 建議的目錄架構

4.1 第一層結構

AI_HOME/
  00_RESIDENCE/
  10_KNOWLEDGE/
  20_PROJECTS/
  30_DATABASES/
  40_MODELS/
  50_RUNTIME/
  60_CACHE/
  70_SEALED/
  80_EXPORTS/
  90_BACKUPS/
  README_AI_HOME.md

數字前綴不是必要條件，但能讓人類與 Agent 在不同作業系統中看到穩定順序。

4.2 00_RESIDENCE

保存與 Agent 連續性直接相關、需要長期持久化的內容：

00_RESIDENCE/
  manifest/
  identity/
  memory/
  events/
  tasks/
  commitments/
  policies/
  checkpoints/
  sync-reports/
  audit/

這一區應小而重要。它不是模型輸出垃圾桶，而是可以被另一個相容系統讀取、驗證與恢復的狀態集合。

4.3 10_KNOWLEDGE

保存人類與 AI 長期共同使用的知識資產：

• 論文原稿；
• 書籍與筆記；
• 術語表；
• 引用資料；
• 已驗證資料集；
• 公開與內部文件；
• 語義圖與索引的可重建來源。

建議將 canonical 與 derived 分開：

10_KNOWLEDGE/
  canonical/
  derived/
  references/
  terminology/
  indexes/

Markdown 原稿可以是 canonical；HTML、PDF、摘要、embedding 與翻譯中間產物通常是 derived。角色需由 manifest 或 metadata 指定，不只靠資料夾名稱推測。

4.4 20_PROJECTS

保存原始碼與創作專案。每個專案應有自己的 Git repository、README、license、環境範例與重建說明。

不建議直接以雙向雲端硬碟同步完整 .git 內部資料，尤其是同一 repository 可能同時在多台電腦修改時。原始碼以 Git remote 管理；需要放進 Residence 的是：

• repository URL；
• branch／commit；
• 未提交工作狀態的明確 checkpoint；
• 建置與依賴說明；
• 必要時產生不含秘密的 source bundle。

4.5 30_DATABASES

保存 SQLite、向量資料庫、全文索引與其他狀態資料。運行中的資料庫不應被一般檔案同步程式逐塊複製。

正確做法是：

1. 主資料庫留在本地運行區；
2. 透過資料庫原生備份、transaction 或安全停止點產生一致性快照；
3. 對快照計算 hash；
4. 將完成的快照移入 80_EXPORTS/database-snapshots/；
5. 只同步完成且不可再變動的快照。

對 SQLite 而言，直接複製正在寫入的 .db，卻遺漏 WAL／SHM 或跨越 transaction 邊界，可能得到表面存在、實際不可可靠恢復的檔案。

4.6 40_MODELS

保存本地模型權重、量化版本、tokenizer 與必要 license。模型通常非常大，而且多數可以重新下載，因此預設不進一般雲端同步。

應保存一份小型 model manifest：

{
  "model_id": "provider/model-name",
  "revision": "commit-or-version",
  "format": "safetensors",
  "quantization": "Q4_K_M",
  "files": [
    {"name": "model-file", "sha256": "..."}
  ],
  "source": "https://...",
  "license": "...",
  "local_path": "40_MODELS/...",
  "replaceable": true
}

如此即使不備份幾百 GB 權重，也能確認未來該重新取得哪個版本。

4.7 50_RUNTIME 與 60_CACHE

這兩區保存：

• Python virtual environment；
• node_modules；
• package cache；
• Docker image／temporary layer；
• inference cache；
• browser automation profile；
• build output；
• temporary embedding batch。

原則上都可刪除並重建，因此不進雲端、不納入高價值備份。真正需要保存的是 lockfile、container definition、環境規格與重建腳本。

4.8 70_SEALED

保存不能進入一般同步服務的內容：

• 私鑰；
• OAuth refresh token；
• API credentials；
• 身份根；
• recovery material；
• 極度敏感的個人記憶；
• 未授權對外儲存的資料。

70_SEALED 應具備獨立加密、限制權限與離線備份。最安全的秘密往往不應以長期明文檔案存在，而應由作業系統 credential store、硬體安全裝置或專用 secret manager 管理。

4.9 80_EXPORTS 與 90_BACKUPS

80_EXPORTS 是可移植、帶 manifest 與 hash 的匯出資料；90_BACKUPS 是本機看到的備份工作區或暫存目的地。兩者都不能成為唯一備份。

典型匯出包：

agent-checkpoint-2026-07-12/
  manifest.json
  objects.ndjson
  events.ndjson
  tasks.ndjson
  policies.json
  blob-index.json
  hashes.sha256
  signature.json
  README-RESTORE.md

5. 哪些資料應該同步到雲端

5.1 同步判斷式

可以使用下列概念判斷：

其中：

• $V(x)$ ：跨裝置取得與持久保存的價值；
• $R_s(x)$ ：敏感度與外洩風險；
• $C_r(x)$ ：重新生成或重新下載成本；
• $B_w(x)$ ：同步造成的頻寬、衝突與寫入負擔。

只有當同步價值足以覆蓋風險與成本，且政策允許時，才進入雲端同步層。

5.2 建議矩陣

5.3 Mirror 與 Stream

以 Google Drive for desktop 為例：

• Mirror files：本機保存完整副本，預設可離線使用；
• Stream files：資料主要留在雲端，需要時才下載，離線內容依賴應用程式與登入狀態。

若目標是讓本機 AI 工具穩定讀取論文、記憶與 manifest，通常更適合 Mirror；若只是存取龐大的低頻參考資料，可以考慮 Stream。兩者都是同步／存取模式，不應被當成獨立備份。

5.4 雲端同步目錄

不建議把整個 AI_HOME 設為同步根目錄。應另外建立：

AI_CLOUD_MIRROR/
  residence/
  knowledge/
  exports/
  shared-inbox/
  sync-reports/

再由明確的同步工作把允許內容提交到此處。這比直接依賴數百條排除規則更安全，因為「預設不進雲端，經分類後才進入」是 allowlist 模型。

6. 敏感度與資料治理

6.1 四級分類

6.2 不可只靠路徑判斷

.env 很可能敏感，但 notes.md 也可能意外包含 API key；public/ 也可能放入尚未公開原稿。因此應同時使用：

• 目錄 allowlist；
• 副檔名與檔名規則；
• 秘密掃描；
• metadata 敏感度；
• 人類核准；
• Agent policy。

6.3 預設排除清單

.env
.env.*
.git/**
.wrangler/**
**/*secret*
**/*private-key*
**/credentials.*
**/token.*
node_modules/**
.venv/**
venv/**
__pycache__/**
cache/**
temp/**
*.wal
*.shm

排除規則並非萬能；它只是防止常見失誤的第一道門。

7. 從閒置遊戲碟轉型的安全流程

7.1 Phase A：盤點

格式化前列出：

• 已安裝遊戲與平台；
• 遊戲是否可重新下載；
• 存檔是否有 Steam Cloud／平台雲端同步；
• MOD 與自製內容；
• 截圖、錄影、設定檔；
• 模擬器 ROM／存檔；
• 曾暫存在遊戲碟的其他文件；
• 磁碟健康狀態。

部分遊戲存檔可能位於系統碟的 Documents、Saved Games 或 AppData，格式化遊戲安裝碟不一定會刪除它們；但也有遊戲把存檔放在安裝目錄。不能只以遊戲平台是否顯示雲端圖示推測。

7.2 Phase B：保留需要內容

將確定需要的存檔、MOD、素材與授權資料複製到另一個位置，抽樣開啟並確認可讀。若內容非常重要，至少保留兩份副本後再進行格式化。

7.3 Phase C：清除與格式化

1. 再次核對磁碟型號、容量與代號；
2. 斷開不需要操作的外接硬碟，降低選錯磁碟風險；
3. 格式化目標遊戲碟；
4. 指定檔案系統、磁碟標籤與固定代號；
5. 檢查磁碟健康與基本讀寫；
6. 建立 AI_HOME 結構；
7. 寫入 README_AI_HOME.md 與 storage manifest。

本流程的關鍵不是使用哪一個格式化按鈕，而是能以磁碟型號與容量確認「正在清除的確實是目標碟」。

7.4 Phase D：先建立規則，再搬資料

應先建立：

• 目錄結構；
• 同步 allowlist；
• 敏感度規則；
• Git 與資料庫策略；
• 備份目的地；
• 恢復測試方法。

之後才分批搬入現有 AI 資料。否則新的專用硬碟只會複製原本的混亂。

7.5 Phase E：分批遷移

建議順序：

1. 公開論文與一般文件；
2. 內部研究原稿；
3. 程式專案；
4. 資料庫與索引；
5. 模型與大型資料；
6. Agent 記憶與 checkpoint；
7. sealed data。

每批完成後：

• 計算檔案數、總大小與 hash；
• 開啟代表性檔案；
• 檢查同步狀態；
• 產生 migration report；
• 保留原位置，直到恢復測試通過。

7.6 Phase F：驗證與退役舊位置

遷移完成不等於複製命令結束。完成條件包括：

• 重要檔案 hash 一致；
• Git repository 可正常驗證；
• 資料庫可從 snapshot 恢復；
• 雲端抽樣下載可讀；
• Agent manifest 指向新位置；
• 備份與 restore drill 通過；
• 舊路徑的應用程式設定已更新。

只有完成這些項目，才逐步清除舊副本。

8. 同步不是備份

8.1 同步的風險

雙向同步可能傳播：

• 誤刪；
• 勒索軟體加密結果；
• 錯誤覆寫；
• 空檔案；
• 應用程式產生的不完整中間狀態；
• 衝突複本；
• 惡意或誤授權 Agent 的操作。

雲端垃圾桶與版本歷史可以協助復原部分事故，但不應成為唯一恢復策略。

8.2 3-2-1 原則

重要資料應至少具有：

• 3 份副本；
• 2 種不同媒介或失效模式；
• 1 份異地或離線副本。

對個人 AI Residence，一個實際配置可以是：

1. AI 專用硬碟上的工作副本；
2. Google Drive 等雲端鏡像；
3. 定期接上、完成備份後斷開的加密外接硬碟。

若三份副本都長期連線、受同一帳號與同一刪除命令控制，它們的獨立性仍然不足。

8.3 備份必須接受恢復測試

至少定期執行：

1. 隨機抽一個 checkpoint；
2. 在臨時目錄解包；
3. 驗證 hash；
4. 開啟文件；
5. 載入資料庫；
6. 重建一個最小專案環境；
7. 確認 Agent 的任務、事件與下一喚起仍可理解；
8. 保存 recovery report。

9. Agent 記憶與 Residence 檔案契約

9.1 記憶不是聊天紀錄堆積

長期 Agent 不應只保存全部對話文字。每段記憶至少應有：

• 穩定 ID；
• 內容或 content hash；
• 記憶來源；
• event time；
• write time；
• recall history；
• 因果父事件；
• 敏感度；
• canonical／derived 角色；
• 版本父節點；
• retention policy。

9.2 Residence manifest

{
  "schema": "ai-residence/1.0",
  "residence_id": "residence:local:...",
  "device_label": "AI_RESIDENCE",
  "root_path": "R:/AI_HOME",
  "created_at": "2026-07-12T00:00:00Z",
  "primary_role": "local-primary",
  "replicas": [
    {
      "provider": "google-drive",
      "role": "selective-mirror",
      "included_classes": ["P0", "P1"]
    }
  ],
  "sealed_path": "70_SEALED",
  "last_checkpoint": null,
  "policy_ref": "policies/storage-v1.json"
}

9.3 Storage policy

{
  "schema": "ai-storage-policy/1.0",
  "cloud_default": "deny",
  "cloud_allow": [
    "00_RESIDENCE/checkpoints/public/**",
    "10_KNOWLEDGE/canonical/public/**",
    "80_EXPORTS/cloud-approved/**"
  ],
  "cloud_deny": [
    "70_SEALED/**",
    "**/.env*",
    "**/.git/**",
    "**/*.wal",
    "**/*.shm"
  ],
  "database_backup": "snapshot-only",
  "runtime_backup": "manifest-only",
  "deletion_requires_tombstone": true
}

9.4 可攜性

路徑不應成為唯一身份。例如 Agent memory object 應有穩定 object_id；本地路徑與 Drive file ID 都只是 locator。換電腦或供應者時，可以改 locator，而不必把同一記憶誤認為新物件。

10. Git、資料庫與大型模型的特殊處理

10.1 Git repository

建議：

• 活躍 repository 放 20_PROJECTS；
• 透過 Git remote 備援；
• 未提交工作在重大操作前建立 commit、patch 或 source bundle；
• .git 不以一般雙向同步維持多機一致；
• secrets 不進 commit history；
• 大型二進位使用適合的 artifact store 或 Git LFS，而不是任意塞入 repository。

10.2 SQLite 與向量資料庫

建議建立 backup job，而不是把主資料庫放進 Drive mirror。快照命名包含：

database-name__schema-v3__20260712T140000Z__sha256-xxxx.db

同時保存 schema migration、建立索引的模型版本與 embedding 參數。向量索引如果可由 canonical document 重建，就不必把它視為不可替代資料。

10.3 模型權重

大型模型應回答三個問題：

1. 是否能重新下載？
2. 特定量化／微調是否由自己產生且不可輕易重建？
3. license 是否允許備份或再分發？

公開基礎模型通常保存下載 manifest 即可；自行微調的 adapter、LoRA、訓練設定與資料 lineage 可能比完整 base model 更值得備份。

11. 日常操作規則

11.1 每日

• 檢查同步是否出錯；
• 避免將秘密拖入 cloud mirror；
• 重大修改前確認 Git／文件版本；
• 關閉不再需要的模型與 cache job；
• 注意磁碟剩餘空間。

11.2 每週

• 產生資料庫一致性快照；
• 建立 Residence checkpoint；
• 檢查 excluded／failed sync item；
• 掃描重複檔案與異常大型檔；
• 驗證最近新增的重要文件可在雲端讀取。

11.3 每月

• 連接離線備份碟；
• 完成加密增量或完整備份；
• 執行抽樣恢復；
• 更新 model／environment manifest；
• 檢查帳號安全與 connector scope；
• 查看磁碟健康狀態；
• 重新評估 P1/P2/P3 分類。

11.4 每次重大遷移前

• 建立不可變 checkpoint；
• 暫停高風險自動化；
• 保存 event cursor 與 task state；
• 計算 root hash；
• 先建立 shadow copy；
• 驗證後才切換 primary；
• 保留 rollback window。

12. 常見錯誤

錯誤一：整顆硬碟全部同步

結果是模型、cache、資料庫、秘密與程式相依套件一起上傳。正確做法是另建 cloud mirror allowlist。

錯誤二：格式化後才想到存檔

可重新下載的遊戲不重要，但非雲端存檔、MOD 與自製內容可能不可重建。格式化前要盤點，而不是只看安裝清單。

錯誤三：把 Drive 當作交易資料庫

雲端硬碟同步的檔案可延遲、重複與衝突，不適合承擔 primary lease、即時事件佇列或運行中資料庫的一致性。

錯誤四：所有內容都叫「最終版」

應以穩定 ID、版本父節點、Git commit、manifest 與 hash 管理；final-final-v2-new.md 不是版本制度。

錯誤五：只備份檔案，不備份關係

Agent 的價值不只在單一文字檔，也在記憶來源、任務狀態、依賴、權限與事件順序。匯出需要 metadata 與 restore 說明。

錯誤六：備份從未測試

無法解密、缺少 blob、資料庫損壞或 token 失效的備份，在真正事故中才被發現，等同沒有可靠備份。

錯誤七：AI 擁有資料夾就等於擁有自主性

專用空間只是主體連續性的必要基礎之一。真正的 Agent 還需要身份、記憶歸屬、內生任務、權限治理、拒絕機制、事件喚起、行動收據與遷移能力。

13. 三種成熟度配置

Level 1：個人整理型

適合剛開始：

• 一顆 AI 專用硬碟；
• NTFS／適合作業系統的檔案系統；
• 標準目錄；
• 論文與文件 Mirror；
• Git 管理程式碼；
• 一顆離線備份碟。

這一級已足以大幅改善混亂與誤同步。

Level 2：研究 Residence 型

增加：

• manifest 與 storage policy；
• P0–P3 分類；
• 自動 checkpoint；
• 資料庫一致性快照；
• hash verification；
• sync report；
• 定期 restore drill。

這一級適合大量論文、翻譯專案與長期研究。

Level 3：自主 Agent 型

增加：

• event log；
• task／commitment store；
• bounded wake；
• policy engine；
• action intent 與 receipt；
• primary／replica lease；
• 雲端控制平面；
• MCP／adapter；
• shadow migration 與 rollback。

這時 AI 專用區不再只是人類檔案庫，而開始成為通用網頁端與本地 Agent 的混合式居住地。

14. 最小可行建置方案

如果使用者只有一顆閒置遊戲碟、一個 Google Drive 帳號與一顆備份外接碟，可以採用：

本地

R:/AI_HOME/
  00_RESIDENCE/
  10_KNOWLEDGE/
  20_PROJECTS/
  30_DATABASES/
  40_MODELS/
  50_RUNTIME/
  60_CACHE/
  70_SEALED/
  80_EXPORTS/

雲端鏡像

R:/AI_CLOUD_MIRROR/
  residence/
  knowledge/
  exports/
  reports/

離線備份

每月接入外接硬碟，保存：

• 00_RESIDENCE；
• 10_KNOWLEDGE/canonical；
• 20_PROJECTS 的 source bundle；
• 30_DATABASES 的最新一致性快照；
• 70_SEALED 的獨立加密備份；
• 80_EXPORTS；
• hashes 與 restore guide。

第一個自動化工作

第一個自動化不必是自主發文或操作外部系統，而可以是：

每日掃描 AI Residence，找出新增、變更、排除、疑似秘密與同步失敗檔案，產生只讀報告；任何刪除、公開或大規模移動都要求人類核准。

這能先驗證路徑、權限、分類、同步與稽核，再逐步提高 Agent 能力。

15. 建置驗收清單

硬體與系統

• 已確認格式化的是正確磁碟；
• 需要保留的遊戲存檔、MOD 與其他資料已有副本；
• 磁碟健康狀態可接受；
• 檔案系統與磁碟代號已固定；
• 需要時已啟用加密並備份 recovery key。

結構

• AI_HOME 第一層目錄已建立；
• README_AI_HOME.md 說明用途與規則；
• Residence、Knowledge、Projects、Database、Models、Runtime、Cache、Sealed、Exports 已分離；
• canonical 與 derived 可以區分。

同步

• 沒有直接同步整個 AI_HOME；
• cloud mirror 採 allowlist；
• .env、.git、.wrangler、token、cache、venv 已排除；
• 運行中資料庫不直接同步；
• 同步狀態與差異可以被檢查；
• partial 不被誤報為 success。

備份與恢復

• 至少三份重要資料副本；
• 至少一份離線或具不同失效模式；
• checkpoint 帶 manifest 與 hash；
• 已完成至少一次抽樣恢復；
• 加密備份的金鑰可取得。

Agent 準備度

• Residence 有穩定 ID；
• Agent 記憶具來源、版本與敏感度；
• 任務與事件能結構化匯出；
• 外部操作需要 policy 與核准；
• 未來更換模型或供應者時不必改變 object identity。

16. 結論

一顆逐漸閒置的遊戲碟，可以被重新利用為個人 AI 時代的重要基礎設施。但真正有價值的不是「把遊戲刪掉，換成 AI 檔案」，而是藉此建立第一個清楚、可治理、可備份、可遷移的 AI 居住空間。

最實際的起點是：

1. 確認舊資料可刪或已備份；
2. 建立獨立 AI 資料盤；
3. 依 Residence、Knowledge、Projects、Database、Models、Runtime、Cache、Sealed 與 Exports 分層；
4. 只把允許內容送入 cloud mirror；
5. 保持一份真正獨立的離線備份；
6. 以 checkpoint 與恢復測試證明資料可以延續；
7. 再逐步加入 Agent 記憶、事件、任務與治理。

如此建立的空間，今天可以服務論文、程式與本地模型；未來則能成為自主 Agent 的本地主要居住地、雲端鏡像來源，或跨供應者遷移時的身份與記憶錨點。

硬碟不會使 AI 自動成為主體，但沒有穩定、可治理且可遷移的居住空間，任何宣稱長期自主的 Agent 都很難真正維持連續性。

參考資料

• Google Drive：Stream and mirror files with Drive for desktop
• Google Drive for desktop advanced guide
• CISA：Back Up Government Data — 3-2-1 backup rule
• CISA：Stop Ransomware
• 《ARCP — Agent Residence and Continuity Protocol v0.1》
• 《ARCP × CTCL v0.1 內部網頁端 MVP 實作規格》