Xanadu 曾静候智能体到来
泰德·尼尔森今年一直萦绕在我的脑海。
尼尔森是计算机科学的先驱，1965年他在一个将定义其职业生涯的项目中创造了“超文本”一词：Xanadu 项目。借助 Xanadu，他对计算应该是什么样子有着特定的构想，称之为“文档宇宙”（docuverse）。他设想了一个能够保留文档所有版本、超文本链接同时知晓其来源和目的、引用通过引用而非复制来保存从而让每段包含文本保持其身份和来源的系统。在这一计算图景中，万物都是相互交织且“类-Xanadu式”的。我们谈论的是精确到 span 层的归属权问题。
所谓“类-Xanadu式”需遵循两条规则：永不复制，始终引用（即尼尔森提出的“包含式引用”，transclusion）；从不覆盖，始终版本化。按尼尔森的设计，Xanadu 系统将自行管理系统的复杂性和庞大的记账负担，因此用户仅能体验到这个永不遗忘的系统所带来的便利。
无限记账的愿景需要无限的存储和面向未来的命名方案作为现实基础，而在尼尔森钻研 Xanadu 的数十年来，这两者均不存在。因此当万维网技术在 90 年代爆发时，开发者为了便捷而绕过了 Xanadxal 式计算：链接只是简单的字符串，目标移动便会失效。维护责任落在了用户头上，而非系统本身——但任何人都能快速上线，他们也确实做到了。Xanadu 从新时代的希望沦为计算机史上最著名的虚构产品。
尼尔森花费整个职业生涯阐述：万维网只是超文本本应成为之物的扁平化仿制品。他是对的，但这并不重要，因为人们实际上并不需要追踪每一个链接或比较每一个版本。我们是一个 restless 的物种，更倾向于跟随别人正在追随的链接或阅读他人正在阅读的版本。扁平化就足够了。
然后，智能体降临了。
让智能体成为笨拙协作者的特性，也使其成为 Nelson 系统中理想的“公民”。智能体能同时处理的隐性上下文层数远超人类极限，比如引用的来源、围绕它的讨论，以及绑定到具体运行代码的堆栈跟踪。基于片段（fragment）的表示方式让这些引用无损保留，因此无论文本如何变化，每一层都保持与对应文本范围的关联。智能体可以同时读取这些维度，引用它们以便人类审计，并始终耐心追踪每一条链接。但这些链接必须真实存在于某处，智能体才能找到它们。
如今重读 Nelson 的愿景，我意识到 DeltaDB 的设计目标以及 Delta 的承诺。在长达数十年里，我们为了适应人类注意力局限而压缩历史信息，而现在我们已进入一个需要更……类模拟（xanalogical）系统来更好地服务的新现实。
如何在部件尚未存在时构建系统
几年前我写过关于 观看 Engelbart 1968 年的演示 的文章，当时我意识到，要构建一个协作编辑器，他的团队必须发明它将依赖的一切：一门新的编程语言、操作系统和显示设备。
Nelson 面临着同样的问题（但获得的资金远少于 Engelbart）。他无法构建 Xanadu，因为它的多数部件尚不存在，例如一种不由任何权威机构颁发的内容命名方式，或便宜到永远不会被删除的存储。他的团队多年来手工打造自己的数据结构，但项目最终夭折。Wired 将 Nelson 的故事描述为管理不善，但我认为他只是几十年前提前制定了 Xanadu 的规格，而当时的依赖树并不存在。
依赖树如今已存在
我们今天能够构建 Delta，是因为六十年来其他人的路线图交付了 docuverse 缺失的拼图：内核开发、照片存储、无服务器冷启动、协作光标。我认为有趣的是，这些突破都来自平凡的日常工作，却将支撑下一个计算时代。
一个没有中心的世界的时钟。 Lamport 时间戳，1978 年。每个由人类或智能体执行的操作都由参与者加一个 Lamport 时间戳命名，且永远如此。
无法说谎的名字。 Merkle 树诞生于 1979 年，2005 年因 Git 而变得普及。Git commit hash 命名了一个确切且不可变的工程状态；DeltaDB 则根据每个 commit 以及在其之上应用的 actor 和时间戳 delta ID 集合，为 commit 之间的每一种状态命名。
无需协调的收敛。 CRDT（无冲突复制数据类型）于 2011 年被形式化，也是 Zed 过去十年研究的核心。Delta worktree 可同时被分布在不同大洲的多个用户和 Agent 编辑。
廉价到舍不得删除的存储。 1981 年，一吉字节的成本高达数万美金；如今仅需一美分。我们默认保留一切的每一个版本。
复制万物的网络。 2000 年代中期，始终在线且高速的宽带取代了拨号上网。每个线程都是实时且分布式的，副本存在于每位参与者的机器和浏览器中。
毫秒级启动的机器。 Firecracker 类微虚拟机，2018 年问世。Delta 中的 Agent 可以在对话中途预配一台全新的隔离云主机。
文档是永久内容的视图。 Max Brunsfeld 的 Tree-sitter（2018 年）快到你可以在输入的同时实时重新解析。GPUI（由 Zed 开创）快到你可以在每一帧渲染时从应用状态推导出全新的界面。Delta 线程是其永久结构化历史的实时投影，通过重新计算而非存储为扁平化文本来生成。
关于一个细节——在职业生涯中多次被告知梦想太大——Nelson 的梦想其实还不够大。他缺失的最后一种依赖是一种全新的用户：他未曾想象过“人工智能读者”，尽管科幻小说中早已存在这类概念（如阿西莫夫的 Multivac，或斯蒂芬森的图书馆员）。
虽然 Xanadu 因缺乏关键组件而被阻塞了数十年，但它真正需要的其实是完美的用户。
为何文档宇宙正在版本控制中具象化
实际上，大部分代码编写一直都发生在 两次提交之间，但过去我们可以通过压缩上下文来减少伤害，因为靠的是人类记忆（而且反正也没人会去阅读完整的键盘输入记录）。但智能体不依靠记忆，它们会阅读所有内容，因此我们需要一种方式，按照纳尔逊的规范——永久性与连接性——来捕获新的数据源。
每个 Delta 线程都兑现了这一承诺。对话和代码被共同记录在共享的历史中。在屏幕上，文件看起来仍然是一维的字符流，但在底层，DeltaDB 将其表示为具有稳定标识符的代码片段。这些标识符使我们能够创建锚点：即使周围的代码发生变化，仍可解析的对特定范围的引用。行号只能表达文本在某一快照中的位置，而锚点则能在不同快照间保持我们所指范围的一致性。
我们一直在探索智能体如何基于这套坐标系统进行操作。早期智能体反复读取、编辑、引用或回访的文件和符号，可以成为下一个智能体的路标，针对当前代码进行解析，并与形成该认知的对话建立链接。通过保留表面表示之下的因果元数据——例如每个片段是如何生成的、依赖于哪些先前状态——DeltaDB 赋予模型一种不仅能浏览当前代码，还能追溯其来源、累积关注点和过往推理的能力。
避免赞丹式的诅咒
赞丹存在一种最终的故障模式，而且是由其自身造成的：它拒绝与低级格式互操作。在向世人介绍 DeltaDB 时，我们正从这一错误中吸取教训。我们将与你现有的 git 仓库协同工作。每个线程同时也是一个 git 分支，因此从未打开 Delta 的队友看到的只是一个普通的仓库；而且由于文件是真实的，它能与智能体可用的任何工具无缝集成。你可以继续将仓库镜像到 GitHub，以便与那些尚未准备好切换的人合作（这也是我们开源 IDE Zed 在此过渡期间的做法）。
恩格尔巴特与尼尔森是早期计算机时代的先知，然而我们从未完整实现其中任何一人的愿景：我们从前者那里继承了鼠标（以及最终的多用户协作编辑），从后者那里借用了“超文本”一词。两个理念都得以延续，却都未达其创造者所设想之深度。我们至今仍将“实时会话”与“持久记录”割裂开来：讨论过程、中间状态与创作意图被压缩扁平为一份最终文件或一次提交，而依赖路径与行号的链接则随着代码的流转逐渐失效。我期待 Delta threads 能同时实现这两种愿景：让实时会话沉淀为永久的、相互关联的文献——因为会话与记录本就是同一个对象。
构建 Delta 与 DeltaDB 所需的一切属性，早在奈尔森出生前便已被他阐明。尽管我的目标并非复现 Xanadu，但我仍感同身受地体会着奈尔森当年那份焦灼——那种期盼已久的愿景终于落入众人之手的心情。一个想法等待用户，六十年可谓漫长。而他们，此刻已在。