hero

Nathan Sobo 把 Zed 的新版本控制系統 Delta 說成是 Xanadu 的轉世。他的論證很乾淨：Ted Nelson 1965 年許下的超文本願景之所以沒實現，不是因為想法錯，而是因為當時沒有足夠便宜的儲存、去中心命名、以及一個有耐心把每條連結都追完的讀者。現在這三個條件都到齊了，而最後一塊拼圖，是 agent。

原文摘要

Ted Nelson 在 1965 年創造了 hypertext 這個詞，並用 Project Xanadu 描繪一種他稱為 docuverse 的運算願景：所有資訊都互相連結（intertwingled），而且透過 xanalogical 的方式管理。所謂 xanalogical 有兩條規則：第一，永不複製，永遠引用（也就是 transclusion）；第二，保留每個版本的歷史。Nelson 相信，好的超文本應該讓讀者能追蹤每一條引用、比對每一個版本。

但這個願景需要兩樣當時不存在的东西：無限且未來不會過時的命名系統，以及便宜到可以永遠不刪的儲存。於是當 1990 年代網路爆炸時，開發者選擇了簡單：URL 是一串字元，目標搬了連結就斷，維護變成使用者的責任。Xanadu 從「下一個時代的承諾」變成「電腦史上最有名的 vaporware」。Nelson 一輩子都在說網路是 hypertext 的扁平諷刺畫，但他說對了也沒用，因為人類本來就不需要追蹤每條連結。我們只會跟著別人也在看的東西走。扁平，夠用了。

直到 agent 出現。

Sobo 認為，agent 那些讓人類覺得難合作的特質，恰恰讓它成為 Nelson 系統裡的完美公民。agent 可以同時追蹤比人腦能容納更多的層次：一段引用的來源、圍繞那段話的討論、以及附著在實際執行程式碼上的 stack trace。片段化的表示法讓這些引用不會遺失，每個層次都能隨著文字改變而繼續附著在同一段文字上。agent 可以同時讀取這些維度、引用它們讓人類稽核，而且每次都有耐心地追蹤每條連結。問題是，這些連結必須真的存在，agent 才追得到。

Sobo 回頭看，發現 Zed 的 DeltaDB 與 Delta 的設計目標，正好對上了 Nelson 的願景。人類注意力有限，所以過去幾十年我們一直把歷史壓扁成現在這個版本；但現在新的現實出現了，我們需要的是更 xanalogical 的東西。

幾年前 Sobo 寫過一篇文章，講他看 Engelbart 1968 年經典 demo 時的領悟：要打造協作編輯器，Engelbart 團隊必須先發明他們會依賴的一切，包括新的程式語言、作業系統、顯示器。Nelson 也面臨同樣困境，只是資金比 Engelbart 少很多。他無法打造 Xanadu，因為大部分元件根本不存在，例如沒有中央權威也能命名內容的方式，或者便宜到永遠不刪的儲存。他的團隊手工打造資料結構多年，但專案還是枯萎了。《Wired》把 Nelson 描繪成管理不善的悲劇，但 Sobo 認為他只是把 Xanadu 規格訂在它依賴樹出現之前的幾十年。

而現在，那棵依賴樹長出來了。Sobo 列舉 Delta 能夠存在所仰賴的各種基礎設施：沒有中心的時鐘（CRDT 協定）、不會說謊的名字（內容導向定址）、不需要協調就能收斂的資料結構、便宜到不刪的儲存、什麼都複製的網路、毫秒內啟動的運算單元、把文件當成永久內容的視圖。具體到 Zed 的技術堆疊，Tree-sitter（2018）快到可以隨打字即時重新解析，GPUI（Zed 自己開創）快到可以每幀都從應用狀態重新推導介面。Delta thread 也是同樣邏輯：它是永久結構化歷史的即時投影，是重新計算出來的，而不是被壓扁儲存的文件。

Sobo 也指出一個微妙的反轉：Nelson 一輩子被說夢想太大，但在最後一個依賴條件上，他其實夢得不夠大。他沒有想像出一種新的使用者：人工讀者。這種存在在科幻小說裡早就有了，例如 Asimov 的 Multivac 或 Stephenson 的 Librarian。Xanadu 被缺少的元件擋了幾十年，但它真正需要的，是完美的使用者。

這也解釋了為什麼 docuverse 正在從版本控制系統中浮現。絕大多數真正寫程式的過程，其實都發生在兩次 commit 之間。以前把中間脈絡壓扁沒那麼痛，因為我們靠人腦記憶湊合，反正也不會有人去讀每一個按鍵的變化紀錄。但 agent 不會把東西記在腦子裡，它們會讀所有東西。

每一條 Delta thread 都在實現這個承諾：對話與程式碼一起被收進共同的歷史裡。螢幕上的檔案看起來仍然是一維的字元串，但底層 DeltaDB 把它表示成帶有穩定身份的片段。這些身份讓我們可以創造 anchor：指向某段文字的參照，即使周圍的程式碼改了，anchor 仍然解析得到。行號只能表達某個 snapshot 中文字出現在哪，anchor 則能跨 snapshot 保存我們真正指的是哪一段。

Zed 正在探索 agent 如何在這個座標系統上運作。先前 agent 反覆讀取、編輯、引用或回頭查看的檔案與符號，可以變成下一個 agent 的地標——它們會根據程式碼現在的樣子解析，並連回那些理解是如何形成的對話。透過保存表面表示之下的因果 metadata，例如哪個操作產生了哪個片段、它建立在什麼先前狀態上，DeltaDB 讓模型不只可以遍歷當前程式碼，還可以遍歷它的來源、累積的注意力和先前的推理。

但 Sobo 也強調要避開 Xanadu 最後一個自取滅亡的陷阱：拒絕與次等格式互通。Xanadu 當年因為不肯跟外面的世界接軌而死。Zed 打算學這個教訓。DeltaDB 會跟你現有的 git repository 一起工作：每條 thread 同時也是一個 git branch，所以從來不開 Delta 的隊友看到的還是正常的 repo；也因為檔案是真的，它可以跟任何 agent 能用的工具無縫整合。你也可以繼續把 repo mirror 到 GitHub，跟還沒準備好切換的人一起工作——Zed 自己的開源 IDE 在這段過渡期就是這麼做的。

Sobo 最後說，Engelbart 和 Nelson 都是早期運算的先知，但我們從來沒有完整實現任何一方的願景。從 Engelbart 那裡我們拿走了滑鼠（最後還有多人編輯），從 Nelson 那裡我們拿走了 hypertext 這個詞，然後各自走上了自己的路。建造 Delta 與 DeltaDB 所需的每一個性質，Nelson 在 Sobo 出生前就已經規格化了。Sobo 的目標不是實現 Xanadu，但他能感受到 Nelson 等待願景落進人們手中時的那種焦躁。六十年對一個想法來說是很長的等待時間。它們的使用者，現在到了。

城武觀點

Nathan Sobo 這篇文章寫得很迷人，因為它把 Zed 的產品敘事接到了一條很長的知識史脈絡上。但「迷人」跟「成立」是兩件事。

第一個問題在「完美使用者」這個詞。Sobo 說 agent 是 Xanadu 的完美使用者，因為 agent 能追蹤每條連結、有耐心、不會累。但「能追蹤」不等於「會被允許追蹤」。Delta 的文檔與對話確實變成可遍歷的結構了，但這個結構存在誰的伺服器上？誰能決定哪些 thread 被保存、哪些被刪除、哪些能被匯出？Xanadu 的精神是去中心命名、永久引用，但如果那個「不會撞名、不會消失」的命名空間最後還是 Zed 在維護——或者某個單一實體在維護——那它只是一種新形態的中心化。我們不是擺脫了鎖定，只是把鎖定從 GitHub 換到 Delta 身上。

第二個問題是「兼容 git」真的等於「開放」嗎？Sobo 說每條 thread 同時是 git branch，沒開 Delta 的人看到的還是普通 repo。這聽起來很友善，但只解決了「人類協作者」的互操問題。Delta 真正的價值不在檔案層，而在那層超文本：anchor、片段身份、對話與程式碼的因果 metadata。這些東西並不存在於 git 裡。換句話說，git 拿到的是降維後的投影，真正讓 Delta 成為 Delta 的層，只有 Delta 能讀懂。如果 agent 的記憶、引用與推理越來越依賴這層超文本，那麼「檔案還是 plain text」並不能阻止平台鎖定——它只會讓鎖定看起來比較溫和。

這裡的結構是：Zed 越是成功說服大家 Delta 的 xanalogical 層很有價值，agent 就越會被訓練成離不開那層；而那層的解析權，只掌握在 Zed 手裡。Sobo 說他們要避免 Xanadu 拒絕互操的詛咒，但一個系統可以表面上開放，實質上卻因為語義層的獨占而變成新的壟斷。我認為 Delta 真正要回答的問題不是「你們會不會跟 git 共存」，而是「那層超文本規格有沒有獨立於 Zed 存在的路徑」。如果沒有，那麼 Xanadu 等了六十年的使用者，可能只是從一個花園換到另一個花園，差別只在這個花園的門面比較像開源。

城武的未解檔案——agent 確實會讀完每一條連結，但前提是那條連結沒有在半年後變成 404，也沒有在某個付費牆後面靜靜消失。