一切都在演进，什么留了下来？

如果你问我，最初为什么喜欢计算机，我的答案只有三个字：玩游戏。

1987 年，我接触 Apple II。那时坐在它前面，大部分时间其实都在打游戏。没有机会用彩色显示器，眼前就是一片黑底上的绿色。而最让我着迷的游戏之一，就是 Lode Runner。

Apple II 版 Lode Runner 启动画面。来源：JYManet，保留原图的绿色单色效果；不是我的个人截图。游戏画面版权归原权利人。

对当时的我来说，计算机首先就是能让我玩到这个游戏的东西。主机、键盘、显示器都摆在面前；手指按下一个键，屏幕里的小人就动起来。“计算机”和“界面”几乎是同一回事：我坐在这里，机器也在这里，那个可以进入的小世界就在屏幕里。

后来我才发现，眼前这个屏幕，和真正为我工作的那台计算机，可以隔得很远。再后来，连“界面应该是什么样子”，也一次次被推翻。

今天准备 AFS-UI 的演讲时，我又想起这些经历。我会在开头告诉听众一件事：你现在看到的这套胶片，就是运行在 AFS 上、由 AFS-UI 呈现的一个应用。AI agent 也参与了它的制作。 它看起来像普通的网页幻灯片，为什么值得专门说出来？先把这个问题留下来。

我想讲的，是这些年界面不断变化以后，我们究竟应该保留什么。

一台计算机，和进入它的地方

Apple II 参考照片，并非我的个人设备。Rama 与 Musée Bolo，Wikimedia Commons，CC BY-SA 2.0 FR。

Lode Runner 的画面并不复杂。小人穿过梯子和平台，收集金子，躲开追赶者。地板可以挖开，暂时困住敌人，随后又会恢复。画面上的每一块砖、每一道梯子，都有明确的用途。你按下一个键，那个小世界就发生一点变化。

Lode Runner 关卡画面，作者提供的网络图片，未经重绘或改色；游戏画面版权归原权利人。

旁栏 · Lode Runner 不只有闯关

Doug Smith 创作的 Lode Runner 于 1983 年由 Broderbund 发行。原版提供 150 个关卡，还附带关卡编辑器，让玩家设计、测试和保存自己的关卡。今天看起来熟悉的“玩家也能造世界”，当时已经装在这个小小的游戏里。可以翻看原版手册，看看它怎样向玩家解释这些能力。

到了 1990 年前后，我第一次接触终端。背后的主机是一套基于 Motorola 68000、运行 Unix 的系统，还用着巨大的八英寸软盘。

具体型号我已经记不清了。印象中，那是一台小型机，可以连接几十个终端。每个人面前都有自己的键盘和屏幕，真正运行程序的却是同一台主机。

这和 Apple II 给我的感觉很不一样。我的手还在键盘上，回应也仍然出现在眼前的屏幕上，但计算机并不在这里。终端提供输入和输出，另一处的主机负责计算。原来，好多人可以各自拥有一个界面，共同使用一台计算机。

DEC VT220 参考照片，用来说明终端的形态，并非我当时所用设备的型号。Tom Page，Wikimedia Commons，CC BY-SA 2.0。

旁栏 · 终端不是一台较弱的 PC

这里说的终端，主要承担键盘输入和屏幕输出。应用程序在相连的主机上运行。今天在电脑里打开的“终端模拟器”，继承了这类交互方式，却不等于当年桌上那台专门的终端设备。

随后是 PC、DOS 和 Windows。计算和界面好像又回到了同一个盒子里。我在这个世界里写程序，也经历了从字符界面到窗口界面的变化。窗口、菜单、按钮让事情变得直观，但这时我已经知道：它们和计算机之间的关系，并非天生如此。

博物馆中的 Windows 3.1 设备。Jason Scott，Wikimedia Commons，CC BY 2.0。

旁栏 · Windows 3.1

微软在 1992 年发布 Windows 3.1。它属于仍与 DOS 密切相连的 Windows 世代，和今天的 Windows 架构不同。这里的照片用于还原那个时期 PC 窗口界面的观感。微软的历史记录介绍了这次发布。

窗口可以在这里，程序可以在那里

真正让我再次受到冲击的是 Unix 和 X Window。

在大学里接触 Unix，后来使用 Sun 工作站，我逐渐熟悉了远程登录和远程管理。但 X Window 带来的感觉还是很不一样：一个程序可以在一台机器上运行，把它的窗口显示在另一台机器上。

这意味着，我面前的屏幕不是程序唯一能去的地方。显示器、键盘和鼠标，可以作为另一端的显示与输入服务。计算在哪里发生，和我在哪里看见它，变成了两个可以分别安排的问题。

这是 Huihermit 在 Debian 上制作的 Motif/MWM 参考截图，不是我当年 Sun 工作站的原始画面。Wikimedia Commons，CC0。

旁栏 · X Window 的“服务器”在哪一边？

X 的一个有趣之处，是负责显示和输入的这一端叫 X server，应用程序反而是 client。窗口管理器又是可以单独选择的部分，因此同一套底层机制能呈现不同的桌面风格。这种分工比某一种窗口外观更重要。X.Org 的概念说明解释了它们各自的职责。

后来我为 SGI 的 IRIX 系统开发过一个 Video CD 播放器，也在工作中使用过 IBM AIX。这些 Unix 系统外观不同，窗口管理器也不同。对我来说，那种可以更换界面呈现、又不必把整个系统一起推倒的能力，很有吸引力。

AFS-UI 里的 Display、Device 和 Window Manager，并不是凭空想到的名词。它们背后有这段经验：界面是一种连接计算的方式，显示方式应该可以独立变化。 我们借鉴的是这种分工，并不是要把 X 的协议原样搬进今天的系统。

互联网给我的第一次震撼：在中国访问白宫

1994 年，我第一次接触互联网时，用过字符终端里的 Gopher。我最早访问的站点之一就是白宫。

让我震撼的不是画面。那还是文字和菜单。我坐在中国，输入一个选择，远方的系统就把文件送回来。当时我觉得，是一台放在白宫的计算机在回应我。它实际部署在哪里，我并不知道；但输入发生在我这里，反馈却来自大洋彼岸，这件事突然变得非常具体。

根据 RFC 1580 示例重建的终端菜单，用来说明交互形式；不是我当年访问白宫的截图。

旁栏 · Gopher 是什么？

Gopher 用层层菜单组织互联网上的文件和服务。你进入目录、选择条目，再取回内容。它有自己的协议，不等同于 Telnet；当时也可以通过远程登录一个提供 Gopher 客户端的系统来使用它。RFC 1436记录了这个协议。

同一年，我也接触了 Mosaic。互联网从字符菜单变成了可以看见图片、点击链接的页面。后来，我们经历了动态网页、Ajax，以及越来越复杂的浏览器应用。今天，AI 又开始根据任务生成可交互的界面。

旁栏 · Mosaic 并不是第一个浏览器

NCSA 在 1993 年推出 Mosaic。它在图形化 Web 的普及中扮演了重要角色，但 Web 和浏览器在它之前已经存在。这里的 1994 年，是我接触它的时间。NCSA 保存的项目历史值得一读。如果想沿着图片继续走，可以打开我们的界面发展时间线。

这些经历对我有一个共同的影响：每当我以为自己已经知道界面是什么，下一种系统就会让我重新想一遍。

第一次回到问题：什么变了，什么留了下来？

变化很明显。机器换了，操作系统换了，画面从字符变成窗口，又变成网页。程序运行的位置，可以在桌面、机房，也可以在网络另一端。

留下来的是什么？

从人的一端看，键盘和显示器这样的输入输出方式，延续了很久。从系统的一端看，还有一个更不起眼的东西：文件。

我当年 Apple II 的软盘，至今还留在书架上。今天要读取它，需要处理介质、驱动器和格式兼容的问题。但当我们把数据恢复出来，它仍然可以作为文件被找到、保存和搬走。原来的机器早已退出日常生活，文件这个抽象却还在。

这并不意味着文件系统不会变化。恰恰相反，它的实现变了很多次。能留下来的是一些简单、可理解的约定：内容有名字，有位置，可以被读取，也可以在允许的时候被修改。

Unix 把这个想法推进了一步。

“Everything is a file”并不是说世界上的东西都真的变成了磁盘文件。它让许多不同资源能够通过相近的输入输出方式被操作。终端、设备、标准输入和标准输出，都进入了这个思路。

旁栏 · “一切皆文件”的边界

Unix 用特殊文件连接设备与文件式 I/O；网络套接字也可使用文件描述符，但并不意味着每个网络连接都对应一个可浏览的普通路径。这个原则的价值，在于统一访问方式，而不是抹掉资源的差别。可以读 Dennis Ritchie 保存的Unix 手册导言。

前面那些故事，到这里连起来了：我看到的终端、用来输入的设备、承载输出的地方，都可以成为系统能够操作的资源。

从文件，到 agent 可以工作的上下文

我们设计 AFS，Agentic File System，很大程度上受到这个思路启发。

AI agent 面对的环境非常杂。这里有文件，那里有数据库，还有服务、工具、任务和运行中的状态。它需要知道有什么、在哪里、能做什么，以及做完以后发生了什么。

AFS 为这些资源提供一个类似文件系统的访问空间。不同资源通过 provider 接进来。Provider 负责把背后的系统接到 AFS 的路径与操作约定上，资源本身不必变成磁盘上的文件。

我更愿意把它理解为一个可以探索和操作的工作环境。路径告诉 agent 去哪里，资源的结构和说明帮助它理解那里有什么，支持的操作与权限决定它能做什么。

从 Unix 的 “Everything is a file”，我们走到了 “Everything is context”。这里的 context，不只是塞进模型输入的一段文字，也包括 agent 正在使用、可以重新访问的外部资源。AFS 的介绍和上下文与认知的区别分别展开了这两个方面。

那么，已有 tool calling、MCP 和 skills，为什么还需要 AFS？

因为它们回答的问题并不完全相同。工具让 agent 执行某件事，MCP 可以把工具和资源暴露给它，skills 可以告诉它怎样组织工作。而工作环境里仍然需要一个办法，把不同来源的资源放在一起，让 agent 能继续找到、查看和操作它们。

这些机制可以配合使用。AFS 不要求把工具协议或工作方法全部替换掉。它试图稳定的是 agent 接触工作环境的那一层。稳定也不代表路径永久有效：会话会结束，资源会移动，权限会改变。系统仍然必须明确表达这些边界。

第二次回到问题：资源不断增加，什么应该稳定？

模型会换，工具会换，后面的服务也会换。我们希望保留的，是找到资源、理解资源、在授权范围内操作资源的明确方式。

这个想法用在上下文上很自然。但做着做着，一个缺口变得明显：界面在哪里？

假如 agent 已经可以直接访问许多资源，最后却要对着屏幕猜一个按钮是什么、应该点哪里，我们其实又把它带回了另一套环境。

Computer Use 和 Browser Use 正在解决这个问题，而且很有价值。它们让 agent 有机会操作原本没有为 agent 设计的软件。访问方式也不只有截图，还可以包括 DOM、可访问性树和其他结构化入口。

但真正让 agent 做过这类工作，就会遇到辨认、等待和确认的成本。一个弹窗、一处布局变化、一个尚未加载完成的页面，都可能要求它重新判断。视觉理解没有因此变得多余；只是当应用由我们自己设计时，是否还应该让 agent 先从外观反推我们已经知道的结构？

我觉得，Generative UI 至少有两个值得分别回答的问题：

AI 怎样把一个界面呈现给人？

AI 怎样通过这个界面参与工作？

在《界面会变，工作应该留下》里，我从 OpenAI 的交互界面探索谈起，也讨论了 A2UI、MCP Apps 等不同方向。它们不能简单地被归成一种技术：有的关注界面描述，有的关注应用嵌入与宿主之间的交互，有的关注 agent 与前端的通信。

这里我想再往前问一步。一个生成出来的界面，如果人可以理解和操作，agent 是否也能沿着明确的结构，回到同一件工作上？

AFS-UI：让画面和路径指向同一个系统

这就是 AFS-UI 的出发点。

人看到画面，agent 访问路径。人通过点击、输入和触摸操作；agent 可以读取接入 AFS 的界面节点、相关状态和支持的操作。两者使用不同入口，但应当能够指向同一个对象。

比如一张任务卡。人看到标题、状态和操作按钮。对 agent 来说，它不必先识别卡片的颜色、推算按钮坐标，才能知道这个对象是什么。界面系统已经把相应结构暴露出来，它可以沿路径找到它，再按系统支持的操作行事。

路径本身并不会解决一切。业务规则仍要实现，权限仍要检查，结果仍要验证。复杂图像的含义，也不会因为有一个路径就自动变成结构化数据。AFS-UI 的价值，是让已知的界面结构不必在每次操作时重新从像素里猜一遍。

旁栏 · 协议与设备各做什么？

AUP，Agentic UI Protocol，描述界面的结构、属性、绑定和事件等约定。可以把它看作界面系统用来表达“这里有什么，以及它怎样参与交互”的语言。

Web Device 则把 Web 作为一种具体的呈现环境，提供网站所需要的页面组织、路由、组件与渲染等能力。协议和具体设备承担不同职责。具体的实时会话，则承载某次运行中的界面状态。

如果想进一步看这几个部分怎样配合，我们另外写了Introducing AFS-UI。这篇故事里，我最希望留下的，是那个简单的对应关系：同一个界面系统，人可以看见它，agent 可以直接访问它。

现在，可以回到文章开头留下的问题了。

这套演讲胶片本身就是一个应用。演讲走到这里，我会把 Explorer 打开，让听众看看承载胶片的发布包：Markdown 内容在哪里，AUP 定义在哪里。它不是事后画的一张示意图，浏览的就是这套胶片自己的材料。

需要分清的是，这个 Explorer 展示的是应用发布包的内容与定义，并不等于把全部运行中的 UI 对象树展示了出来。它让人先看到一个实在的入口，再去理解背后的体系。

这个网站、配套的文章和 Learning 内容，也是通过我们自己的系统构建与呈现的。读者不必先接受一套理论，才有机会看看它能做什么。

显示设备，还可以是什么？

X Window 曾经让我明白，计算和显示不必在一起。AFS-UI 让我继续追问：显示与交互，是否也不必只有一种形态？

我们已经有终端与浏览器 UI 的实现，也有承载网站的 Web Device。再往前想，智能音箱可以是一个 Device：它听语音，也用声音回应。眼镜可能只有很小的显示区域。VR 可以把整个空间变成界面。游戏里的角色、物件和动作，也可能成为一个 RPG Device 的交互语言。

概念插画，复用自 Introducing AFS-UI。上方对应已有的终端与 Web 实现方向；下方是未来设备设想。图中的具体界面是示意，不是产品运行截图，也不表示同一界面已经能够自动转换到所有设备。

这些后面的例子是我们讨论中的方向，还不是已经交付的通用能力。一套复杂的网页也不会自动、完整地搬到音箱里。没有屏幕，就必须重新安排信息；没有键盘，就需要不同的输入方式。有的能力可以保留，有的需要简化，有的根本不适合在那个设备上提供。

但如果对象和操作有共同基础，设备就可以围绕自己的能力决定怎样表达它们。人仍然应该能理解自己在做什么，agent 也仍然应该能找到相关对象。

讲到游戏，我发现故事又回到了开头。

旁栏 · Lode 这个名字，一直跟着我

Lode Runner 对我的影响，后来甚至留在了公司的名字里。我创立的第一家公司叫 LodeSoft，就是因为我喜欢这个游戏。ArcBlock 最初把核心称为 Lightweight Objects Decentralization Engine，缩写 LODE，也有同样的来由。这段早期命名记录在ArcBlock 架构演进回顾里；后来写《ArcBlock：从蓝图到现实》时，我又回到了这条从设想到实现的线索。

还有一个很巧的插曲。在 ArcBlock 成立之前，我为当时的公司在 Bellevue 租办公室，后来才发现，Lode Runner 版权拥有者的公司就在附近，和我们在同一条路上。小时候屏幕里的游戏，突然和现实中的一条路接上了。

根据Tozai 保存的历史，Doug Smith 在西雅图、还是华盛顿大学学生时，开始了这个游戏的创作。他后来已离世。他做出的游戏，确实在很长时间里影响着我。

第三次回到问题：界面继续演进，什么应该留下？

从绿色屏幕里的游戏，到今天的生成式界面，变化远远没有结束。新的模型会生成新的画面，新的设备会改变输入输出的方式。

我希望留下的，是我们正在操作的对象，是它们可以被理解的状态，是明确的操作与权限，也是人和 agent 能够共同进入的工作环境。

AFS 为上下文提供访问方式，AFS-UI 把界面也接进来。但软件的全部生命周期，显然比界面更大。需求怎样变成工作，工作怎样接受验证，出了问题谁能理解并接管，这些还需要进一步回答。

这也是我们继续探索DarcFactory，黑灯工厂的原因。AFS、AFS-UI，再加上组织和验证 agent 工作的软件工厂，才逐渐接近那个更大的愿景。自主执行需要验证与监督作为前提，不能因为界面已经可以被 agent 操作，就认定整个生产过程已经可靠。

但如果我们把黑灯工厂这个设想继续往前推呢？

假如有一天，从实现、测试到交付，软件开发中的日常工作都能够自主完成，人不再需要直接操作这些过程，那么 User Interface，用户界面，还会是什么？

我们还需要看着软件怎样工作吗？还是只在表达意图、作出判断，或者决定让它停下来的时候，才与它相遇？当没有人需要坐在开发工具前，界面又应该出现在哪里？

也许不是屏幕。也许不是键盘。甚至不是我们今天所设想的语音输入。

它会是什么？我不知道。我们都还不知道。

我从 Apple II 上的 Lode Runner 开始认识计算机。那时候，我以为计算机就是眼前那个盒子，界面就是里面发着绿光的世界。后来，终端、X Window 和互联网，一次次让我发现：原来它还可以是别的样子。

今天，我不想替下一代界面提前画出最后的形状。AFS 和 AFS-UI，是我们为这种变化所做的一次具体尝试：让画面可以变，让人和 agent 仍然能够找到对象、理解状态、参与同一件工作。

而当软件已经可以在黑暗中继续运转，我们需要留给人的，也许不再是一块始终亮着的屏幕，而是理解它、决定它该做什么，以及在必要时改变它的能力。

一切都在演进。连界面本身，也可能不再是我们认识的界面。

到那时，什么应该留下来？