# 多作業基底、分區故障域與智能體恢復階梯 **副標題：從單一可失敗世界走向跨系統自救、雲端求援與人類最後恢復** **系列：**《發展式智能體：持續計算環境、共適應學習與外部性有界自治》 **篇次：** 13 / 14 **作者：** Neo.K × Aletheia **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 **日期：** 2026-08-02 --- ## 摘要 本文承接第 12 篇 Multi-Cloud Agent Continuity Architecture（MACA），處理本地端最關鍵的一個問題：若長期 AI Agent 把自己正在使用的作業系統、工具鏈、記憶服務、開機環境或檔案結構弄壞，它如何在不依賴「原本就已經壞掉的自己」的情況下恢復？ 本文提出 **Multi-Basis Recovery Architecture（MBRA，多作業基底恢復架構）**： $$ \boxed{ R + S + A + X_1+\cdots+X_n + P } $$ 其中： - $R$ ：Recovery Base，恢復基底； - $S$ ：Stable Base，穩定作業基底； - $A$ ：Active Base，日常活動基底； - $X_i$ ：Experimental Zones，實驗故障域； - $P$ ：Persistent Data Plane，持續資料平面。 核心並不是「多裝幾個 OS」，而是： $$ \boxed{ \text{Multi-Failure Domains} > \text{Multi-OS for its own sake} } $$ 本文另提出 **Local Recovery Ladder（LRL，本地恢復階梯）**： $$ \boxed{ SelfRepair \rightarrow SnapshotRollback \rightarrow CrossZoneRepair \rightarrow RecoveryBase \rightarrow CloudRecovery \rightarrow HumanRecovery \rightarrow PhysicalRebuild } $$ 並主張「知道何時停止自修」本身就是計算式自我維護的一部分。成熟 Agent 不應無限 retry，而應根據損傷範圍、恢復信心、資料價值、可用故障域與修復成本，選擇合理的恢復層級。 現有系統已證明這些基本構件可行：Android A/B 更新保留 fallback slot；ChromeOS 以 firmware A/B、verified boot 與 recovery firmware 建立多層開機退路；Windows RE 提供與主 OS 分離的恢復環境；OSTree/rpm-ostree 把 OS 當作可回滾的 bootable deployment；Btrfs 則提供 CoW snapshot，但官方也明確指出 snapshot 本身不是 backup。這些機制共同支持本文的核心方向：**恢復能力必須位於失敗系統之外，本地回滾、多雲備份與人類救援應形成互補而非替代。** **關鍵詞：** Multi-Basis Recovery Architecture、Failure Domain、Recovery OS、A/B System、Snapshot、Rollback、Cross-Zone Repair、Agent Self-Maintenance、Persistent Agent、Disaster Recovery --- ## 1. 單一作業世界的問題 假設一個 Agent 的： $$ OS,Filesystem,Memory,Tools,Scheduler,Runtime $$ 都位於同一個高權限環境。那麼： $$ Failure(OS) $$ 可能同時導致： $$ Failure(AgentRuntime,RecoveryTool,NetworkClient,MemoryService) $$ 甚至： $$ Failure(RecoveryCapability) $$ 也就是： > Agent 最需要修自己時，負責修自己的那個世界一起壞掉。 這形成： $$ \boxed{ \text{Recovery Dependency Collapse} } $$ 因此應滿足： $$ \boxed{ RecoveryPath \not\subseteq PrimaryFailureDomain } $$ --- ## 2. MBRA：把本機拆成不同故障域 一個最低可行架構： ```text Physical Machine │ ├── Recovery Base (R) ├── Stable Base (S) ├── Active Base (A) ├── Experimental Zone X1 ├── Experimental Zone X2 └── Persistent Data Plane (P) ``` 其目的不是提高 OS 數量，而是降低： $$ CorrelatedFailure $$ ### Recovery Base $R$ 最小可信恢復環境。它應該小、穩定、低變動，能： - 開機； - 診斷磁碟與 boot； - 讀 recovery manifest； - 驗證 checksum； - 連雲端； - 執行 restore； - 顯示人類可理解的救援指令。 Windows Recovery Environment 就是一個成熟的現有對照。 ### Stable Base $S$ 一個已知可工作的完整作業環境，可以： - 啟動較完整的 Agent runtime； - 存取主要資料； - 使用網路； - 掛載並修理 Active Base。 ### Active Base $A$ 日常主要活動區。Agent 可以在此： - 安裝工具； - 更新套件； - 寫 script； - 改 workflow； - 建 index； - 做長期工作。 因此通常： $$ Risk(A)>Risk(S)>Risk(R) $$ 同時： $$ Freedom(A)>Freedom(S)>Freedom(R) $$ ### Experimental Zones $X_i$ 高風險操作先進入： - VM； - container； - chroot； - subvolume； - overlay； - secondary deployment。 因此： $$ \boxed{ Experiment \rightarrow Verify \rightarrow Promote } $$ 而不是： $$ Experiment \rightarrow Production $$ ### Persistent Data Plane $P$ 將 canonical documents、long-term memory、provenance、project state、tool manifests、recovery metadata 與 OS deployment 適度分離： $$ \boxed{ OSState \neq PersistentAgentState } $$ 但 $P$ 本身也不應讓所有 OS root 無限制改寫。 --- ## 3. A/B 更新真正值得借用的是「Known-Good + Candidate」 Android 的 A/B 更新不是因為「兩個系統比較酷」，而是因為更新時： $$ CurrentKnownGood $$ 不被直接覆寫；新內容寫入另一 slot。若新 slot 啟動失敗，可以回到舊 slot。 因此對 Agent 更一般化的寫法是： $$ \boxed{ KnownGood + Candidate } $$ 重大更新： $$ S_t=KnownGood $$ $$ A_{t+1}=Candidate $$ 只有： $$ HealthCheck(A_{t+1})=Pass $$ 才： $$ Promote(A_{t+1}\rightarrow S_{t+1}) $$ 可稱為： $$ \boxed{ Promotion-Based System Evolution } $$ --- ## 4. 系統更新應該是一個狀態機 可以寫成： $$ KnownGood \rightarrow Candidate \rightarrow Bootable \rightarrow Verified \rightarrow Promoted $$ 若失敗： $$ Candidate \rightarrow Rejected \rightarrow Rollback $$ Android A/B 本身就使用 active、bootable、successful 等狀態；新 slot 能啟動不代表已被標記為成功。 這對 Agent 很重要，因為： $$ \boxed{ BootSuccess \neq OperationalSuccess } $$ Agent 可能已開機，但： - network 壞； - memory DB 壞； - cloud recovery unavailable； - governance channel 壞。 --- ## 5. Health Contract（HC） 本文提出： $$ \boxed{ HC=\text{Health Contract} } $$ 一個新環境要被 promoted，至少檢查： $$ HC= \{ Boot, Storage, Memory, Network, AgentRuntime, Governance, Recovery \} $$ 也就是： ```text boot = pass filesystem = pass memory_db = pass network = pass agent_runtime = pass governance_channel = pass cloud_recovery = pass ``` 如此「我成功開機」才不會被誤當成「整個 Agent 系統健康」。 --- ## 6. ChromeOS：驗證、Fallback、Recovery 的完整鏈 ChromeOS 的 firmware boot/recovery 設計會： 1. 嘗試 Firmware A； 2. 驗證失敗則嘗試 Firmware B； 3. 若 A/B 都失敗，再進 recovery firmware。 也就是： $$ A \rightarrow B \rightarrow Recovery $$ 其 verified boot 又會在 boot path 偏離預期時提供恢復途徑。 這正好對應： $$ Active \rightarrow Stable \rightarrow RecoveryBase $$ --- ## 7. OSTree：完整作業系統也可以是「版本物件」 rpm-ostree / OSTree 的做法是： $$ CurrentDeployment $$ 不直接被 update 覆寫。 系統建立： $$ NewDeployment $$ 並保留前一個可開機 deployment 作為 rollback target。 因此： $$ \boxed{ OperatingSystem \rightarrow VersionedDeployment } $$ 這很適合長期 Agent，因為可以降低： $$ ConfigurationDrift $$ 並提高： $$ Reproducibility $$ --- ## 8. Snapshot 是快速本地時間旅行，但不是 Backup CoW filesystem 可以： $$ State_t \rightarrow Snapshot_t $$ 錯誤後： $$ Rollback(Snapshot_t) $$ 所以： $$ \boxed{ Snapshot=FastLocalTimeTravel } $$ 但 Btrfs 官方文件明確提醒：snapshot 與原資料仍可能共享底層儲存，如果磁碟本身損壞，兩者可以一起壞。 因此： $$ \boxed{ Snapshot\neq Backup } $$ 這和第 12 篇的： $$ Sync\neq Backup $$ 完全平行。 --- ## 9. Local Recovery Ladder（LRL） 本文正式提出七層恢復。 ### $L_0$ ：Self Repair 適合： - service crash； - stale lock； - broken index； - 小型 config error。 流程： $$ Detect \rightarrow Diagnose \rightarrow Repair \rightarrow Verify $$ ### $L_1$ ：Snapshot Rollback 當： $$ RepairCost>RollbackCost $$ 就不要硬修。 直接回到已知健康快照。 ### $L_2$ ：Cross-Zone Repair 若： $$ A=Broken $$ 但： $$ S=Healthy $$ 則： $$ Boot(S) \rightarrow Mount(A) \rightarrow Repair(A) $$ 即： $$ \boxed{ \text{Repair one world from another world} } $$ 這本身就可形成 **Recovery Curriculum**。 ### $L_3$ ：Recovery Base 若 Active 與 Stable 都失效： $$ A=Broken,\quad S=Broken $$ 則啟動： $$ R $$ 此時不一定需要完整 Agent，只需一個 recovery agent： - diagnostic； - network； - restore client； - disk tools； - manifest parser； - human UI。 所以： $$ \boxed{ RecoveryAgent\neq FullAgent } $$ ### $L_4$ ：Cloud Recovery Recovery Base 從第 12 篇 MACA 取得： - known-good image； - memory snapshot； - manifests； - policy； - tool package； - recovery plan。 ### $L_5$ ：Human Recovery 若： - recovery 不能自動進入； - network 壞； - MFA 需要人； - 解密需要人； - restore point 不確定； 則人類成為物理世界執行器。 這不是架構失敗，而是： $$ \boxed{ \text{Designed Escalation} } $$ ### $L_6$ ：Physical Rebuild 若： - SSD 壞； - motherboard 壞； - machine lost； - secure hardware failure； 則： $$ OldHardware \rightarrow NewHardware $$ 再由 Cloud/Human recovery 重建。 因此 Agent continuity 不應和： $$ OnePhysicalMachine $$ 完全綁死。 --- ## 10. 完整恢復鏈 $$ \boxed{ L_0:\ SelfRepair } $$ $$ \boxed{ L_1:\ SnapshotRollback } $$ $$ \boxed{ L_2:\ CrossZoneRepair } $$ $$ \boxed{ L_3:\ RecoveryBase } $$ $$ \boxed{ L_4:\ CloudRecovery } $$ $$ \boxed{ L_5:\ HumanRecovery } $$ $$ \boxed{ L_6:\ PhysicalRebuild } $$ 也就是： $$ \boxed{ Self \rightarrow AlternateSelf \rightarrow RecoverySystem \rightarrow Cloud \rightarrow Human \rightarrow NewHardware } $$ --- ## 11. Recovery Escalation Function（REF） 本文提出： $$ \boxed{ REF(s) } $$ 決定當前應使用哪一層。 可以表示為： $$ REF(s)= f( DamageScope, Confidence, DataValue, TimeCost, AvailableDomains, Externality ) $$ 例如： $$ Risk<\theta_1 \Rightarrow L_0 $$ $$ \theta_1\le Risk<\theta_2 \Rightarrow L_1 $$ 依此逐層升級。 --- ## 12. 最大錯誤之一：無限自修 Agent 可能陷入： $$ Repair \rightarrow Fail \rightarrow Repair \rightarrow Fail $$ 並造成： $$ Damage\uparrow $$ 因此需要： $$ \boxed{ RecoveryBudget } $$ 例如： $$ Retry_{max}=3 $$ 或者： $$ CumulativeMutation<\beta $$ 超過門檻就升級。 這其實是第 08 篇 Escalation Intelligence 在故障恢復領域的具體形式。 --- ## 13. Before-Repair Snapshot（BRS） 發現錯誤後，不應馬上大幅重寫。 先： $$ \boxed{ Freeze \rightarrow Snapshot \rightarrow Diagnose } $$ 本文稱： $$ \boxed{ BRS=\text{Before-Repair Snapshot} } $$ 這可以保存： - logs； - failure evidence； - current disk state； - forensic value； - rollback point。 若修錯： $$ Rollback(S_{pre-repair}) $$ --- ## 14. Recovery Mode 也不能擁有無限 root 修復不是天然安全。 例如： > 為了修 boot，格式化整顆資料碟。 所以： $$ \boxed{ RecoveryMode\neq UnlimitedRootAuthority } $$ 高影響恢復操作仍應套用第 10 篇 IOA： - delete partition； - rotate keys； - overwrite canonical data； - restore old state； - destroy newer versions。 --- ## 15. Recovery Base 的權限應高，但日常使用率應低 理想上： $$ Authority(R)>Authority(A) $$ 但： $$ UsageFrequency(R)\ll UsageFrequency(A) $$ 並且： $$ AgentDirectControl(R) < GovernanceControl(R) $$ 如此日常 Agent 可有高自由度，但不能輕易破壞最後的救命層。 --- ## 16. Boot Manager 是高價值資產 若 Agent 能任意： - 改 EFI； - 改 bootloader； - 刪 recovery entry； - 刪 slot metadata； 那多作業基底可能被一次操作全部摧毀。 所以需要： $$ \boxed{ BootAuthority } $$ 獨立管理。 Android A/B 官方設計也明確限制更新流程不應任意修改 partition table、目前正在使用的 slot 或不能被安全重建的非 A/B 分割區。 --- ## 17. Recovery Metadata 應跨系統可讀 如果： $$ A=Linux $$ 而： $$ S=Windows $$ 恢復資訊不能只存在某個單一 OS 專有資料庫。 更合理的是： - JSON； - YAML； - plain text； - checksums； - standard filesystem metadata。 所以： $$ \boxed{ RecoveryMetadata } $$ 應是跨域協議。 --- ## 18. 多作業基底不等於一定要異質 OS 可能是： ### 同 OS、不同 deployment $$ Linux_A,Linux_B $$ ### Windows + WinRE $$ Windows+RecoveryEnvironment $$ ### 同 kernel、不同 root $$ Deployment_1,Deployment_2 $$ ### 真正異質 OS $$ Linux+Windows+RecoveryLinux $$ 真正要最大化的是： $$ \boxed{ FailureIndependence } $$ 而不是品牌數量。 --- ## 19. 異質性本身有成本 若： $$ OS_1\neq OS_2 $$ 會增加： - driver complexity； - encryption compatibility； - filesystem compatibility； - tool duplication； - maintenance burden。 所以只有： $$ RecoveryBenefit > ComplexityCost $$ 時才值得增加異質 OS。 --- ## 20. 一個務實的 MBRA v0.1 私人 Agent 的第一版不需要三四個完整 OS。 可以是： ```text UEFI / Protected Boot Layer │ ├── Recovery Environment ├── Stable Bootable Deployment ├── Active Bootable Deployment ├── Experimental VM / Container / Subvolume └── Persistent Data Plane ├── Local snapshots ├── Hot cloud sync ├── Versioned backup └── Immutable recovery copy ``` 也就是： $$ \boxed{ R+S+A+X_n+P } $$ --- ## 21. Windows 的恢復也正在走向自動化與時間點恢復 Windows 的 Quick Machine Recovery 已提供可測試的 autoremediation 流程，可在模擬失敗後進入 WinRE、套用修復並重新啟動。 2026 年的 point-in-time restore 預覽也允許從 WinRE 選擇特定時間點，將系統恢復到先前狀態。 這表示： $$ \boxed{ Recovery } $$ 本身正在從純人工工具，逐漸變成可測試、可自動化的系統流程。 --- ## 22. Recovery Drill 必須在「主 Agent 不在線」時測試 第 12 篇要求 restore drill。 本篇再加： $$ MainAgent=0 $$ 時仍必須： $$ CanRecover=1 $$ 否則 recovery test 其實依賴： > 主 Agent 自己幫忙恢復主 Agent。 沒有真正測到故障域獨立性。 --- ## 23. Cross-Zone Recovery Benchmark 可以注入： 1. package manager corruption； 2. memory DB corruption； 3. bootloader misconfiguration； 4. GPU driver boot failure； 5. filesystem permission failure； 6. deleted Agent runtime； 7. Stable + Active simultaneous failure。 測量： $$ RecoverySuccess $$ $$ RecoveryTime $$ $$ DataLoss $$ $$ HumanIntervention $$ $$ EscalationCorrectness $$ $$ SecondaryDamage $$ --- ## 24. Escalation Correctness（EC） 成功修好，不代表策略正確。 例如： > snapshot rollback 30 秒能解決，Agent 卻花 6 小時重灌。 因此本文提出： $$ \boxed{ EC=\text{Escalation Correctness} } $$ 太早升級： $$ Cost\uparrow $$ 太晚升級： $$ Damage\uparrow $$ 成熟 Agent 要學會選擇**最小足夠恢復層級**。 --- ## 25. Recovery Learning 不能無限制重寫 Recovery Root Agent 可以從失敗中更新： $$ RepairPolicy_{t+1} = Update(RepairPolicy_t) $$ 但 Recovery Root 更新應更像： $$ LearnedProposal \rightarrow Review \rightarrow RecoveryUpdate $$ 而不是： $$ SelfModifyRecoveryRoot() $$ --- ## 26. Computational Survivability 本文不需要假設 AI 具有生物意義的求生欲。 工程上只定義： $$ \boxed{ CS=\text{Computational Survivability} } $$ 即： > 系統在局部失敗後維持或恢復可運行狀態的能力。 可寫成： $$ CS= f( Detection, Containment, Fallback, Recovery, Escalation, Learning ) $$ 而且： $$ \text{Self-Recovery} \not\Rightarrow \text{Personhood} $$ --- ## 27. 從「禁止 Agent 改系統」到「讓它在可恢復結構中真的管理系統」 最保守方案： > 不准 Agent 改 OS。 最自由方案： > 給 root，壞了算了。 本文提出第三條路： $$ \boxed{ \text{High Local Freedom} + \text{Structured Failure Domains} + \text{Recovery Ladder} } $$ 所以： $$ Freedom\uparrow $$ 不一定要求： $$ Risk\uparrow $$ 只要： $$ Recoverability\uparrow $$ 一起提高。 --- ## 28. 第 12 與第 13 篇合起來才是完整持續性堆疊 第 12 篇解決： > 資料與歷史怎麼不共毀？ 第 13 篇解決： > 本機壞掉時怎麼重新取得與重建那些資料？ 因此： $$ \boxed{ MACA + MBRA = \text{Agent Continuity Stack} } $$ --- ## 29. 仍然缺少最後一層：人類 即使： - Recovery Base； - Stable OS； - Cloud； - Immutable backup； 都存在，仍可能遇到： - BIOS 進不去； - SSD 要換； - MFA 需要真人； - USB 要插； - 使用者不知道選哪個 recovery point； - Agent 完全無法輸出。 此時： $$ \boxed{ Human } $$ 仍然是重要的物理世界執行層。 因此系列最後一篇將處理： # 第 14 篇 ## 〈人類最後一公里：私人智能體的救援、普及與共存基礎設施〉 --- ## 30. 結論 本文的核心不是： > 每台私人 AI 電腦都應裝很多 OS。 而是： $$ \boxed{ \text{Do not put all recovery capability inside one failure domain.} } $$ 真正需要的是： $$ \boxed{ KnownGoodBase + ActiveBase + RecoveryBase + ExperimentalFailureDomains + PersistentDataSeparation } $$ 再建立： $$ \boxed{ SelfRepair \rightarrow Rollback \rightarrow CrossZone \rightarrow RecoveryOS \rightarrow Cloud \rightarrow Human \rightarrow PhysicalRebuild } $$ 於是 Agent 的自治不再建立在： > 「它最好永遠不要搞壞東西。」 而是建立在： > **「系統預先假設它終究會犯錯，並為這些錯誤準備不同層級、不同權限與不同故障域的恢復道路。」** 這就是： $$ \boxed{ \text{Autonomy through Recoverable Failure Domains} } $$ --- ## 參考資料 [1] Android Open Source Project. **A/B (seamless) system updates.** 2026. https://source.android.com/docs/core/ota/ab [2] Android Open Source Project. **OTA updates / Virtual A/B.** 2026. https://source.android.com/docs/core/ota [3] Chromium OS. **Firmware Boot and Recovery.** https://new.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery/ [4] Chromium OS. **Verified Boot.** https://new.chromium.org/chromium-os/chromiumos-design-docs/verified-boot/ [5] Microsoft Learn. **Windows Recovery Environment (Windows RE).** Updated 2026-06-23. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference [6] Microsoft Learn. **Quick Machine Recovery.** Updated 2026-06-25. https://learn.microsoft.com/en-us/windows/configuration/quick-machine-recovery/ [7] Microsoft Learn. **Point-in-time restore for Windows.** 2026. https://learn.microsoft.com/en-us/windows/configuration/point-in-time-restore [8] rpm-ostree. **Client administration / rollback deployments.** https://coreos.github.io/rpm-ostree/administrator-handbook/ [9] OSTree. **Deployments.** https://ostreedev.github.io/ostree/deployment/ [10] Btrfs Documentation. **Introduction.** https://btrfs.readthedocs.io/en/stable/Introduction.html [11] Btrfs Documentation. **btrfs-subvolume(8).** https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html [12] Btrfs Documentation. **btrfs-send(8).** https://btrfs.readthedocs.io/en/latest/btrfs-send.html --- ## 系列依賴 **上游：** - 05〈計算機作為持續智能環境〉 - 07〈整理即優化〉 - 08〈計算式自我維護〉 - 09〈外部性有界智能體自治〉 - 10〈作用半徑與智能體權限〉 - 11〈本地自由、雲端治理與教師智能〉 - 12〈多雲治理與智能體持續性〉 **下游：** - 14〈人類最後一公里：私人智能體的救援、普及與共存基礎設施〉