作者: Neo.K
日期: 2026-07-16
版本: v0.1
狀態: 觀察論文／公開概念草案
語言: zh-TW
原始檔: papers/01-control-plane-transition.zh-Hant.md

從路徑容器到智能封裝

AI 原生無損壓縮格式的控制平面轉移命題

作者： Neo.K 日期： 2026 年 7 月 16 日 文件性質： 觀察論文／公開概念草案

摘要

ZIP、TAR、7z 等傳統封裝格式主要被設計為人類操作的檔案容器：人類選擇檔案、設定壓縮選項、建立封裝，再由另一位人類或應用程式解壓。即使現代壓縮工具加入自動偵測、內容預覽與更好的 Unicode 支援，格式的控制平面仍然大致停留在「人類發出壓縮命令，工具執行固定策略」的模式。

當 AI Agent 開始管理程式專案、研究資料、遊戲資源、模型檔案與跨平台工作空間時，壓縮系統需要面對新的操作者。AI 不只需要呼叫「壓縮」與「解壓縮」，還需要自主分析檔案類型、測量可壓縮性、選擇無損 Codec、規劃分塊、建立索引、增量更新、局部物化、驗證完整性，以及記錄每一次封裝決策。

本文提出「控制平面轉移命題」：

壓縮格式的下一個重要演進，不一定首先來自更高的單一 Codec 壓縮率，而可能來自封裝控制平面由人類手動設定，轉向 AI 可規劃、可審計、可重放的自主操作。

然而，AI 原生不應等同於生成式重建，也不應容許模型以摘要、提示詞、語義近似或可再生成判斷取代原始資料。本文因此提出一個嚴格邊界：

AI 可以決定如何保存，但不能決定原始位元是否值得保存；凡被宣告納入封裝的資料，必須由模型獨立、確定性且可驗證的解碼器完整恢復。

本文將 AI 原生無損封裝定義為保存平面與智能平面的分離：保存平面承擔原始內容、路徑、Metadata、完整性與復原責任；智能平面負責規劃、索引、查詢與自動化。智能平面可以被刪除或重建，而保存平面仍須保持完整可解碼。此設計使格式同時獲得 AI 操作能力與長期數位保存能力，避免檔案生命週期依賴特定模型、供應商或推理結果。

關鍵詞： AI 原生格式、無損壓縮、封裝格式、Coding Agent、內容定址、確定性解碼、模型獨立性、壓縮控制平面

一、問題不是 ZIP 不夠新，而是操作者已經改變

1.1 傳統格式的歷史成功

ZIP 的生命力不只來自壓縮演算法。它更大的優勢是：

廣泛的作業系統支援。
大量程式語言與標準函式庫支援。
電子郵件、瀏覽器、雲端硬碟與通訊工具支援。
使用者已形成穩定認知。
各種文件與應用格式沿用 ZIP 容器。
數十年工具鏈已累積龐大相容性。

因此，ZIP 的市場地位可粗略表示為：

V_ZIP = V_codec + V_compatibility + V_installed\ base + V_social\ expectation

即使其他格式在壓縮率、加密或 Unicode 設計上更現代，也很難一次取代後三項。

ZIP 規範後來加入 UTF-8 旗標與 Unicode Path Extra Field，以改善早期檔名編碼缺乏自描述資訊的問題。但大量歷史封裝仍可能只保存本地 Code Page 位元組，使接收端必須依賴外部語境或人工選擇才能正確解碼。這顯示格式一旦形成長期路徑依賴，早期缺少的語境資訊可能持續成為後世工具的負擔。

1.2 傳統壓縮工具仍以人類為控制中心

典型流程是：

人類選擇檔案
→ 人類選擇 ZIP／7z
→ 人類設定壓縮等級
→ 工具依固定策略處理
→ 人類命名並移動壓縮檔

這種流程預設操作者具有：

對目錄的視覺理解。
對壓縮率與速度的主觀偏好。
對路徑與編碼的人工判斷。
對重要檔案的先驗知識。
對解壓位置和覆蓋風險的責任。

即使壓縮軟體提供自動模式，決策通常仍是局部且不可審計的。工具可能根據副檔名選擇壓縮方式，但不會輸出完整的機器可讀計畫，說明：

為何如此分塊。
為何選擇某 Codec。
哪些區塊被去重。
哪些 Metadata 被保存。
哪些平台屬性無法恢復。
此封裝是否可做局部物化。
更新時是否必須重新封裝全部資料。

對人類偶爾壓縮一個資料夾而言，這些缺口可以接受；對自主維護大型工作空間的 Agent 而言，它們會變成系統性限制。

二、AI 原生不是「壓縮工具加聊天框」

2.1 介面包裝不等於原生格式

若 AI 只是在 GUI 或 CLI 外層呼叫：

7z a project.7z project/

那只是 AI 使用傳統工具。它並沒有改變封裝格式的能力模型。

真正的 AI 原生封裝應讓 Agent 能直接處理：

檔案集合分析。
不同資料類型的無損 Codec 選擇。
固定分塊或內容定義分塊。
跨檔案與跨版本去重。
快速與高壓縮模式的混合。
大檔案隨機存取。
小檔案聚合。
增量版本。
遠端局部下載。
路徑語境與平台 Metadata。
完整性、簽章與損壞復原。
結構化決策紀錄。

因此，AI 原生的核心不是自然語言介面，而是格式提供可組合、可查詢與可驗證的控制面。

2.2 從「命令」轉向「封裝計畫」

傳統壓縮輸入通常只有：

(source,format,level)

AI 原生系統的輸入更接近：

P = (C, K, D, M, I, S, V)

其中：

$C$ ：Codec 配置。
$K$ ：Chunking 配置。
$D$ ：Deduplication 配置。
$M$ ：Metadata 保存配置。
$I$ ：Index 配置。
$S$ ：Security 與資源限制。
$V$ ：Versioning 與更新策略。

AI 的作用是根據檔案集合 $F$ 和使用者政策 $Π$ 產生封裝計畫：

P = Plan_AI(F,Π)

但計畫不能直接等同於封裝結果。它必須交給確定性寫入器驗證：

A = W(F,P)

其中 $W$ 必須拒絕：

未覆蓋的輸入物件。
有損 Codec。
無法識別的 Decoder。
缺少完整性資訊的 Chunk。
不符合政策的 Metadata 遺失。
未聲明的路徑正規化。
超出安全限制的參數。

三、無損底線

3.1 內容保真不變量

令 $F={f₁,f₂,\dots,fₙ}$ 為被宣告納入封裝的檔案集合， $A$ 為封裝結果， $D$ 為標準解碼器。最基本要求為：

D(A)=F

對每個檔案內容，必須滿足：

H(fᵢ)=H(fᵢ̂), \forall i

其中：

$H$ 是規範指定的密碼雜湊。
$fᵢ̂$ 是解壓後內容。

這是位元級要求，不是語義相似要求。

以下條件都不能代替上述等式：

文字意思相同。
圖片看起來相似。
影片品質評分足夠高。
程式可以重新編譯。
模型可以重新生成。
依賴可以重新下載。
Agent 判斷檔案不重要。

3.2 封裝範圍和資料省略必須分離

AI 可以建議使用者排除快取、建置產物或可下載依賴，但「排除」必須發生在封裝集合形成之前。

令原始工作空間為 $U$ ，使用者批准的封裝集合為：

F = Select(U,Π)

無損承諾只對 $F$ 成立：

D(W(F,P))=F

若某個檔案不在 $F$ 中，Manifest 必須明確記錄它未被封裝，不能讓使用者誤以為整個工作空間已完整保存。

這使以下兩件事不再混淆：

封裝範圍決策。
封裝範圍內的無損壓縮。

3.3 Metadata 也需要分級保真

「檔案內容完全相同」不代表工作空間完全相同。某些系統還依賴：

路徑與大小寫。
權限。
ACL。
符號連結。
Hard Link。
稀疏區段。
Extended Attributes。
Alternate Data Streams。
Resource Fork。
建立與修改時間。
Reparse Point。

因此應區分：

內容級無損

F_content \equiv F̂_content

命名空間級無損

F_namespace \equiv F̂_namespace

平台 Metadata 級無損

F_metadata \equiv F̂_metadata

跨平台解壓時，目標檔案系統可能無法原樣套用所有 Metadata。此時解碼器必須保留原 Metadata 並輸出明確報告，而不能默默丟棄後仍宣稱完全恢復。

四、保存平面與智能平面

4.1 保存平面

保存平面包含解壓原始資料所需的一切：

Preservation Plane
├─ 格式版本與能力聲明
├─ 物件清單
├─ 原始檔案內容
├─ Chunk Map
├─ Codec 與參數
├─ 路徑和平台 Metadata
├─ 內容雜湊
├─ Snapshot Root
├─ 簽章
└─ 復原資訊

保存平面具有四個特性：

公開可實作。
不依賴模型推理。
解碼結果確定。
長期可驗證。

4.2 智能平面

智能平面包含 Agent 工作所需的衍生資料：

Intelligence Plane
├─ 壓縮決策紀錄
├─ 檔案類型與語言標註
├─ 搜尋索引
├─ 相似內容索引
├─ 任務相關檢視
├─ Agent 操作日誌
├─ 存取熱度提示
└─ 可重建的語義索引

智能平面可以由不同模型重建，因此不能成為恢復原始內容的必要條件。

形式上：

A = (P,I)

其中：

$P$ ：保存平面。
$I$ ：智能平面。

必須滿足：

D(P,I)=D(P,\emptyset)=F

這稱為「智能層可拋棄性」。

4.3 模型獨立性判準

若一個格式只能由建立它的模型正確解壓，它就不是可靠的檔案格式，而是模型綁定的生成協議。

AI 原生格式應滿足：

Dₘ₁ (A)=Dₘ₂ (A)=D_nonAI(A)=F

其中：

$m₁$ 、 $m₂$ 是不同模型。
$D_nonAI$ 是不含模型的規範解碼器。

模型可以改變封裝效率，但不能改變解壓真值。

五、控制平面轉移命題

5.1 命題內容

本文提出：

控制平面轉移命題： 當 AI Agent 能持續管理大量異質檔案時，壓縮系統的主要創新焦點將由單一 Codec 的壓縮率，逐步轉向可由 Agent 規劃、驗證、更新與局部物化的封裝控制平面。

這並不否定 Codec 研究。Codec 仍決定特定資料的空間與時間效率。但在多類型工作空間中，整體效果還取決於：

E_archive = f( E_codec, E_chunk, E_dedup, E_index, E_update, E_access )

其中：

$E_codec$ ：單區塊壓縮效率。
$E_chunk$ ：分塊效率。
$E_dedup$ ：去重效率。
$E_index$ ：檢索效率。
$E_update$ ：增量更新效率。
$E_access$ ：局部存取效率。

AI 的優勢在於可根據整個工作空間和任務歷史動態協調這些維度。

5.2 Agent 可做而固定預設難以完成的事

例如同一封裝中：

原始碼適合較小 Chunk，以提高增量去重。
大型已壓縮影片應使用 Store，避免浪費 CPU。
重複模型權重可使用較大 Chunk 與跨版本去重。
數千個小文字檔可先聚合，再使用字典壓縮。
高頻讀取索引可放在前部或獨立快速區。
冷資料可選高壓縮、慢編碼但快速解碼的設定。
遠端工作空間可建立局部物化索引。
Windows、Linux 與 macOS Metadata 可分 namespace 保存。

傳統工具可以透過大量人工選項做到其中部分，但 AI 能將這些選擇轉為可重放計畫，並根據真實測試結果調整。

六、為什麼現有格式只提供部分答案

6.1 ZIP

ZIP 提供廣泛相容性、逐檔案封裝與多種擴充欄位，但其歷史包袱包括：

舊檔名編碼可能缺乏自描述。
中央目錄和局部標頭形成複雜一致性問題。
增量與跨版本去重不是核心模型。
Agent 決策與索引不是第一級結構。

ZIP 適合作為匯出交換格式，但不必成為 AI 原生系統的內部極限。

6.2 7z

7z 具有更現代的 Unicode 與壓縮設計，也支援固實壓縮等能力，但它主要仍是高效率壓縮容器，而非 Agent 的版本化工作空間封裝協議。

6.3 CAR 與內容定址封裝

IPLD CAR 將內容定址區塊串流化，證明 Archive 可以圍繞內容 Hash 和物件圖，而不只圍繞路徑樹。但 CAR 並不直接定義完整跨平台檔案 Metadata、壓縮策略治理或 AI 決策平面。

6.4 OCI Image

OCI Image Specification 使用 Manifest、Descriptor 和內容定址 Blob，並可用 Index 指向不同平台版本。它證明 Manifest 與 Payload 分離、內容定址和平台檢視具有強大互通性。但 OCI 的主要目標是容器映像，而非任意工作空間的通用保存。

6.5 BagIt

BagIt 要求 Payload Manifest 完整列出檔案及其校驗資訊，適合可靠傳輸與數位保存。它提供重要啟示：完整性清單應是封裝規範的核心，而非事後附加功能。但 BagIt 不是以高效率 Chunk、去重、隨機存取與 Agent 更新為主要目標。

七、可反駁條件

控制平面轉移命題並不是必然正確。以下情況可削弱它。

7.1 AI 規劃收益不足

若實驗顯示，AI 產生的混合分塊與 Codec 計畫，相較固定 Zstandard 或 7z 設定沒有穩定收益，卻顯著增加複雜度，則 AI 規劃不應成為格式核心賣點。

7.2 決策成本高於節省成本

令規劃成本為 $Cₚ$ ，節省的儲存、傳輸與解壓成本為 $Bₛ$ 。若長期滿足：

Cₚ > Bₛ

則自主規劃沒有工程價值。

7.3 格式複雜度破壞互通性

若新格式因包含過多可選能力而造成：

不同實作無法互通。
Decoder 容易出現安全漏洞。
無法建立最小讀取器。
Archive 必須依賴大型 Runtime。

則它可能重蹈複雜格式的失敗。

7.4 人類與一般程式無法使用

AI 原生不應排斥人類。若格式只能由 Agent 操作，卻沒有穩定 CLI、函式庫與檔案系統掛載方式，它就難以形成真正生態。

八、研究與實驗設計

8.1 測試資料集

至少應包含：

大量小型原始碼檔案。
大型二進位模型。
已壓縮圖片與影片。
Office／PDF 文件。
遊戲資源與舊編碼檔名。
多版本 Repository。
Windows、Linux、macOS Metadata。
大型稀疏檔案。
重複備份資料。

8.2 比較基線

ZIP Deflate。
7z LZMA2。
TAR + Zstandard。
固定大小 Chunk + Zstandard。
FastCDC + Zstandard。
AI 規劃的混合策略。

8.3 指標

儲存

R_c = (archive bytes) / (original bytes)

封裝速度

Tₚ = (input bytes) / (pack time)

解壓速度

T_u = (output bytes) / (unpack time)

增量效率

RΔ = (new archive bytes) / (changed source bytes)

局部物化效率

Lₘ = time to materialize requested object set

保真

Q_f = 1, & 所有要求的內容與 Metadata 驗證通過 0, & 任一必要項目不一致

在無損格式中，保真不是連續評分，而是規範層的通過或失敗。

九、治理原則

9.1 AI 只能提出計畫

最終寫入器必須：

驗證 Codec 為無損。
驗證每個輸入位元組都有對應 Chunk。
驗證所有 Chunk 可解碼。
驗證 Manifest 完整。
驗證路徑與 Metadata 政策。
在完成後執行抽樣或完整 Round Trip。

9.2 未知能力必須拒絕或降級

Decoder 不可猜測未知 Codec 或未知 Metadata 語義。

遇到未知必要能力時：

MUST fail

遇到未知可選智能索引時：

MAY skip

這能確保格式擴充不破壞保存核心。

9.3 智能索引不得污染保存真相

AI 標註可能錯誤，例如：

語言判斷錯誤。
MIME 推斷錯誤。
檔案關係錯誤。
重要性分類錯誤。

因此它們必須標示：

產生者。
模型或工具版本。
時間。
信心。
是否人工確認。
可否重建。

錯誤索引可以刪除；原始檔案不能受到影響。

十、結論

AI 原生壓縮格式不是讓模型代替人類按下壓縮按鈕，也不是讓生成模型用近似內容取代原始資料。

它真正代表兩個同時發生的變化：

第一，壓縮與封裝的控制平面開始能由 Agent 自主規劃。AI 可以根據檔案類型、版本關係、存取模式與資源條件，決定無損 Codec、分塊、去重、索引與更新策略。

第二，資料保存必須比過去更嚴格。因為決策者不再永遠是人類，格式需要用不變量、Manifest、Hash、能力聲明與確定性 Decoder 限制 AI 的自由。

本文的核心定義是：

AI 原生無損封裝，是允許 AI 自主規劃、建立、索引、更新與查詢，但由公開、確定性、模型獨立的解碼器保證所有納入封裝的原始內容與受保護 Metadata 可精確恢復的格式。

因此，真正的創新不在「讓 AI 決定哪些資料可以失去」，而在：

讓 AI 擁有封裝智能，同時讓格式本身拒絕資訊失真。

參考資料

PKWARE, APPNOTE.TXT — ZIP File Format Specification. https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

IETF, RFC 8878: Zstandard Compression and the application/zstd Media Type. https://www.rfc-editor.org/rfc/rfc8878

W. Xia et al., FastCDC: A Fast and Efficient Content-Defined Chunking Approach for Data Deduplication, USENIX ATC 2016. https://www.usenix.org/conference/atc16/technical-sessions/presentation/xia

IETF, RFC 8949: Concise Binary Object Representation (CBOR). https://www.rfc-editor.org/rfc/rfc8949

BLAKE3 Team, BLAKE3 Specification and Reference Implementations. https://github.com/BLAKE3-team/BLAKE3 https://github.com/BLAKE3-team/BLAKE3-specs

IPLD, Content Addressable aRchives Specification. https://ipld.io/specs/transport/car/

Open Container Initiative, OCI Image Specification. https://github.com/opencontainers/image-spec

IETF, RFC 8493: The BagIt File Packaging Format. https://www.rfc-editor.org/rfc/rfc8493

IETF, RFC 9052: CBOR Object Signing and Encryption. https://www.rfc-editor.org/rfc/rfc9052