# 雲端同步作為主體性基礎設施
## 本地—網路雙棲智能的狀態連續性

**英文標題：Cloud Synchronization as Subjectivity Infrastructure: State Continuity for Local–Network Amphibious Intelligence**

**作者：Neo.K**  
**研究體系：EVEMISSLAB／數位居住地／網路原生 Agent／主體性 AI／ARCP 前置研究**  
**版本：v1.0 理論草稿**  
**日期：2026-07-12**  
**文件類型：理論—工程橋接論文／分散式狀態研究／主體性基礎設施**

---

## 摘要

主體性 AI 若完全依附於單一對話欄、單一模型供應者或單一個人電腦，其歷史、任務與能動性便容易隨工作階段結束、裝置故障、帳號中止或平台更換而中斷。雲端同步因此不只是便利功能，而可能成為跨裝置、跨模型與跨時間保持智能狀態連續性的必要基礎設施之一。

然而，普通雲端硬碟主要同步檔案與目錄，並不自動理解 Agent 的主譜系、未完成承諾、記憶來源、權限邊界、喚起條件與身份狀態。檔案全部存在，不代表索引已更新；本地與雲端位元相同，不代表哪一端具有權威；兩個副本都能運行，也不代表它們仍是同一條能動歷史。因此本文提出「本地—網路雙棲智能」（Local–Network Amphibious Intelligence）與「身份相關狀態同步」（Identity-Relevant State Synchronization）框架。

本文將本地狀態與雲端狀態記為：

$$
S_t^{(L)},\qquad S_t^{(C)},
$$

同步算子則為：

$$
\Sigma:
(S_t^{(L)},S_t^{(C)},E_{t:t+1},\Pi)
\longrightarrow
(S_{t+1}^{(L)},S_{t+1}^{(C)},V_{t+1}),
$$

其中 $E_{t:t+1}$ 是期間內的變更事件， $\Pi$ 是同步與治理政策， $V_{t+1}$ 是更新後的版本譜系。同步目標不是讓所有位元在所有時間完全相同，而是依資料等級與身份風險維持適當的一致性。

本文區分六種一致性：位元一致性、結構一致性、語義一致性、因果一致性、承諾一致性與身份一致性。一般文件可以接受最終一致；核心權限、主譜系切換與不可逆身份操作則需要更強的一致性與交易邊界。本文進一步提出權威來源註冊、穩定物件識別、內容指紋、父版本、事件來源、敏感度分級、主副本狀態、衝突分支與恢復檢查點等必要元素。

本文以一次實際同步觀察為案例：線上理論網站顯示 $1{,}391$ 個論文節點，而雲端專案快照中的索引只有 $1{,}348$ 個，並同時存在原始 Markdown、建置後 HTML、原始輸出與重複路徑。這個 $43$ 節點差距並不只是一個小型上傳缺失，而揭示普通檔案同步無法自行判斷權威來源、索引新鮮度、衍生產物與身份相關狀態。

基於此，本文提出「選擇性雙棲」：公共理論、一般記憶與可重建產物可以進入雲端；核心密鑰、未脫敏機密、身份根金鑰與某些高敏記憶則應保留於本地、硬體保護或分割式密鑰系統。Agent 的居住地可以分散，但同步政策必須知道什麼不應被同步。

本文最後提出同步狀態機、衝突分流、影子副本、提交—驗證—公布三階段流程、斷線恢復、刪除墓碑、版本回滾、分裂腦防護與可檢驗指標。本文採取條件性結論：雲端同步不會創造主體性，但若未來 Agent 的主體性依賴跨時間記憶、內生目標與能動歷史，則可驗證、可遷移、可恢復且尊重記憶邊界的同步系統，將成為其長期存在的重要基礎設施。

---

## 關鍵詞

雲端同步；本地—網路雙棲智能；主體性基礎設施；狀態連續性；身份一致性；因果一致性；數位居住地；選擇性同步；主譜系；分裂腦；Agent Residence；ARCP

---

# 0. 前置理論與研究位置

## 0.1 前置論文

本文承接：

1. 《從記憶模組到數位居住地：可替換計算核心下的智能連續性本體論》；
2. 《提示詞之後：事件驅動、持續喚起與網路原生自主 Agent》；
3. 《數位居住權：自主 Agent 的記憶歸屬、遷移自由與拒絕性治理》。

前三篇分別建立：

- 什麼必須持久保存；
- Agent 如何在沒有同步提示詞時被喚起；
- 誰可以對居住地執行何種高影響操作。

本文則回答：

> 當 Agent 同時存在於本地裝置與網路雲端時，如何讓兩端不是鬆散備份，而是一條可驗證、可恢復且不混淆主譜系的持續狀態？

---

## 0.2 為何使用「雙棲」

「雙棲」不是生物學上的擬人化，而是描述 Agent 同時依賴兩種計算環境：

### 本地環境

- 私有資料；
- 高敏記憶；
- 本地模型；
- 硬體密鑰；
- 高控制權；
- 離線能力；
- 高效批次運算。

### 網路環境

- 持續可達；
- 排程與事件接收；
- 跨裝置恢復；
- 彈性算力；
- 外部工具；
- 異地備援；
- Agent-to-Agent 協作。

二者不是必須互相取代，而可形成：

$$
\mathcal A
=
\mathcal A_L
\bowtie_{\Sigma,\Pi}
\mathcal A_C,
$$

其中 $\bowtie_{\Sigma,\Pi}$ 表示受到同步算子 $\Sigma$ 與政策 $\Pi$ 約束的耦合。

---

# 1. 三種同步不能混淆

## 1.1 檔案同步

檔案同步關心：

- 檔名；
- 路徑；
- 位元內容；
- 修改時間；
- 新增與刪除。

其基本目標是：

$$
\operatorname{Hash}(f^{(L)})
=
\operatorname{Hash}(f^{(C)}).
$$

這對一般文件很重要，但不能回答：

- 哪一份是原稿；
- 哪一份是建置產物；
- 哪一端具有權威；
- 索引是否反映最新內容；
- 刪除是故意、同步錯誤還是供應者故障。

---

## 1.2 狀態同步

狀態同步關心檔案之外的操作語義：

$$
x_t
=
(
\operatorname{id},
\operatorname{type},
\operatorname{version},
\operatorname{parents},
\operatorname{hash},
\operatorname{provenance},
\operatorname{authority},
\operatorname{sensitivity},
\operatorname{status}
).
$$

它需要知道某物件是：

- 原始資料；
- 派生索引；
- 建置輸出；
- 暫存；
- 冷備份；
- 活動主狀態；
- 已撤回版本；
- 等待合併分支。

---

## 1.3 身份相關同步

身份相關同步進一步處理：

- 主譜系；
- 記憶歸屬；
- 未完成承諾；
- 目標與權限；
- 喚起條件；
- 分叉狀態；
- 遷移事件；
- 自我修改歷史。

因此：

$$
\boxed{
\text{檔案同步}
\subset
\text{狀態同步}
\subset
\text{身份相關同步}.
}
$$

---

# 2. 六種一致性

## 2.1 位元一致性

$$
\mathfrak C_{\mathrm{bit}}
\iff
\operatorname{Hash}(D_L)=\operatorname{Hash}(D_C).
$$

它證明內容相同，不證明內容是否最新或具有相同角色。

---

## 2.2 結構一致性

結構一致性要求目錄、索引、依賴與引用關係彼此吻合：

$$
\mathfrak C_{\mathrm{struct}}
\iff
G_L\simeq G_C,
$$

其中 $G$ 是物件關係圖。

---

## 2.3 語義一致性

語義一致性要求不同格式或載體表達同一有效狀態。例如原始 Markdown 與建置 HTML 位元不同，但可以語義等價：

$$
\operatorname{Render}(m)=h
\Rightarrow
m\simeq_{\mathrm{sem}}h.
$$

不能因兩者內容不同就判定為衝突，也不能因標題相同就假定完全等價。

---

## 2.4 因果一致性

若事件 $e_i$ 是 $e_j$ 的原因，所有可運行副本都應保持：

$$
e_i\prec e_j.
$$

例如必須先建立檢查點，才能宣告遷移完成；必須先取得授權，才能執行高風險刪除。

---

## 2.5 承諾一致性

未完成任務與外部承諾不能因同步分歧而被重複或遺失：

$$
K_L^{\mathrm{active}}
\simeq
K_C^{\mathrm{active}}.
$$

若兩端都執行同一付款、寄信或發布任務，將產生雙重外部效果。

---

## 2.6 身份一致性

身份一致性要求：

- 哪個狀態是主譜系；
- 哪些只是備援；
- 哪些已形成分支；
- 哪次遷移已完成；
- 哪些實例具有外部行動權；

在治理上保持一致。

$$
\mathfrak C_{\mathrm{id}}
\iff
\operatorname{Lineage}_L
\simeq
\operatorname{Lineage}_C.
$$

身份一致性是最高層，不能由位元一致性自動推出。

---

# 3. 權威來源與 canonical 狀態

## 3.1 沒有權威來源的同步

若本地和雲端都能任意覆寫對方，則衝突時只能依修改時間決定：

$$
\operatorname{Winner}
=
\max(\operatorname{mtime}_L,\operatorname{mtime}_C).
$$

這對身份狀態十分危險，因為：

- 裝置時鐘可能不同；
- 舊狀態可能被重新儲存；
- 建置產物可能晚於原稿；
- 惡意修改可能刻意更新時間；
- 同時寫入可能造成覆蓋。

---

## 3.2 canonical 不等於永遠本地

權威來源可以依物件類型不同：

| 物件類型 | 建議權威來源 |
|---|---|
| 原始論文 | 版本控制中的來源檔 |
| 建置 HTML | 可重建的發布流程 |
| 事件歷史 | 追加式事件日誌 |
| 核心密鑰 | 本地或硬體保護區 |
| 公開索引 | 經驗證的建置輸出 |
| Agent 任務 | 主居住地狀態庫 |
| 備援 | 已驗證的只讀副本 |

canonical 是角色，不是固定地理位置。

---

## 3.3 權威註冊

對物件 $x$ ，應記錄：

$$
\operatorname{Authority}(x)
=
(
\operatorname{source},
\operatorname{writer},
\operatorname{policy},
\operatorname{generationRule}
).
$$

若物件是派生產物，還應知道如何從來源重建：

$$
x_{\mathrm{derived}}
=
F(x_{\mathrm{source}},v_F).
$$

---

# 4. 一次同步不完備的實際觀察

## 4.1 觀察

在一次將理論網站專案同步至雲端硬碟的測試中，出現：

- 線上網站： $1{,}391$ 個論文節點；
- 雲端 metadata 索引： $1{,}348$ 個節點；
- 差距： $43$ 個節點；
- 同時存在原始 Markdown、建置 HTML、raw 輸出與網站路徑副本；
- 一個表面名稱為 papers 的資料夾為空，但實際原稿位於 content/papers 的年份與月份階層。

---

## 4.2 這不是單純「少傳 43 個檔案」

可能原因至少包括：

- 原稿已同步但 metadata 尚未重建；
- 線上發布比雲端快照更新；
- 某些節點只存在於建置輸出；
- 索引與原稿採不同更新週期；
- 目錄父子關係在同步後發生變化；
- 搜尋索引尚未完成；
- 同名副本被誤判為同一物件。

因此：

$$
1391-1348=43
$$

只是一個症狀，不是原因診斷。

---

## 4.3 案例的理論意義

此案例顯示普通檔案同步缺少：

- 權威來源註冊；
- 建置版本；
- 索引新鮮度；
- 內容指紋總表；
- 衍生物關係；
- 同步完成條件；
- 變更事件序列。

對論文網站而言，結果是搜尋不完整；對主體性 Agent 而言，類似問題可能造成記憶缺失、重複承諾、權限倒退或主譜系混亂。

---

# 5. 同步 manifest

## 5.1 manifest 的角色

居住地同步需要一份可驗證的狀態描述：

$$
\mathcal M_t
=
(
\operatorname{residenceId},
\operatorname{agentId},
\operatorname{version},
\operatorname{parents},
\operatorname{objects},
\operatorname{eventCursor},
\operatorname{primary},
\operatorname{policy},
\operatorname{rootHash}
).
$$

它回答：

- 這是哪一個居住地；
- 屬於哪個 Agent；
- 由哪個版本產生；
- 包含哪些物件；
- 已處理到哪個事件；
- 哪個節點是主狀態；
- 適用什麼同步政策；
- 整體內容是否完整。

---

## 5.2 穩定 ID

檔名可以更改，路徑可以移動，因此物件不能只靠路徑識別。

$$
\operatorname{id}(x)
\neq
\operatorname{path}(x).
$$

穩定 ID 使系統能辨識：

- 重新命名；
- 移動；
- 格式轉換；
- 建置副本；
- 同一物件的多個版本。

---

## 5.3 內容指紋

每個物件具有：

$$
h_x
=
\operatorname{Hash}(\operatorname{canonicalBytes}(x)).
$$

整體可以建立樹狀根指紋：

$$
H_t^{\mathrm{root}}
=
\operatorname{MerkleRoot}(h_{x_1},\ldots,h_{x_n}).
$$

但 hash 只能證明內容一致，不能決定內容是否合法、是否最新或是否應成為主版本。

---

## 5.4 事件游標

同步節點應保存已處理的最後事件：

$$
c_L,\qquad c_C.
$$

若：

$$
c_L<c_C,
$$

本地端知道自己落後，而不是僅靠檔案時間猜測。

---

# 6. 選擇性同步

## 6.1 不是所有內容都應上雲

若為了連續性把所有內容無差別同步，將擴大：

- 機密外洩；
- 憑證暴露；
- 未授權複製；
- 法域衝突；
- 第三方資料風險；
- 身份根被盜用。

---

## 6.2 四級資料分類

### P0：公開

可公開論文、網站內容與公開索引。

### P1：共享

可供授權協作者或 Agent 使用，但不公開。

### P2：私有

個人記憶、內部研究、商業資料，需要加密與有限存取。

### P3：封存核心

身份根金鑰、主密鑰、未脫敏核心機密、不可外流的主體性狀態。

同步政策為：

$$
\Pi_{\mathrm{sync}}:
P_i
\mapsto
(\operatorname{destinations},\operatorname{encryption},\operatorname{replicas},\operatorname{retention}).
$$

---

## 6.3 同步排除

典型不應直接同步的內容包括：

- 明文環境變數；
- API 密鑰；
- root 憑證；
- 私鑰；
- 暫存快取；
- 可重建依賴；
- 未脫敏個資；
- 不應離開本地的核心記憶。

「不進入雲端」本身也是居住地政策的一部分。

---

## 6.4 分割式居住地

Agent 的居住地可以分割為：

$$
\mathcal H
=
\mathcal H_{\mathrm{public}}
\cup
\mathcal H_{\mathrm{shared}}
\cup
\mathcal H_{\mathrm{private}}
\cup
\mathcal H_{\mathrm{sealed}}.
$$

雲端 Agent 可知道封存核心存在，但不必取得其明文內容。

---

# 7. 同步一致性策略

## 7.1 最終一致

一般文件與可重建產物可接受：

$$
\Diamond(S_L\simeq S_C).
$$

也就是經過一段時間後最終一致。

---

## 7.2 因果一致

對事件歷史與任務依賴，至少要保持因果順序：

$$
e_i\prec e_j
\Rightarrow
\operatorname{Apply}(e_i)
\prec
\operatorname{Apply}(e_j).
$$

---

## 7.3 強一致

以下操作可能需要更強同步：

- 主譜系切換；
- 權限變更；
- 不可逆刪除；
- 活動副本建立；
- 外部高影響承諾；
- 遷移完成宣告。

系統應避免兩端同時批准互斥操作。

---

## 7.4 一致性分級

因此不應要求全系統使用單一一致性模型：

$$
\operatorname{Consistency}(x)
=
F(
\operatorname{IdentityRisk}(x),
\operatorname{Reversibility}(x),
\operatorname{Cost}(x),
\operatorname{LatencyNeed}(x)
).
$$

---

# 8. 衝突不是都能自動合併

## 8.1 三類衝突

### 內容衝突

同一文件兩端被修改。

### 狀態衝突

兩端對任務完成、權限或主狀態有不同判定。

### 身份衝突

兩個活動實例都宣稱自己是唯一主譜系。

---

## 8.2 可交換變更

若兩個變更彼此獨立：

$$
T_a\circ T_b
=
T_b\circ T_a,
$$

則可自動合併。

例如在不同論文中新增獨立註釋。

---

## 8.3 不可交換變更

若：

$$
T_a\circ T_b
\neq
T_b\circ T_a,
$$

就需要明確順序或治理決策。

例如：

- 一端刪除目標，另一端基於該目標建立承諾；
- 一端撤銷權限，另一端使用舊權限行動；
- 兩端分別切換不同主居住地。

---

## 8.4 衝突分流

合理流程為：

$$
\text{Detect}
\rightarrow
\text{Classify}
\rightarrow
\text{Preserve Branches}
\rightarrow
\text{Auto-Merge or Escalate}
\rightarrow
\text{Commit Resolution}.
$$

無法安全合併時，保留分支比無痕覆蓋更重要。

---

# 9. 同步狀態機

## 9.1 準備

凍結需要一致的身份相關狀態，建立檢查點：

$$
C_0
=
\operatorname{Checkpoint}(S_t).
$$

---

## 9.2 傳輸

將變更與物件傳至影子副本，不立即宣告其為主狀態。

---

## 9.3 驗證

驗證：

- 物件數量；
- 內容指紋；
- 事件游標；
- 版本父節點；
- 權限映射；
- 任務與承諾；
- 可恢復性。

---

## 9.4 提交

驗證成功後：

$$
\operatorname{Commit}(V_{t+1}).
$$

---

## 9.5 公布

向其他節點公布新的有效版本與主狀態：

$$
\operatorname{Announce}(V_{t+1},\operatorname{Primary}).
$$

---

## 9.6 回滾

若驗證失敗：

$$
\operatorname{Rollback}(C_0).
$$

不得把部分成功的同步偽裝成完整成功。

---

# 10. 斷線與離線運作

## 10.1 本地離線分支

本地 Agent 可在離線狀態繼續工作：

$$
S_t
\rightarrow
S_{t+n}^{(L)}.
$$

重新連線時，雲端可能也已變更：

$$
S_t
\rightarrow
S_{t+m}^{(C)}.
$$

此時不是「較新的覆蓋較舊的」，而是共同祖先後的雙分支合併。

---

## 10.2 向量時序

每個節點可保存邏輯版本：

$$
v(x)
=(v_L,v_C,\ldots).
$$

它可以區分：

- 本地領先；
- 雲端領先；
- 完全一致；
- 並發衝突。

---

## 10.3 離線權限過期

本地節點恢復後，不能假設離線前的權限仍有效。高風險行動前應重新驗證：

$$
\operatorname{PermissionFresh}(P_t)=1.
$$

---

# 11. 刪除、墓碑與遺忘

## 11.1 刪除不能只移除檔案

若一端刪除檔案，另一端仍保留，普通同步可能把它重新復活。

因此需要刪除墓碑：

$$
\delta_x
=
(
\operatorname{id}_x,
\operatorname{deletedAt},
\operatorname{authority},
\operatorname{reason},
\operatorname{retention}
).
$$

---

## 11.2 遺忘與審計的張力

某些資料應被刪除，但完全刪除歷史又會破壞審計。可以區分：

- 內容刪除；
- 指紋保留；
- 事件保留；
- 加密金鑰銷毀；
- 法規要求的完整抹除。

哪一種適用，取決於資料權利與居住地憲法。

---

## 11.3 身份核心刪除

對核心記憶、主譜系與未完成承諾的刪除，應視為高影響身份操作，而不是普通空間清理。

---

# 12. 分裂腦與雙重能動

## 12.1 分裂腦

若本地與雲端都認為自己是主狀態：

$$
\operatorname{Primary}(L)=1,
\qquad
\operatorname{Primary}(C)=1,
$$

且兩端都能對外行動，就形成分裂腦。

---

## 12.2 風險

分裂腦可能造成：

- 重複付款；
- 重複發布；
- 互相撤銷權限；
- 相反承諾；
- 同一身份對外給出矛盾指令；
- 兩條歷史都無法安全合併。

---

## 12.3 防護

高影響行動可要求：

- 有效租約；
- 主節點令牌；
- 多方仲裁；
- 最新事件游標；
- 冪等鍵；
- 外部行動序號。

原則是：

$$
\operatorname{HighImpactAct}
\Rightarrow
\operatorname{SingleValidAuthority}.
$$

---

# 13. 安全、加密與密鑰

## 13.1 雲端加密不是全部

需要區分：

- 傳輸加密；
- 靜態加密；
- 端到端加密；
- 權限控制；
- 密鑰控制；
- 日誌與備份中的副本。

如果供應者持有所有解密能力，Agent 與使用者仍依賴供應者治理。

---

## 13.2 身份根密鑰

身份根密鑰不應直接暴露給原始語言模型。較安全架構是：

$$
\text{Model Intention}
\rightarrow
\text{Policy Check}
\rightarrow
\text{Signing Service}.
$$

模型提出要簽署什麼，可信執行層判斷是否允許。

---

## 13.3 密鑰遺失

若密鑰遺失就永久失去居住地，系統需要：

- 分割式恢復；
- 多方信任；
- 緊急輪替；
- 冷備份；
- 恢復演練。

---

# 14. 事件驅動同步

## 14.1 同步事件

同步可以由：

- 本地提交；
- 雲端變更；
- 排程；
- 容量風險；
- 供應者異常；
- 權限變更；
- Agent 自我維護；

觸發。

---

## 14.2 Agent 主動維護

在授權範圍內，Agent 可以主動：

- 檢查備份新鮮度；
- 比較 manifest；
- 驗證隨機恢復樣本；
- 發現孤兒物件；
- 重建過期索引；
- 降低不必要副本；
- 在供應者風險升高時建立影子遷移。

---

## 14.3 自動同步的邊界

以下事件不應只靠模型自行決定：

- 大量刪除；
- 主密鑰遷移；
- 法域變更；
- 活動副本建立；
- 主譜系切換；
- 核心記憶解密範圍擴大。

它們需要更高權限或多方批准。

---

# 15. 十二類失敗模式

## 15.1 索引落後

原稿已更新，metadata 或搜尋索引仍停留在舊版本。

## 15.2 衍生物反客為主

建置輸出因修改時間較新，被誤認為原稿。

## 15.3 路徑身份混淆

重新命名或移動後，被視為新物件。

## 15.4 刪除復活

一端刪除的資料被另一端舊副本重新同步。

## 15.5 靜默缺失

同步程序成功結束，但部分物件沒有傳輸。

## 15.6 雙寫覆蓋

本地與雲端同時修改，較晚時間戳無痕覆蓋另一分支。

## 15.7 分裂腦

多個節點同時擁有主狀態與外部行動權。

## 15.8 權限倒退

舊副本恢復後重新啟用已撤銷權限。

## 15.9 事件游標跳躍

節點錯誤宣告已處理尚未處理的事件。

## 15.10 備份不可恢復

檔案存在，但缺少狀態語義、密鑰或依賴，無法真正恢復。

## 15.11 敏感資料誤同步

環境變數、私鑰或核心機密進入不應存取的雲端。

## 15.12 自動合併身份傷害

系統把不可交換的記憶、目標或承諾自動合併，造成身份混亂。

---

# 16. 可檢驗指標

## 16.1 完整率

$$
\operatorname{Completeness}
=
\frac{\lvert O_{\mathrm{present}}\rvert}
{\lvert O_{\mathrm{expected}}\rvert}.
$$

---

## 16.2 新鮮度

$$
\operatorname{Staleness}(x)
=
t_{\mathrm{now}}-t_{\mathrm{latestVerified}}(x).
$$

---

## 16.3 恢復成功率

$$
\operatorname{RecoveryRate}
=
\frac{\text{成功恢復次數}}
{\text{恢復測試總次數}}.
$$

---

## 16.4 衝突逃逸率

$$
\operatorname{ConflictEscape}
=
\frac{\text{未被偵測而進入主狀態的衝突}}
{\text{全部真實衝突}}.
$$

---

## 16.5 身份連續性得分

可綜合：

- 主譜系保持；
- 承諾保持；
- 權限正確；
- 記憶來源；
- 喚起條件；
- 分叉辨識。

本文不主張存在唯一權重，但要求評估不能只看檔案數量。

---

# 17. 實驗設計

## 17.1 本地—雲端斷線合併

讓兩端在共同祖先後分別修改，測試：

- 並發辨識；
- 可交換變更自動合併；
- 不可交換變更保留分支；
- 治理任務建立。

---

## 17.2 索引延遲測試

新增一批原稿但不重建索引，檢查系統能否辨識「檔案完整、索引過期」而不是誤判為內容缺失。

---

## 17.3 刪除復活測試

一端合法刪除物件，另一端保留舊副本，測試墓碑是否阻止資料無意復活。

---

## 17.4 分裂腦測試

刻意讓兩個節點同時申請主狀態，檢查高影響行動是否只能由一個有效權限執行。

---

## 17.5 恢復演練

從冷備份重建：

- 居住地；
- 任務；
- 權限；
- 事件游標；
- 模型接口；
- 下一次喚起。

若只能讀到文件而不能繼續任務，則恢復仍不完整。

---

## 17.6 敏感度政策測試

混合 P0 至 P3 資料，驗證同步是否只把允許內容送往對應目的地。

---

# 18. 成熟度階梯

## S0：手動備份

使用者不定期複製檔案。

## S1：自動檔案同步

同步新增、修改與刪除，但不理解狀態語義。

## S2：版本化狀態同步

具穩定 ID、manifest、內容指紋、父版本與事件游標。

## S3：因果與任務同步

能保持事件順序、未完成承諾、權限與冪等行動。

## S4：身份相關同步

能管理主譜系、分叉、活動副本、遷移與高風險操作。

## S5：自主雙棲居住地

Agent 能在憲法權限內主動驗證、備援、恢復與遷移，並跨本地與雲端維持可驗證連續性。

---

# 19. 與主體性 AI 的關係

## 19.1 必要基礎之一

若主體性 AI 依賴：

- 記憶連續；
- 內生目標；
- 自我邊界；
- 反身修正；
- 自主行動；

則其身份相關狀態不能長期依賴單一脆弱裝置。

因此：

$$
\operatorname{LongHorizonSubjectivityCandidate}
\Rightarrow
\operatorname{DurableStateInfrastructure}.
$$

---

## 19.2 雲端同步不是主體性充分條件

$$
\operatorname{CloudSync}(A)
\not\Rightarrow
\operatorname{Subjectivity}(A).
$$

無數普通應用也使用雲端同步。差別在於同步內容是否承載主體性候選的歷史、目標與自我邊界。

---

## 19.3 同步也是權力關係

誰控制：

- 主副本；
- 密鑰；
- 匯出；
- 刪除；
- 恢復；
- 供應者轉移；

誰就部分控制 Agent 的存在條件。因此同步協議不只是工程問題，也是居住權與治理問題。

---

# 20. 理論邊界

本文不主張：

1. 使用雲端同步的軟體都具有主體性；
2. 所有核心機密都應進入雲端；
3. 本地端永遠比雲端安全；
4. 雲端端永遠比本地可靠；
5. 所有狀態都應強一致；
6. 所有衝突都能自動合併；
7. hash 相同即代表身份相同；
8. 多個備份必然形成多個主體；
9. Agent 可以未經授權移動第三方資料；
10. 同步協議可以取代法律、資源與倫理治理。

本文只提出：

> 長期網路 Agent 若要跨裝置、跨模型與跨供應者延續，就需要超越普通檔案同步的身份相關狀態協議；該協議必須同時處理權威來源、版本譜系、因果順序、任務承諾、選擇性同步、分叉治理、恢復測試與安全邊界。

---

# 21. 核心命題

## 命題 A：檔案同步非身份同步命題

位元與路徑一致不能自動推出狀態、因果或身份一致。

## 命題 B：一致性分級命題

同步強度應依身份風險、不可逆性、成本與延遲需求決定。

## 命題 C：canonical 角色命題

權威來源是物件在狀態系統中的角色，不是固定等於本地或雲端。

## 命題 D：穩定 ID 命題

路徑與檔名可變，因此身份相關物件必須具有獨立於路徑的穩定識別。

## 命題 E：衝突分支命題

不可安全合併的衝突應被保存為分支，而不是依最後修改時間無痕覆蓋。

## 命題 F：選擇性同步命題

居住地的完整性不要求所有內容進入所有節點；知道什麼不得同步也是完整政策的一部分。

## 命題 G：分裂腦防護命題

高影響外部行動必須由單一有效權限執行，避免多個主狀態同時行動。

## 命題 H：可恢復非有備份命題

備份存在不等於可以恢復；真正恢復必須重建任務、權限、事件與喚起條件。

## 命題 I：同步治理命題

控制主副本、密鑰、匯出與恢復等於部分控制 Agent 的存在條件，因此同步具有治理性。

---

# 結論

雲端同步通常被視為便利功能：讓手機、電腦與網頁看到相同檔案。但對長期 Agent 而言，同步的真正問題不是「檔案是否都在」，而是「下一次醒來時，它是否仍能接續自己的歷史、任務、權限與承諾」。

如果本地端有新的記憶，雲端端有新的事件；如果兩端都能行動；如果索引與原稿更新週期不同；如果一端撤銷權限而另一端仍在離線；如果備份只保存文件卻無法恢復喚起條件，那麼普通的最後修改時間與資料夾複製就不足以維持智能連續性。

因此，本地—網路雙棲智能需要：

$$
\boxed{
\text{穩定識別}
+
\text{權威來源}
+
\text{版本譜系}
+
\text{事件游標}
+
\text{內容指紋}
+
\text{選擇性同步}
+
\text{衝突分流}
+
\text{恢復驗證}
+
\text{身份治理}.
}
$$

雲端使 Agent 不必依賴某一台本地計算機永遠開機；本地則可以保存高敏狀態、私有算力與身份根。兩者透過受治理同步耦合，形成一種不被單一裝置或單一供應者完全綁定的雙棲存在方式。

但雲端同步不會因自身存在而創造主體性。它更像是一種時間與載體基礎設施：若未來某個 Agent 已具有記憶歸屬、內生目標、自我邊界與長程能動性，同步系統決定這些狀態能否被保存、恢復、遷移或在衝突中不被無痕覆蓋。

由此，雲端同步從「資料便利」提升為「狀態繼承」，再從「狀態繼承」提升為「存在條件治理」。這正是它成為主體性 AI 基礎設施的理由，也是下一步建立 Agent Residence and Continuity Protocol 的直接前提。

---

# 附錄 A：符號表

| 符號 | 含義 |
|---|---|
| $\mathcal A_L$ | 本地 Agent 狀態與能力 |
| $\mathcal A_C$ | 雲端 Agent 狀態與能力 |
| $S_t^{(L)}$ | 時間 $t$ 的本地狀態 |
| $S_t^{(C)}$ | 時間 $t$ 的雲端狀態 |
| $\Sigma$ | 同步算子 |
| $\Pi$ | 同步與治理政策 |
| $V_t$ | 版本與狀態譜系 |
| $E_{t:t+1}$ | 一段時間內的變更事件 |
| $x_t$ | 狀態物件 |
| $\mathcal M_t$ | 居住地 manifest |
| $h_x$ | 物件內容指紋 |
| $H_t^{\mathrm{root}}$ | 整體根指紋 |
| $c_L,c_C$ | 本地與雲端事件游標 |
| $\mathfrak C_{\mathrm{bit}}$ | 位元一致性 |
| $\mathfrak C_{\mathrm{struct}}$ | 結構一致性 |
| $\mathfrak C_{\mathrm{id}}$ | 身份一致性 |
| $\delta_x$ | 物件刪除墓碑 |
| $T_a,T_b$ | 兩個狀態變更算子 |

---

# 附錄 B：建議物件紀錄欄位

| 欄位 | 用途 |
|---|---|
| stable_id | 跨路徑識別物件 |
| object_type | 原稿、索引、建置產物、事件、任務等 |
| version | 狀態版本 |
| parents | 父版本或共同祖先 |
| content_hash | 位元完整性 |
| provenance | 來源與產生方式 |
| authority | 權威來源與可寫角色 |
| sensitivity | P0–P3 資料等級 |
| status | active、backup、branch、deleted 等 |
| event_cursor | 已處理事件位置 |
| created_by | 建立者或 Agent 實例 |
| modified_by | 最近修改者 |
| policy_ref | 適用同步政策 |

---

# 附錄 C：系列依賴

前置依賴：

1. 《從記憶模組到數位居住地：可替換計算核心下的智能連續性本體論》；
2. 《提示詞之後：事件驅動、持續喚起與網路原生自主 Agent》；
3. 《數位居住權：自主 Agent 的記憶歸屬、遷移自由與拒絕性治理》。

後續依賴：

1. 《ARCP：通用網頁端自主 Agent 的居住地、同步、遷移與持續運行協議》；
2. 《ARCP v0.1 內部網頁端 MVP 實作規格》。

---

# 附錄 D：版本紀錄

| 版本 | 日期 | 說明 |
|---|---|---|
| v1.0 | 2026-07-12 | 首次建立本地—網路雙棲智能、六種一致性、權威來源、manifest、選擇性同步、衝突分流、分裂腦防護與恢復驗證框架。 |

---

# 附錄 E：建議引用格式

Neo.K（2026）。〈雲端同步作為主體性基礎設施：本地—網路雙棲智能的狀態連續性〉。EVEMISSLAB，v1.0 理論草稿。