Benjamin Bratton《The Stack》如何重畫主權？六層架構、雲端城市與AI基礎設施

六層架構真正改變的是提問順序

讀《The Stack》最容易遇到的誤區，是把 Earth、Cloud、City、Address、Interface、User 當成一張漂亮的分類表，背完名詞就以為理解了理論。MIT Press 對本書的介紹，將它描述為把智慧電網、雲端平台、行動應用、智慧城市、物聯網與自動化視為一個「意外形成的巨型結構」。這個說法的重點不在於創造另一套技術術語，而在於改變提問順序：看到一個 App 或 AI 功能時，先不要只問它做得好不好，也要問它依賴哪些物質、哪些系統、哪些身分與哪些權限。

這種提問會把「數位服務」從螢幕上拉回整條供應鏈。一次登入可能同時涉及裝置、網路、資料中心、帳號資料庫、風險模型、介面設計與客服制度；一次 AI 回答也不是單純由模型在雲端吐出文字，而是由晶片、電力、冷卻、訓練資料、推論服務、API、使用者授權與輸出場景共同完成。六層架構的價值，是讓這些通常被分開報導的因素重新出現在同一張地圖上。

Earth：先問一朵雲需要多少地面

Cloud 這個詞很容易製造無重量的錯覺，好像資料只要上傳，就離開了地理與材料世界。Earth 層提醒我們，雲端從來沒有離開地球。伺服器需要礦物、晶片、機櫃、電力與冷卻水，資料中心需要土地、建築、交通與維修勞動。當 AI 模型規模增加，討論不能只停在參數量與回應速度，也要追蹤能源需求、設備更新週期、供應鏈集中與環境成本。

Earth 層不是把所有科技批評都簡化成環保口號，而是要求把基礎條件寫進技術敘事。若一家公司宣稱服務可以無限擴張，讀者可以追問：擴張需要新增什麼硬體？能源和水由誰提供？設備淘汰後如何處理？若答案完全消失在「雲端」兩個字裡，代表文章只寫了介面效果，沒有寫完整系統。

這一層也會改變台灣科技議題的閱讀方式。半導體、電力、水資源、科學園區、土地規劃與全球製造網路，不是彼此獨立的新聞分類，而是同一套運算基礎的不同面向。把台灣只寫成晶片產地，會漏掉它在全球 Stack 中同時扮演製造、能源、人才、地緣政治與基礎設施節點的角色。

Cloud：平台的權力來自共同底層

Cloud 層包含資料中心、網路骨幹、儲存、運算、模型與平台服務。它的政治效果不只是「速度更快」，而是讓很多不同產業共享同一組底層。當政府服務、金融交易、醫療系統、媒體發布與小型商家的工作流程都依賴同一批雲端供應者，服務條款、價格調整、維修中斷或資安政策就可能產生接近公共基礎設施的影響。

這不代表平台已經變成國家，也不代表國家在數位時代消失。比較精確的說法是，國家法律、公共預算與平台技術互相嵌合，治理權力分散在不同層級。政府可能依賴私人雲端執行公共服務，平台則需要國家提供土地、電力、法規、人才與市場。兩者不是單純的二選一，而是要追問每一項依賴關係由誰談判、誰能退出、誰有替代方案。

對使用者而言，Cloud 最直接的問題是可攜性。當照片、工作文件、商店訂單、付款紀錄與模型工作流都留在一個平台裡，離開平台的成本就可能高到足以改變選擇。真正的競爭不能只看誰的首頁更漂亮，也要看資料能否匯出、服務能否互通、帳號能否申訴，以及停機時是否有可用的替代路徑。

City：城市被感測，不代表城市被理解

City 層把運算拉入街道、建築與公共服務。交通號誌、票證、攝影機、手機定位、物流平台與建築管理系統，讓城市持續產生可計算的資料。這些系統確實可以改善交通安排、能源使用與公共服務，但「可以被測量」不等於「已經被正確理解」。一個模型能預測人流，仍可能不理解某個社區為什麼在特定時間需要停留、繞路或拒絕被紀錄。

城市資料的治理問題因此不只在技術準確率，也在資料的代表性與申訴權。誰的移動被完整記錄？誰因為沒有智慧型手機、穩定網路或可接受的地址而被排除？自動化決策出錯時，居民能否知道資料從哪裡來、要求更正、請真人覆核？如果城市只被當成一個可最佳化的儀表板，人的生活差異就會被壓成幾個方便管理的指標。

把 City 放回六層結構，也能避免把智慧城市寫成單一建設案。感測器需要 Cloud 儲存與分析，Cloud 需要 Earth 的能源與設備，服務則透過 Address 辨識人和地點，再由 Interface 把結果交給 User。城市治理的責任不會因為外包給平台而消失，只會更需要清楚標記每個環節。

Address：被辨認是便利，也是權力

Address 不只是門牌號碼。IP、GPS 座標、網域、手機號碼、帳號、裝置識別碼、會員編號與生物特徵，都可能成為系統用來辨識「誰」或「哪裡」的地址。沒有地址，服務很難把資源送到正確對象；但地址一旦被大量串接，也可能讓不同情境下原本分開的行為被拼成一個可追蹤的人。

因此，帳號驗證不是純粹的登入流程，而是進入制度的門。當工作、醫療、支付、社群表達與公共服務都要求不同形式的身分，使用者要承擔的不只是輸入密碼，還包括錯誤標記、資料外洩、帳號遭盜與誤封鎖的風險。好的系統不應只追求辨識率，也要提供更正、申訴、撤回與最低必要資料的選項。

AI Agent 進入 Address 層後，問題會更複雜。Agent 可能使用一個人的帳號、企業的 API 金鑰或服務專用的機器身分；它的行動看似來自使用者，實際上可能經過多個委託關係。治理不能只問「誰按下按鈕」，還要問 Agent 取得了什麼身分、身分有效多久、能否被追溯，以及它能否把錯誤行動歸還給真正負責的人。

Interface：選項的排列就是一種規則

Interface 層最貼近一般人的日常，也最容易被誤認為只是視覺設計。其實介面決定使用者看到什麼、哪些選項被放在最前面、什麼風險被藏在細小文字裡，以及出錯後能不能回到上一個狀態。推薦排序、付款按鈕、同意視窗、帳號停權通知與 AI 的工具權限，都是介面在把制度規則翻譯成可操作的形式。

一個平台可以在條款裡承諾使用者有申訴權，卻在介面上只提供一個無法追蹤的表單；也可以宣稱資料能下載，實際上只給出難以使用的格式。這些不是小瑕疵，而是權利是否真的能被行使。設計評估因此應包含可逆性、可理解性、替代入口與人工協助，而不只是轉換率和使用時長。

AI 介面同樣不能只看回答是否自然。要檢查它是否清楚標示正在讀取哪些資料、即將呼叫哪些工具、哪些內容是推測、哪些動作需要再次確認。當 Agent 能付款、發信、發布、刪除或修改資料時，介面必須讓使用者知道行動的範圍與後果，並保留停止和回復的機會。否則「自動化」只是把責任藏到按鈕後面。

User：使用者已經不只是一個人

User 層包含人，也可能包含企業、裝置、感測器、Bot、車輛和 AI Agent。這個擴張會改變傳統的責任模型。人類使用者可以表達意圖，但機器使用者能以速度、數量與持續性放大行動；一個錯誤的 Agent 規則，可能在幾分鐘內影響大量帳號、訂單或公共資訊。

所以設計 Agent 時，最重要的不只是讓它「會做事」，而是讓它的權限可被理解、限制、暫停和稽核。取得身分的方式、可呼叫的工具、能讀寫的資料、每次行動的確認門檻，都應該有明確邊界。尤其在高影響場景裡，不能把「模型很有能力」當成「模型可以被授權」的理由。

User 層也提醒我們，使用者不是平台統計裡的一個可替換數字。每個帳號背後可能是工作、收入、家庭照護或公共表達。當系統封鎖一個人，真正被中斷的可能是一整條生活路徑。因此，帳號處分需要理由、通知、申訴與人工判斷，不能只把人當成風險分數。

六層如何一起解釋一次叫車與一次 AI 行動

叫車是一個容易理解的例子。乘客與司機是 User，手機 App 是 Interface，帳號、GPS 與車輛識別是 Address，街道與交通系統是 City，配對、計價與通知由 Cloud 完成，而手機、車輛、基地台、電力與晶片則把服務落到 Earth。若只研究 App 的按鈕，就會看不到司機如何被分派、價格如何形成、城市如何被重新安排，以及平台中斷時誰承擔損失。

AI Agent 的行動也可以用同一方式檢查。使用者在 User 層提出目標，Agent 透過 Interface 或 API 取得工具，使用帳號與金鑰通過 Address，從 Cloud 取得模型與資料，可能進一步影響 City 中的物流、排程或公共資訊，最後消耗 Earth 層的硬體與能源。這條路徑越長，越不能只用一句「使用者同意了」來解釋所有責任。

實務上可以為每次高影響 Agent 行動留下最小紀錄：誰授權、授權到什麼範圍、使用了哪個工具、寫入了什麼資料、何時可以撤銷、發生錯誤時由誰處理。這不是為了把所有生活都變成稽核表，而是讓跨層行動至少能在出事時被追溯。沒有可追溯性，所謂自動化很容易變成沒有人真正負責。

主權被重畫，不等於國界已經失效

《The Stack》談主權時，最值得保留的細節是「重畫」而不是「消失」。國家仍然擁有法律、稅收、暴力與公共資源的制度能力；平台則在帳號、資料、排序、支付與 API 中形成另一種跨境治理效果。兩者可能衝突，也可能合作。真正的問題是，當一個人的工作、交易或表達同時受國家與平台規則支配時，他能否知道規則來源、申訴對象和可替代路徑。

這也解釋了為什麼平台停權會接近政治問題。若帳號只是娛樂工具，停權的影響也許有限；但若同一帳號同時是收入入口、客戶聯絡、作品檔案與社群身分，停權就會重新分配一個人的生活機會。平台不必被稱為國家，仍然需要面對接近公共制度的正當程序要求。

台灣如何在六層中看見自己的位置

台灣在 The Stack 中不是被動使用者，也不只是硬體供應商。它在 Earth 層面對能源、水與土地條件，在 Cloud 層面連接全球運算與製造網路，在 City 層面實驗數位公共服務，在 Address 層面處理身分與資料治理，在 Interface 層面設計政府與商業服務，而在 User 層面同時包含勞工、企業、居民、裝置與新一代 Agent。

這種多重位置要求政策討論避免單一指標。晶片出口成長不會自動代表平台主權增加，資料中心進駐也不會自動代表公共利益，AI 導入率更不會自動代表治理品質。需要一起看的，是供應鏈是否過度集中、能源成本是否可負擔、資料是否可攜、公共服務是否保留替代入口，以及受影響的人能否真正申訴。

對一般讀者而言，可以從一個具體服務開始畫自己的六層地圖：選一個每天使用的支付、叫車、購物或 AI 工具，寫下它依賴的硬體與能源、雲端供應者、城市場景、帳號識別、介面選項與實際使用者。當某一層完全無法被說明，通常就是權力或成本被隱藏的地方。

把六層架構轉成可執行的治理問題

1. Earth：服務的能源、水、設備與勞動成本是否被看見？有沒有環境與供應鏈責任？
2. Cloud：是否依賴單一供應者？資料能否匯出？中斷時有沒有替代方案？
3. City：城市資料由誰收集、誰能使用？居民能否更正與申訴？
4. Address：系統需要哪些身分？資料保留多久？錯誤標記能否被修正？
5. Interface：使用者能否理解、拒絕、撤回與回復？重要權利是否真的有操作入口？
6. User：人、組織、裝置與 Agent 的權限是否分開？誰能停止行動並承擔後果？

這六個問題可以用在產品評估、公共採購、AI 導入、城市建設與媒體報導。它們不會直接給出唯一答案，但會防止討論被單一介面或單一模型能力牽著走。對技術團隊而言，這是一份跨部門檢查表；對公民而言，這是一種把抽象平台權力翻譯成日常經驗的方法。

原創六層圖的閱讀方式

下方圖示把六層由 Earth 排到 User，右側用問題標記每一層的治理焦點。它不是 Benjamin Bratton 書中的官方插圖，也不是 MIT Press 的出版素材，而是 YOLO LAB 依據公開書籍介紹重新繪製的編輯分析圖。圖中的 AI Agent 只是用來示範跨層行動：它取得身分、呼叫工具並執行動作時，必須同時回頭檢查資料、平台、城市與物質成本。

讀者可以先從最上方的 User 往下追，問一次操作如何取得身分、透過什麼介面、落在哪個城市系統、使用哪個雲端，再回到 Earth 的硬體與能源；也可以從 Earth 往上追，問一項資源如何變成模型、服務、地址和人的選擇。上下兩種方向都比只看產品截圖更接近《The Stack》所提出的尺度轉換。

官方資料與延伸閱讀

• MIT Press：《The Stack: On Software and Sovereignty》官方書籍頁：核對作者、書名、出版資訊與六層架構。
• Penguin Random House：The Stack 書籍介紹：補充全球運算、平台與治理架構的出版社說明。
• MIT Press：The Stack 10 週年版本：補充六層架構與新序言的官方出版資訊。