把 Web3 和 AI 寫進同一張簡報很容易，真正難的是讓兩者在同一條鏈上協同工作。AI 需要吞吐量、低延遲和可編排的運算資源；Web3 需要可驗證、抗操縱與明確的權責邊界。兩邊的目標並不天然相容。本文不討論口號，而是把「去中心化 AI 堆疊」拆成幾層，說明執行層為什麼往往是最先卡住的那一層。
AI 側缺的不是模型，是可信的執行環境
主流大模型的訓練與推論仍高度集中在少數雲端廠商。問題不只是供應商鎖定，更在於：呼叫方很難獨立核驗「用了哪個模型版本、吃了哪些輸入、產出是否被竄改」。對普通的聊天應用，這或許可以接受；對要自動調倉、結算、觸發合約的 AI Agent 而言，黑箱就是系統性風險。
Web3 本應補上可驗證性，但多數公鏈的執行層仍按「人類使用者偶爾點一次交易」來設計。Agent 可能在短時間內發出大量相互依賴的交易：詢價、拆單、跨協議呼叫、事後對帳。若鏈上確認慢、衝突處理粗暴、費用波動大，Agent 要嘛退化成鏈下編排偶爾上鏈，要嘛在壅塞時失效。關於單執行緒 EVM 為何撐不住這類負載，可參見 《EVM 單執行緒瓶頸》。
堆疊視角：五層各管一件事
用堆疊而不是「全棧敘事」來看，去中心化 AI 大致需要五層能力，且層與層之間應解耦：
- 結算與合約執行層：決定狀態誰先誰後、衝突如何收斂。沒有足夠快且可預期的最終性，上層的 Agent 編排就沒有意義。
- 算力排程層：把訓練/推論任務分發給異構 GPU 或邊緣節點，記錄任務中繼資料與完成證明，而不是假裝「鏈上直接訓練千億參數模型」。
- 可驗證運算層：用零知識證明、TEE 或 MPC 等手段，讓「算過什麼」可被第三方抽查，細節見 《可信運算框架》。
- 資料與模型確權層：貢獻者、模型版本、收益分成需要可執行的規則，而不是白皮書承諾，見 《AI 資產確權》。
- 應用與 Agent 層：策略、風控、人機協同邏輯；應盡量把重運算放在鏈下或專用算力網路，把結算與關鍵狀態變更留在鏈上。
Bitroot 的敘事落點，主要在第 1 層（樂觀平行 EVM）以及與第 2、3 層的銜接：鏈負責排序與結算，算力網路負責重負載，可信運算負責抽查與隱私邊界。產品定位的完整說明見 《Bitroot 定位》。算力介面的邊界見 《分散式 GPU 與邊緣算力》；「AI 原生」能力清單見 《AI 原生區塊鏈》。
為什麼「執行層」特別關鍵
很多人把 AI × 鏈的瓶頸歸咎於「Gas 太貴」或「沒有原生 AI opcode」。更常見的失敗模式其實是：共識已經給出交易順序，執行卻跟不上，或者一遇到熱點合約就退化成近似串列。對 Agent 而言，這意味著：
- 延遲不可預期：同一策略在不同壅塞程度下行為漂移，難以做風控。
- 可組合性打折：多協議的原子操作更容易觸發衝突與重新執行，吞吐量被熱點拖垮，參見 《平行 EVM 工作負載熱點》。
- 驗證成本上升：節點若無法高效重放平行結果，去中心化驗證會變成紙上承諾。
因此，平行執行、共識與執行解耦，以及明確的衝突偵測，不是「為了刷 TPS」，而是給自動化實體一個可規劃的結算基板。機制地圖見 《平行 EVM 架構概覽》、《Pipeline BFT 與執行解耦》、《樂觀平行化機制》。
Bitroot 在測試網口徑下披露過單分片數千至數萬 TPS 量級、確認延遲約秒級乃至亞秒級的工程目標與測試結果；具體數字依賴硬體、負載與衝突率，不代表主網的穩定表現，也不構成任何收益承諾。讀指標的方式見 《效能指標術語表》。
該警惕的敘事陷阱
- 鏈上訓練神話：完整的預訓練幾乎必然發生在鏈下或專用網路；鏈更適合記錄任務、支付與驗證摘要。
- 把算力挖礦寫成理財：分散式 GPU 網路可以降低閒置率，但不等於穩定收益。
- 用相容性口號代替工程：真正的 EVM 相容要落實到位元組碼與工具鏈，見 《EVM 相容意味著什麼》。
- 用「融合」掩蓋信任缺口：缺口清單見 《Web3 與 AI 融合》。
落地時先建哪一層
若資源有限，建議的順序是：先讓結算延遲在自動化負載下可預期，再掛上任務/支付與最薄的驗收，然後按威脅模型引入 TEE 或 ZK，最後做複雜確權與市集。反過來先做模型商城而結算仍會抖動，只會放大爭議。去中心化與效能的張力見 《去中心化與效能的權衡》；讀者入口見 《誰該讀平行 EVM》。
層與層之間的失敗如何傳染
堆疊的價值在於解耦，失敗卻會沿著介面傳染。算力層的驗收含糊時，結算層只會忠實地執行錯誤的分帳；確權層缺失時，Agent 應用層只能把平台條款當成最終真相；執行層的衝突失控時，上層再完美的策略編排也會在費用與延遲上崩潰。因此「先畫五層」不是為了多寫幾個模組名稱，而是為了給每個介面規定：輸入是什麼、驗收是什麼、失敗時狀態停在哪裡。
對開發者而言，優先整合的順序建議是：先在平行 EVM 上把任務/支付狀態機跑穩，再接算力排程與證明，最後才做面向終端的 Agent 體驗。反過來從聊天機器人倒推上鏈，幾乎總會在確認延遲與不可驗證的輸出上返工。相容與工具鏈的約束見 《EVM 相容意味著什麼》。
評估清單：讀專案資料時看什麼
遇到「去中心化 AI」專案時，建議至少核對：結算層是否給出衝突率與重放成本，而不只是峰值 TPS；算力層是否描述驗收與挑戰，而不只是 GPU 數量；確權層是否有撤銷與分帳狀態機，而不只是鑄造圖片；可信運算是否寫明對手模型，而不只是名詞堆疊。
Bitroot 的相關材料應放在同一份清單下閱讀：平行 EVM 與 Pipeline BFT 負責結算基板，算力與可信運算負責鏈下重負載與抽查，確權負責規則執行。任何把四者合併成一句「AI 公鏈已就緒」的表述，都值得拆回清單逐項打勾。定位見 《Bitroot 定位》。
堆疊地圖的用處是減少範疇錯誤：不要用結算層解決訓練問題，不要用算力層解決最終性問題，不要用確權 NFT 解決驗收問題。分清範疇之後，Web3 與 AI 的協同才有可討論的介面。
與系列機制文的閱讀順序
若目標是理解結算基板，建議順序為：單執行緒瓶頸與擴容地圖 → 三條平行路線與 OCC 入門 → 本文的堆疊地圖 → 平行 EVM 架構概覽與定位。若目標是 AI 產品，則在堆疊地圖之後讀信任缺口、可信運算、算力網路與確權。兩條路徑都指向同一件事實：沒有可預期的執行層，上層敘事就無法穩定交付。
小結
去中心化 AI 堆疊能否成立，取決於能否把「智慧」放在可驗證的邊界內，同時把「結算」做得夠快、夠確定。執行層是這條鏈路上最先被 Agent 壓測的部分。後續文章分別展開平行架構、可信運算與確權；本文只建立分層地圖，避免把所有問題塞進一句「Web3 + AI」。