多作業基底、分區故障域與智能體恢復階梯

副標題：從單一可失敗世界走向跨系統自救、雲端求援與人類最後恢復
系列：《發展式智能體：持續計算環境、共適應學習與外部性有界自治》
篇次： 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：把本機拆成不同故障域

一個最低可行架構：

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 \}

也就是：

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 設計會：

嘗試 Firmware A；
驗證失敗則嘗試 Firmware B；
若 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。

可以是：

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

可以注入：

package manager corruption；
memory DB corruption；
bootloader misconfiguration；
GPU driver boot failure；
filesystem permission failure；
deleted Agent runtime；
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〈人類最後一公里：私人智能體的救援、普及與共存基礎設施〉

13_多作業基底分區故障域與智能體恢復階梯

多作業基底、分區故障域與智能體恢復階梯

摘要

1. 單一作業世界的問題

2. MBRA：把本機拆成不同故障域

Recovery Base RRR

Stable Base SSS

Active Base AAA

Experimental Zones XiX_iXi​

Persistent Data Plane PPP

3. A/B 更新真正值得借用的是「Known-Good + Candidate」

4. 系統更新應該是一個狀態機

5. Health Contract（HC）

6. ChromeOS：驗證、Fallback、Recovery 的完整鏈

7. OSTree：完整作業系統也可以是「版本物件」

8. Snapshot 是快速本地時間旅行，但不是 Backup

9. Local Recovery Ladder（LRL）

L0L_0L0​ ：Self Repair

L1L_1L1​ ：Snapshot Rollback

L2L_2L2​ ：Cross-Zone Repair

L3L_3L3​ ：Recovery Base

L4L_4L4​ ：Cloud Recovery

L5L_5L5​ ：Human Recovery

L6L_6L6​ ：Physical Rebuild

10. 完整恢復鏈

11. Recovery Escalation Function（REF）

12. 最大錯誤之一：無限自修

13. Before-Repair Snapshot（BRS）

14. Recovery Mode 也不能擁有無限 root

15. Recovery Base 的權限應高，但日常使用率應低

16. Boot Manager 是高價值資產

17. Recovery Metadata 應跨系統可讀

18. 多作業基底不等於一定要異質 OS

同 OS、不同 deployment

Windows + WinRE

同 kernel、不同 root

真正異質 OS

19. 異質性本身有成本

20. 一個務實的 MBRA v0.1

21. Windows 的恢復也正在走向自動化與時間點恢復

22. Recovery Drill 必須在「主 Agent 不在線」時測試

23. Cross-Zone Recovery Benchmark

24. Escalation Correctness（EC）

25. Recovery Learning 不能無限制重寫 Recovery Root

26. Computational Survivability

27. 從「禁止 Agent 改系統」到「讓它在可恢復結構中真的管理系統」

28. 第 12 與第 13 篇合起來才是完整持續性堆疊

29. 仍然缺少最後一層：人類

第 14 篇

〈人類最後一公里：私人智能體的救援、普及與共存基礎設施〉

30. 結論

參考資料

系列依賴

Recovery Base $R$

Stable Base $S$

Active Base $A$

Experimental Zones $X_i$

Persistent Data Plane $P$

$L_0$ ：Self Repair

$L_1$ ：Snapshot Rollback

$L_2$ ：Cross-Zone Repair

$L_3$ ：Recovery Base

$L_4$ ：Cloud Recovery

$L_5$ ：Human Recovery

$L_6$ ：Physical Rebuild