多雲治理與智能體持續性：同步、非同步、版本化與故障域分離

Q: 1. 為什麼長期 Agent 的「資料」比一般檔案更複雜？

對一般個人電腦而言，資料可能主要是：

副標題：從「把資料傳上雲」走向可恢復、不可共毀的長期智能體資料架構
系列：《發展式智能體：持續計算環境、共適應學習與外部性有界自治》
篇次： 12 / 14
作者： Neo.K × Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-02

摘要

當本地 AI Agent 成為一個長期存在、具有持續記憶、工具、檔案、排程與自我維護能力的智能體時，資料保護問題不再只是傳統意義上的「備份使用者檔案」，而是保護一個持續演化的智能系統之歷史、能力與可恢復性。

本文提出 Multi-Cloud Agent Continuity Architecture（MACA，多雲智能體持續性架構）。其核心主張是：

\boxed{ \text{Sync} \neq \text{Backup} \neq \text{Archive} \neq \text{Recovery Root} }

單純將本地資料同步到一個或多個雲端，並不能保證恢復能力。若本地 Agent 誤刪、誤寫或被錯誤政策污染，而雲端採即時 destructive mirroring，錯誤可能同步傳播到所有副本。因此，多雲架構必須同時區分：

同步層（Sync）：維持最新狀態；
非同步備份層（Async Backup）：延遲複寫，提供時間隔離；
版本化層（Versioned History）：保留歷史狀態；
不可變層（Immutable / WORM）：阻止在保留期內被刪除或改寫；
冷封存層（Cold Archive）：低頻、長期、跨故障域保存；
本地私密層（Local-Only）：不因備援需求而被迫上傳；
恢復根（Recovery Root）：權限高於被治理 Agent 的獨立恢復能力。

本文進一步提出 Data Continuity Class（DCC）、Replication Temporal Diversity（RTD）、Failure-Domain Separation（FDS）、Recovery Authority Separation（RAS） 與 Propagation Firebreak（PFB），用來防止：

LocalFailure \rightarrow Cloud_1 \rightarrow Cloud_2 \rightarrow Cloud_3

形成同步共毀。

本文的核心結論是：

\boxed{ \text{Redundancy without independence is fragile redundancy} }

真正的多雲持續性不是「資料有很多份」，而是：

即使本地 Agent、單一雲端帳戶、單一供應商、同步政策甚至治理憑證發生故障，仍然至少存在一條不受同一故障原因控制的恢復路徑。

關鍵詞： Multi-Cloud Agent Continuity Architecture、Sync、Versioning、Immutability、WORM、Failure Domain、Recovery Authority、Persistent Agent、Agent Memory、Disaster Recovery

1. 為什麼長期 Agent 的「資料」比一般檔案更複雜？

對一般個人電腦而言，資料可能主要是：

文件；
照片；
程式碼；
設定。

但一個 Persistent Developmental Agent 還可能擁有：

S_t= ( Memory, Policies, Skills, Tools, Schedules, Indexes, History, Credentials, EnvironmentState )

因此「遺失資料」可能不只是：

某份檔案不見。

而是：

Agent 不再知道自己過去學過什麼。

Agent 的工具鏈被破壞。

Agent 的 policy 演化歷史消失。

Agent 的恢復腳本與 canonical state 一起被刪。

這使：

\boxed{ \text{Agent Continuity} > \text{File Backup} }

2. 第一個核心區分：同步不是備份

假設：

Local_t \rightarrow Cloud_t

即時同步。

當本地 Agent 正確修改檔案時，這很好。

但如果：

Delete(Local,x)

同步系統立即執行：

Delete(Cloud,x)

那麼：

\boxed{ Sync = FailurePropagationChannel }

所以：

\boxed{ \text{Sync} \neq \text{Backup} }

同步優化的是：

Freshness

備份優化的是：

Recoverability

兩者目標不同。

3. Destructive Mirror 是多雲架構最危險的假象之一

假設有：

C_1,C_2,C_3

三個雲。

若全部都是：

C_i(t)=Mirror(Local_t)

則本地誤刪：

x_t\rightarrow\varnothing

可能導致：

C_1(x)=C_2(x)=C_3(x)=\varnothing

雖然有三份雲端：

N_{copies}=3

但有效恢復副本：

N_{recoverable}=0

因此：

\boxed{ CopyCount \neq RecoveryDiversity }

4. Multi-Cloud Agent Continuity Architecture（MACA）

本文提出：

\boxed{ MACA= \text{Multi-Cloud Agent Continuity Architecture} }

一個最低限度的 MACA 可以包含：

L+C_H+C_V+C_I+C_A

其中：

$L$ ：Local Active State

本地 Agent 正在使用的狀態。

$C_H$ ：Hot Sync Cloud

快速同步近期資料。

$C_V$ ：Versioned Backup Cloud

保留歷史版本。

$C_I$ ：Immutable Recovery Cloud

具有 WORM／immutability。

$C_A$ ：Cold Archive

長期冷封存。

這些角色：

\boxed{ \text{可以由不同供應商實作} }

也可以由同一供應商的不同帳戶／區域實作，但故障域越重疊，整體韌性越弱。

5. Data Continuity Class（DCC）

不是所有資料都應使用同一備份策略。

本文提出：

\boxed{ DCC(x)=\text{Data Continuity Class} }

DCC-0：Disposable

例如：

cache；
temporary files；
downloaded artifacts；
rebuildable index。

策略：

LocalOnly / Rebuild

DCC-1：Convenience State

例如：

UI state；
recent task cache；
noncritical preferences。

策略：

AsyncBackup

DCC-2：Persistent Working State

例如：

active project files；
Agent workflow；
tool configuration；
active memory store。

策略：

HotSync+Versioning

DCC-3：Critical Continuity State

例如：

canonical research；
long-term memory；
policy history；
agent identity metadata；
recovery manifests；
important tools。

策略：

Sync + VersionedBackup + ImmutableCopy

DCC-4：Irreplaceable / Constitutional State

例如：

recovery root；
root identity；
foundational policy；
unique provenance；
irreplaceable originals。

策略：

\boxed{ MultiCloud + Immutable + Offline/HumanCopy }

DCC-P：Private Local-Only

有些資料即使重要，也不應上雲。

例如：

highly private raw memory；
sensitive personal workspace；
local-only secrets；
temporary decrypted material。

策略：

\boxed{ LocalEncrypted + OptionalHumanControlledBackup }

而不是：

Importance\uparrow \Rightarrow CloudUpload\uparrow

6. 備份策略本身可以是一個函數

本文將資料保護策略寫成：

B(x) = f( V_x, R_x, S_x, \Delta_x, P_x, C_x )

其中：

$V_x$ ：Value；
$R_x$ ：Recoverability requirement；
$S_x$ ：Sensitivity；
$\Delta_x$ ：Change rate；
$P_x$ ：Propagation risk；
$C_x$ ：Cloud/storage cost。

輸出：

B(x)\in \{ LocalOnly, Sync, Async, Versioned, Immutable, Archive \}

而且可以是多選。

7. 同步與非同步不是二選一

對重要資料：

Sync

可以降低：

RPO

即 Recovery Point Objective。

但非同步備份提供：

\boxed{ Temporal Isolation }

如果 Agent 在：

t_0

犯錯，而非同步備份在：

t_0+\Delta

才執行，就可能在這個時間窗內被：

anomaly detector；
human；
cloud governance；
recovery monitor；

攔截。

所以：

\boxed{ Sync + Async > Sync\ Only }

8. Replication Temporal Diversity（RTD）

本文提出：

\boxed{ RTD= \text{Replication Temporal Diversity} }

如果所有副本都：

\Delta t=0

同步更新，則：

TemporalDiversity=0

更好的策略可能是：

C_1:t

C_2:t+1h

C_3:t+24h

C_4:t+7d

形成不同時間尺度。

這不是為了讓資料「故意過期」，而是：

防止最新錯誤立刻成為所有副本的唯一真相。

9. Versioning：刪除不等於歷史消失

AWS S3 Object Lock、Azure Blob Versioning 與 Google Cloud Object Versioning 都提供一個重要共同思想：

CurrentState \neq OnlyState

版本化意味著：

x_t \rightarrow \{x_0,x_1,\ldots,x_t\}

因此：

Delete(Current)

不必自動意味：

Delete(History)

這是 Agent 世界非常重要的特性。

10. Immutable / WORM：連管理員都不能隨便刪

真正高價值 recovery data 應該存在：

\boxed{ ImmutableWindow }

AWS S3 Object Lock 可對版本設定 retention 或 legal hold；Azure Backup 的 immutable vault 在 locked 狀態下可以阻止導致 recovery point 遺失的操作，並以 WORM 保護；Google Cloud Backup and DR 也提供 immutable vault 與 locked retention。

因此：

AgentCredentialCompromised

甚至：

AdminCredentialCompromised

都不必立即導致：

BackupDestroyed

11. 不可變並不等於永遠保存

如果：

Retention=\infty

成本可能爆炸。

因此：

Immutable \neq Permanent

比較合理：

Immutable(x,\Delta t)

例如：

7 日；
30 日；
90 日；
1 年。

不同 DCC 使用不同 retention。

12. 多雲真正的核心：Failure-Domain Separation（FDS）

本文提出：

\boxed{ FDS= \text{Failure-Domain Separation} }

真正重要的不是：

C_1\neq C_2

而是：

Failure(C_1) \nRightarrow Failure(C_2)

例如以下都屬於不同程度的故障域：

不同 bucket；
不同 account；
不同 subscription；
不同 region；
不同 cloud provider；
不同 authentication root；
offline device；
human-held media。

故障域越獨立：

Correlation(F_i,F_j)\downarrow

韌性越高。

13. 「多雲」不能只是同一登入帳號的三個資料夾

假設三個雲端都使用：

Credential_{root}

而該 credential 洩漏：

Compromise(root) \rightarrow Compromise(C_1,C_2,C_3)

所以：

ProviderDiversity

不等於：

AuthorityDiversity

真正需要：

\boxed{ \text{Data Separation} + \text{Credential Separation} + \text{Policy Separation} }

14. Recovery Authority Separation（RAS）

本文提出：

\boxed{ RAS= \text{Recovery Authority Separation} }

要求：

P_{recovery} > P_{local}

至少：

P_{local} \nsupseteq P_{destroy\ recovery}

也就是本地 Agent 可以：

建資料；
修改工作區；
甚至刪除某些 active copy；

但不能同時：

刪掉所有不可變 backup。

這正是 AWS logically air-gapped vault、Azure immutable vault 等架構背後的重要思想：恢復面應與生產面隔離。

15. Recovery Root 不應依賴被恢復的 Agent 才能使用

如果：

要恢復 Agent，必須先啟動 Agent。

則形成：

RecoveryDependencyCycle

所以恢復根必須能由：

雲端；
recovery OS；
人類；
second device；

獨立觸發。

即：

\boxed{ RecoveryPath \not\subset FailedSystem }

16. Propagation Firebreak（PFB）

本文提出：

\boxed{ PFB= \text{Propagation Firebreak} }

用來阻止錯誤同步一路穿透所有層。

例如：

Local Active
    │
    ├── Hot Sync
    │
    ├── Delayed Versioned Backup
    │
    └── Immutable Archive

其中：

Delete(Local)

可以：

Delete(HotSync)

但不應自動：

Delete(ImmutableArchive)

所以：

\boxed{ DestructiveAction \not\Rightarrow GlobalDestructivePropagation }

17. Tombstone 與真正刪除要分開

當本地 Agent 認為：

這筆記憶不需要了。

可以先寫：

Tombstone(x)

而不是：

PhysicalDelete(x)

這表示：

active system 不再使用。

但 backup/history 仍保留到 retention 到期。

因此：

LogicalDeletion \neq PhysicalDestruction

18. 但隱私刪除又提出反方向問題

長期 Agent memory 的 2026 年研究已指出：

即使原始 memory 被刪除，derived summary 仍可能保留該資訊。

因此：

Delete(raw) \not\Rightarrow Forget(system)

所以多雲系統需要區分：

Recovery Delete

防止誤刪，因此延遲真正刪除。

與：

Privacy Erasure

使用者要求真正忘記，需要跨所有 derived tier 清除。

這兩者：

\boxed{ RecoveryRetention \neq PrivacyErasure }

甚至存在張力。

19. 因此需要 Erasure Manifest

當需要真正刪除：

x

不能只執行：

delete raw/x

而需要：

EM(x) = \{ Raw, Summary, Embedding, Index, Cache, Replica, Archive \}

並逐層標記：

Erase

這可以稱為：

\boxed{ \text{Erasure Manifest} }

20. Agent Memory 必須有 scope

近期長期 Agent memory 系統已開始強調：

user scope；
agent scope；
thread scope；
active memory；
passive store；
lifecycle management。

因此：

Memory(x)

不能只是：

存在某個 vector DB。

而應標記：

Scope(x)

這會直接決定：

可以同步到哪；
哪個雲可以看；
哪個 Agent 可以讀；
retention 多久。

21. 多雲不只是備份，也可以是治理見證

假設：

Cloud_1

是主要治理服務。

可以讓：

Cloud_2

保存：

policy hash；
audit digest；
recovery manifest；
critical event proof。

即：

\boxed{ GovernanceWitness }

如果：

Cloud_1

被修改，可以用：

Cloud_2

比對。

這讓多雲從：

DataRedundancy

擴展成：

\boxed{ GovernanceRedundancy }

22. Teacher 多雲與 Backup 多雲不一定是同一組雲

第 11 篇的 Cloud Teacher：

T_1,T_2

可能來自 frontier model providers 或 specialist providers。

而 backup cloud：

B_1,B_2

可能完全不同。

所以：

\boxed{ CognitiveCloud \neq StorageCloud }

這有助於降低：

VendorConcentration

23. Backup Policy 本身不能只存在本地

如果：

backup_policy.yaml

只有本地一份，而本地壞掉：

PolicyLost

那恢復會很困難。

所以應保存：

\boxed{ Recovery Metadata }

例如：

snapshot list；
canonical version；
dependency map；
encryption key instructions；
restore order；
boot target；
human-readable description。

24. Human-Readable Recovery Metadata

未來私人 AI 的使用者不一定懂：

ZFS；
Btrfs；
object versioning；
IAM；
boot loader。

因此 recovery data 應同時存在：

R= ( R_H, R_M, R_E )

其中：

$R_H$

Human-readable。

例如：

這是 8 月 1 日晚間最後一份健康狀態。

如果 AI 無法啟動，先下載這個救援包。

$R_M$

Machine-readable。

例如 JSON / YAML manifest。

$R_E$

Expert-level detail。

例如：

checksums；
partition map；
encryption configuration；
dependency versions。

25. Restore 必須定期測試

Backup success：

Backup=1

不等於：

Restore=1

所以需要：

\boxed{ \text{Restore Drill} }

例如：

Monthly \rightarrow Restore\ Sample

Quarterly \rightarrow Full\ Recovery\ Test

26. Recovery Point 與 Recovery Time 要分開

定義：

RPO= \text{Maximum Acceptable Data Loss Window}

RTO= \text{Maximum Acceptable Recovery Time}

例如：

Active Memory

RPO=5min

Historical Archive

RPO=24h

而 Boot Recovery 可能需要：

RTO<1h

所以不同：

DCC_i

應有不同：

(RPO_i,RTO_i)

27. 多雲架構可以採用異質時間階層

例如：

Local SSD
    │
    ├── Cloud A: real-time sync
    │
    ├── Cloud B: hourly versioned backup
    │
    ├── Cloud C: daily immutable vault
    │
    └── Human/Offline: monthly rescue image

所以：

\boxed{ \text{Temporal Heterogeneity} + \text{Provider Heterogeneity} + \text{Authority Heterogeneity} }

共同形成 resilience。

28. Agent 不應該自行決定所有 retention

因為 Agent 可能：

為了節省空間，把全部歷史刪掉。

因此：

RetentionPolicy

至少對：

DCC_3,DCC_4

應由：

GovernancePlane

約束。

即：

AgentOptimizeCost

不能凌駕：

RecoveryRequirement

29. 但治理也不能無限保留所有資料

反過來，如果：

Retention\rightarrow\infty

則：

storage cost；
privacy exposure；
legal burden；
attack surface；

可能上升。

所以真正目標：

\boxed{ \min ( LossRisk + StorageCost + PrivacyRisk + RecoveryCost ) }

subject to：

Recoverability\ge r_0

30. Backup Scheduler 可以成為發展式 Agent 的學習對象

Agent 可以觀察：

哪些資料變化頻繁；
哪些資料幾乎不變；
哪些資料最常被 restore；
哪些 backup 很少用；
哪些資料很敏感。

因此：

B_{t+1}(x) = Update(B_t(x),History)

也就是：

backup policy 本身可以學習。

但這種學習需要：

GovernanceConstraints

避免：

Agent 為了省錢把 recovery 關掉。

31. Multi-Cloud Continuity Score

本文提出一個簡化指標：

\boxed{ MCCS }

即 Multi-Cloud Continuity Score。

可以由：

MCCS= f( CopyDiversity, TemporalDiversity, Immutability, AuthoritySeparation, RestoreTest, ProviderDiversity )

構成。

一個：

三份即時 mirror、同帳號、同 credential。

系統的：

MCCS

可能很低。

而：

一份 hot sync + 一份 versioned + 一份 immutable + 獨立 recovery account。

即使副本數相同，MCCS 可能高很多。

32. Common-Mode Failure 才是多雲真正要解的問題

如果三個 backup 都依賴：

同一 OAuth；
同一 encryption key；
同一管理 Agent；
同一 policy；
同一刪除 webhook；

那麼：

\boxed{ CommonModeFailure }

仍然存在。

因此：

MultiCloud

真正應優化：

\min CorrelatedFailure

而不是：

\max CopyCount

33. 一個建議的 MACA v0.1

Layer 0：Local Active

full working state；
private memory；
current OS；
tools。

Layer 1：Hot Sync

DCC-2 / DCC-3；
fast recovery；
short retention。

Layer 2：Versioned Backup

hourly/daily；
soft delete；
point-in-time restore。

Layer 3：Immutable Vault

DCC-3 / DCC-4；
WORM；
independent account；
longer retention。

Layer 4：Cold / Human Recovery

periodic image；
rescue package；
critical keys／instructions；
offline or independent custody。

34. 一個故障例子：Agent 誤刪自己的研究庫

時間：

t_0

Agent 誤判：

這些是重複文件。

執行：

Delete(2000files)

Local

刪除。

Hot Sync

可能同步刪除。

Versioned Cloud

產生 tombstone，但歷史版本仍在。

Immutable Cloud

原版本保留。

Governance

偵測大量 delete：

CumulativeEffect>\theta

停止後續傳播。

Human

看到：

大量重要研究文件被刪除，已自動凍結同步；可選擇 10:32 的恢復點。

這才是：

\boxed{ \text{Recoverable Autonomy} }

35. 一個故障例子：Agent 自己把 OS 搞壞

本地：

Boot=Failure

但 Cloud Recovery 保存：

last healthy manifest；
bootable rescue image；
agent memory snapshot；
tool package；
restore instructions。

於是下一層：

RecoveryOS

或人類可以：

Restore

這會直接進入第 13 篇。

36. 一個可測試的多雲實驗

建立三種架構：

A：Single Cloud Mirror

Local\leftrightarrow C_1

B：Three-Cloud Mirror

Local\leftrightarrow C_1,C_2,C_3

三者全部同步。

C：MACA

hot sync；
delayed versioned backup；
immutable vault；
independent recovery credentials。

注入：

accidental deletion；
malicious deletion；
credential compromise；
corrupted sync；
provider outage；
bad policy update。

測量：

RecoverySuccess

DataLoss

RecoveryTime

CorrelatedFailure

Cost

PrivacyExposure

如果：

Recoverability_C>Recoverability_B

則支持：

多個彼此同構的鏡像副本，不一定比角色分離的異質恢復架構更安全。

37. 本文的五個核心命題

命題一

\boxed{ Sync\neq Backup }

命題二

\boxed{ Replication\neq FailureDomainSeparation }

命題三

\boxed{ Versioning + Immutability > MirrorOnly }

命題四

\boxed{ RecoveryAuthority > LocalDestructiveAuthority }

命題五

\boxed{ \text{Redundancy without independence is fragile redundancy} }

38. 與下一篇的關係

即使 Cloud：

Healthy

如果本地：

OS=Broken

Agent 仍可能無法自己取得雲端恢復資料。

因此需要：

\boxed{ \text{Local Recovery Domains} }

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

將正式把本地環境拆成：

Recovery Base；
Stable OS；
Active OS；
Experimental Zones；
Persistent Data；

並建立：

SelfRepair \rightarrow Rollback \rightarrow CrossZone \rightarrow RecoveryOS \rightarrow Cloud \rightarrow Human

的完整恢復階梯。

39. 結論

多雲架構對長期 AI Agent 的意義，不是：

「把所有東西多存幾份。」

而是：

\boxed{ \text{Continuity through heterogeneous recovery paths} }

真正的韌性來自：

資料分類；
時間分離；
版本分離；
不可變性；
帳戶分離；
權限分離；
供應商分離；
人類恢復路徑。

因此未來私人智能體的資料架構應從：

\text{Sync Everything}

升級為：

\boxed{ \text{Classify} \rightarrow \text{Replicate} \rightarrow \text{Version} \rightarrow \text{Lock} \rightarrow \text{Separate} \rightarrow \text{Test Restore} }

最終目標不是保證 Agent 永遠不犯錯。

而是：

即使 Agent、作業系統、同步策略、雲端帳戶甚至治理層其中一部分出錯，仍然存在另一個不受同一故障支配的恢復世界。

參考資料

[1] Amazon Web Services. Locking objects with Object Lock - Amazon S3.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html

[2] Amazon Web Services. Logically air-gapped vault - AWS Backup.
https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html

[3] Amazon Web Services. Multi-party approval for logically air-gapped vaults.
https://docs.aws.amazon.com/aws-backup/latest/devguide/multipartyapproval.html

[4] Microsoft. Immutable vault for Azure Backup. Updated 2026-06-24.
https://learn.microsoft.com/en-us/azure/backup/backup-azure-immutable-vault-concept

[5] Microsoft. Blob versioning - Azure Storage.
https://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview

[6] Google Cloud. Data protection, backup, and recovery options - Cloud Storage.
https://docs.cloud.google.com/storage/docs/protection-backup-recovery-overview

[7] Google Cloud. Configure cyber resilience for Backup and DR. 2026.
https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/best-practices-cyber-resilience

[8] Omri, Y. et al. Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads. arXiv:2606.06448, 2026.
https://arxiv.org/abs/2606.06448

[9] Lei, C. et al. Deployment-Time Memorization in Foundation-Model Agents. arXiv:2606.10062, 2026.
https://arxiv.org/abs/2606.10062

[10] Ravindran, S. K. Portable Agent Memory: A Protocol for Cryptographically-Verified Memory Transfer Across Heterogeneous AI Agents. arXiv:2605.11032, 2026.
https://arxiv.org/abs/2605.11032

系列依賴

上游：

05〈計算機作為持續智能環境〉
08〈計算式自我維護〉
09〈外部性有界智能體自治〉
10〈作用半徑與智能體權限〉
11〈本地自由、雲端治理與教師智能〉

下游：

13〈多作業基底、分區故障域與智能體恢復階梯〉
14〈人類最後一公里〉

12_多雲治理與智能體持續性_同步非同步版本化與故障域分離

多雲治理與智能體持續性：同步、非同步、版本化與故障域分離

摘要

1. 為什麼長期 Agent 的「資料」比一般檔案更複雜？

2. 第一個核心區分：同步不是備份

3. Destructive Mirror 是多雲架構最危險的假象之一

4. Multi-Cloud Agent Continuity Architecture（MACA）

LLL ：Local Active State

CHC_HCH​ ：Hot Sync Cloud

CVC_VCV​ ：Versioned Backup Cloud

CIC_ICI​ ：Immutable Recovery Cloud

CAC_ACA​ ：Cold Archive

5. Data Continuity Class（DCC）

DCC-0：Disposable

DCC-1：Convenience State

DCC-2：Persistent Working State

DCC-3：Critical Continuity State

DCC-4：Irreplaceable / Constitutional State

DCC-P：Private Local-Only

6. 備份策略本身可以是一個函數

7. 同步與非同步不是二選一

8. Replication Temporal Diversity（RTD）

9. Versioning：刪除不等於歷史消失

10. Immutable / WORM：連管理員都不能隨便刪

11. 不可變並不等於永遠保存

12. 多雲真正的核心：Failure-Domain Separation（FDS）

13. 「多雲」不能只是同一登入帳號的三個資料夾

14. Recovery Authority Separation（RAS）

15. Recovery Root 不應依賴被恢復的 Agent 才能使用

16. Propagation Firebreak（PFB）

17. Tombstone 與真正刪除要分開

18. 但隱私刪除又提出反方向問題

Recovery Delete

Privacy Erasure

19. 因此需要 Erasure Manifest

20. Agent Memory 必須有 scope

21. 多雲不只是備份，也可以是治理見證

22. Teacher 多雲與 Backup 多雲不一定是同一組雲

23. Backup Policy 本身不能只存在本地

24. Human-Readable Recovery Metadata

RHR_HRH​

RMR_MRM​

RER_ERE​

25. Restore 必須定期測試

26. Recovery Point 與 Recovery Time 要分開

Active Memory

Historical Archive

27. 多雲架構可以採用異質時間階層

28. Agent 不應該自行決定所有 retention

29. 但治理也不能無限保留所有資料

30. Backup Scheduler 可以成為發展式 Agent 的學習對象

31. Multi-Cloud Continuity Score

32. Common-Mode Failure 才是多雲真正要解的問題

33. 一個建議的 MACA v0.1

Layer 0：Local Active

Layer 1：Hot Sync

Layer 2：Versioned Backup

Layer 3：Immutable Vault

Layer 4：Cold / Human Recovery

34. 一個故障例子：Agent 誤刪自己的研究庫

Local

Hot Sync

Versioned Cloud

Immutable Cloud

Governance

Human

35. 一個故障例子：Agent 自己把 OS 搞壞

36. 一個可測試的多雲實驗

A：Single Cloud Mirror

B：Three-Cloud Mirror

C：MACA

37. 本文的五個核心命題

命題一

命題二

命題三

命題四

命題五

38. 與下一篇的關係

第 13 篇

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

$L$ ：Local Active State

$C_H$ ：Hot Sync Cloud

$C_V$ ：Versioned Backup Cloud

$C_I$ ：Immutable Recovery Cloud

$C_A$ ：Cold Archive

$R_H$

$R_M$

$R_E$