從 Blocklet Server 到 ARC：為什麼擁有比生成更難

AI 讓做軟體這件事變得很不一樣。過去，一個人想要自己的部落格、商店，或某個只為自己生活而設的小工具，首先想到的通常不是功能，而是要不要找開發者、怎麼買伺服器、以後誰來維護。現在，愈來愈多需求可以直接說給 Agent 聽。這裡的 Agent 指能理解需求、協助生成、運作或維護軟體的 AI 助手。軟體看起來一下子不再那麼遙遠。

但軟體能被生成，不等於它已經屬於你。

一個應用程式在示範環境裡跑起來，很容易讓人興奮。可一旦它開始承載你的資料、關係、歷史和日常工作，問題才剛剛開始：資料放在哪裡，誰能存取，換一台裝置怎麼辦，服務壞了以後能不能復原，想分享給朋友時，究竟是在分享一個連結，還是把自己重新綁回一個平台。真正麻煩的部分，過去一直藏在「部署」「維運」「帳戶系統」這些詞後面。說得直接一點，它們就是把軟體放到能長期存取的地方、讓它持續可用，以及管理誰能登入和使用。

這也是我們正在建構 ARC 的原因。ARC 是 Agentic Realm Computer。它不是再給 Agent 一台傳統電腦，讓它替使用者去管 Linux、安裝修補程式、看日誌。我們想做的是另一種計算基礎：使用者可以藉助 Agent 獲得需要的軟體，但身分、資料和長期控制權不必因此交給某個單一平台。

軟體能被生成，不等於它已經屬於你

ArcBlock 是一家從區塊鏈、去中心化身分和應用基礎設施一路走來的公司。過去一直在解決一個很實際的問題：開發和部署去中心化應用太難。Blocklet Server 和早期 Blocklet 所做的事，不只是把應用部署到一台機器上，而是把身分、使用者管理、網域和應用部署這些共通功能先做好，讓開發者把注意力留給自己的業務。

DID 體系、不同區塊鏈的介接與使用、支付支援，以及 PageKit、DiscussKit 這類元件，都是那套平台的重要部分。它們讓使用者或開發者可以在 Web 介面上處理身分、安裝和組合網站、討論或支付相關能力，而不必每一次都從零搭建一套服務。

這些能力在 ARC 裡都有相對應的基礎，但不會以同一種完成度或同一種模型出現。身分、既有帳本和支付層能力可以延續；鏈端 AFS 介接、鏈上結算，以及它們在 ARC 中的統一承載方式仍在建置。我們不該把它說成舊能力被歸零，再用一個純粹的未來概念取代；它們仍然是 ARC 能否有用的基線。

這個判斷在當時沒有錯。我們過去明確把自己看成開發者平台：只要有足夠多的開發者做出足夠多的應用和元件，一般使用者就能安裝、組合並使用它們。Blocklet Store 和一批 Kit 就是在這個判斷下出現的。今天也仍然有很多開發者需要這樣的工具。

後來我們不得不承認一個很實際的事實：即使元件已經有了，安裝、設定、維護這些事，仍把絕大多數一般使用者擋在外面。軟體套件不會自動變成一個人能長期擁有的應用程式。這也是 SaaS 能流行的原因，它把許多這類麻煩盡量替使用者藏起來了。

變化在於，AI 已經把「誰能做出軟體」這件事往外推了一大步。一個人不必先成為專業開發者，才有資格提出「我想要一個自己的網站」「我想收集和整理這些資料」「我想做一個只給家人用的小應用」。可就算 Agent 幫他寫出了應用，如果資料、部署和後續運作仍是一團只有專業人員才看得懂的東西，他得到的更像一次漂亮的示範，而不是自己的軟體。

有人會說，直接用託管式線上服務，也就是 SaaS，就好了。這個看法很合理。平台替你運作及維護應用，解決了立即可用、共同維運和許多人的日常便利，也會一直適合大量情境。ARC 不是要讓每個人重新學習當系統管理員，更不是要求每個人把所有服務搬回家裡。買一部手機時，沒有人會先問它是不是「自託管」，只會覺得它本來就是自己的。我們想改變的是另一件事：當一個應用真的成為你生活的一部分時，擁有它不該因為技術門檻而變得不可能。

ARC 不想再給 Agent 一台傳統電腦

傳統伺服器、虛擬機和隔離執行環境都可以讓 Agent 做事。但它們帶著傳統電腦的包袱：版本更新、存取權限、故障維護，以及一大堆彼此獨立的管理介面。讓 Agent 去操作它們，當然比讓一般使用者自己操作好一些，可複雜性只是換了一個人去背，並沒有消失。

ARC 從 AFS 開始。AFS 是 Agentic File System，它不是把傳統檔案系統換個名字，而是用「檔案系統」作為統一抽象，讓人和 Agent 都能理解和操作資料、可使用的服務與當前上下文。可以把它想成一個共用工作空間：只有在使用者明確授權、相關資料或服務已完成介接後，應用才能找到資料、理解權限並使用被允許的服務。一般使用者不需要看見這層抽象，但它決定了系統能不能把不同環境裡的東西放到一個可理解的表面上。

在 AFS 之上是 AOS，Agentic Operating System。兩者一起構成 ARC 的執行環境，也就是讓應用實際跑起來的底層環境。ARC 已在本地和雲端執行環境中驗證 Blocklet 的運作與資料介接；未來還會繼續向更多環境延伸。不同環境只是 ARC 的底層落點，不是使用者要自己管理的一台台機器。這裡真正重要的不是支援多少種平台，而是 Agent 面對的系統不再是一堆彼此陌生的盒子。

說白一點，我們不想把「幫使用者擁有軟體」理解成「替使用者管好一台伺服器」。使用者真正關心的是自己的東西還在不在、能不能繼續用、出了問題能不能復原。機器本身應該愈來愈像可替換的器具，而不是使用者必須親自伺候的對象。

重要的東西，不應該和一次執行綁在一起

這也是 ARC 和 ArcBlock 過去積累能夠接上的地方。

身分這一層是 DID，Decentralized Identifier。可以把它理解為一種可長期沿用、可被驗證的身分識別碼。ArcBlock 長期把身分看成系統的基礎，而不是某個平台臨時發給你的帳號。人和裝置等需要被識別的實體，都可以有自己的 DID。ARC 正在延續這套基礎，我們的目標是讓既有使用者不必因為架構升級重新建立身分。這種連續性很重要。換了一個系統，如果「你是誰」都得重新開始，所謂升級其實很可疑。

資料這一層是 DID Spaces。它不是一個讓使用者去維護的網路硬碟，而是個人資料應有的歸屬地。我們的設計目標是讓 ARC 的執行環境可被重建、應用可以被換掉，而真正長期重要的資料、歷史和授權關係擁有獨立的延續性。換掉應用或裝置後，筆記、授權和歷史不應跟著某次安裝一起消失。這樣說並不意味著資料從此不會遺失，也不意味著使用者再也不用備份。它意味著系統應該把可長期保存的資料和某一次特定的執行分開，讓同步、備份和復原有清楚的對象。

區塊鏈也沒有被放棄，只是不再被拿來當口號。它仍是 ARC 架構中可驗證記錄、資產相關情境，以及未來支付能力的延續基礎。對使用者而言，重要的不是先聽到「區塊鏈」，而是我們的目標是在需要驗證的情境中，減少對單一平台日誌的依賴。具體哪些行為可驗證，必須由已納入系統的身分與帳本能力決定。鏈端的 AFS 介接和鏈上結算仍在建置中，不能因為方向清楚，就假裝它們已經交付。

這幾層放在一起，才是我們所說的「擁有」。使用者擁有的不是某一台機器或一次部署，而是身分、資料、授權關係，以及在執行出現問題後繼續復原和遷移的可能。它不是一句「資料歸你」的廣告話術，而是一種架構上的分工：執行環境的可替換性是這套架構要實現的目標，身分要連續，資料要有歸屬，重要行為要有可驗證的記錄。至於每一項在不同產品裡會怎麼落地，還要由真實產品慢慢證明。

Blocklet 的變化，要在真實產品裡接受考驗

Blocklet 是 ArcBlock 很早就提出的名稱。舊 Blocklet 更像帶著完整執行環境一起安裝的軟體套件。它的價值一直很明確：把應用做成可以安裝、重複使用、組合的元件。

在 ARC 裡，這個想法沒有丟掉，但實作模型正在變化。ARC 時代的 Blocklet 正朝描述性的應用定義演進：應用說清自己需要什麼能力，ARC 提供通用的執行、身分、資料和互動基礎。過去常被打包在 Blocklet Server 或某個 Kit 裡的 DID、鏈、支付和網站、討論能力，在 ARC 裡仍要被承接，只是它們不再必然以原來的安裝模型出現。這裡常用「Blocklet 2.0」來指代這一代模型，但最終對外命名仍會隨產品而定。

這是一種有意的取捨，也有真實代價。舊模型裡，複雜應用可以帶著自己的完整執行環境；在這一代模型的方向中，應用描述不承載任意可執行程式，常用能力由 ARC 統一提供。少見的特殊需求，則需要由相應 Provider 單獨實作並明確掛載。技術讀者可以把這條邊界理解為 AFS Provider。也就是說，我們放棄了一部分「什麼都能塞進一個軟體套件裡」的自由度，換取更清楚的安全邊界，以及更少要由每個應用自己背的執行負擔。

介面也是同樣的思路。AUP，Agentic UI Protocol，讓介面的含義和關鍵操作可以被描述出來，而不只藏在某個特定前端實作裡。它不是「Agent 已經可以操作任何介面」的承諾，而是在為人、應用和 Agent 建立一層更清楚的共同語言。

技術讀者可以把這看成抽象邊界的重新劃分。一般使用者不必記住這些詞。我們希望使用者最終感受到：當資料、授權和應用能力具備遷移條件時，換裝置或執行環境不必讓應用突然變成另一個陌生的東西。

如果使用者必須先上完一堂 ARC 課，才能用一個應用，那我們大概把事情做反了。

這套架構最終要在真實應用裡接受檢驗，但不需要靠預先預告一批產品名稱來成立。使用者只會在意自己能不能建立一個網站、組織一場討論、管理身分、處理支付，或安全地保存自己的資料。ARC 應該在背後承擔身分、資料、執行和 Agent 協作的複雜性，而不是變成每個使用者都必須理解的品牌負擔。

恰恰因為舊平台已經做過這些具體能力，ARC 更不能拿一張漂亮的架構圖來取代它們。新的模型應該讓這些事情以更適合 Agent 與使用者協作的方式發生，而不是讓使用者重新面對安裝、設定和維運。

這也是為什麼我們不想只畫一張更複雜的架構圖。過去我們常用面向開發者的架構圖解釋這些元件，它們仍有價值；但未來的 ArcBlock 不應讓一般使用者因元件名稱而被拒於門外。ARC 是新的主線，Blocklet、DID 和 Blockchain 是沒有丟掉的根基。真正的測試不在圖上，而在使用者能不能自然地擁有自己需要的軟體。

這件事還沒有完成。ARC 也不會因為一篇文章就自動成立。我們接下來需要用產品、內容和公開的建設過程，把這套架構一層層證明出來。但我們想先把方向說清楚：AI 讓軟體更容易出現之後，下一步不該只是讓更多軟體被生成，而是讓更多人真的擁有它。

附：文中術語速覽

這不是 ArcBlock 的完整術語庫，只是為這篇文章準備的閱讀地圖。正式戰略與產品邊界還會繼續演進，因此表中的「正在建置」不是迴避，而是刻意區分已經可用的基礎和仍待驗證的部分。