界面会变，工作应该留下

看到 ChatGPT 的回答里出现一个可以直接操作的界面，很多人会先想到：以后是不是不用自己写 UI 了？

我想到的是另一件事。这个界面如果明天换了一个样子，人和 agent 还能不能接着做今天这件事？

这两个问题都值得问。前一个决定了软件能多快出现，后一个决定了它出现以后，能不能成为我们真正使用的系统。

2026 年 10 月 7 日，OpenAI 在 GPT-6 的发布中介绍了 ChatGPT 的 Intelligent UI：回答可以采用可交互的组件，界面能够随生成过程逐步呈现。官方描述的实现包括可流式输出的组件库，以及处理生成中界面的编译器。模型还要判断什么时候值得使用界面，什么时候一段文字就够了。发布说明宣布了这项能力在 ChatGPT 中逐步上线，并不是一份可直接拿来实现另一个兼容客户端的协议规范。

这个区别很重要。不过，我不想用它来削弱这次发布。恰恰相反，好的判断可能比多画几个组件更难。用户问一个问题，系统能够判断该给一段话、一张能调整的图，还是一个可以操作的东西，这才是 Generative UI 真正有意思的地方。

我正在准备的一场 AFS-UI 演讲，也绕不开这个变化。但我会在开场很早就揭露一件事：观众正在看的胶片，本身就是 AFS-UI 应用；承载相关学习材料的站点，也使用这套系统构建。

这时候，观众很可能会想：看着不就是网页和幻灯片吗？

这个反应正好。我们要解释的东西，并不一定长在截图里。

回答有了界面，然后呢？

设想你和 AI 一起安排一次旅行。它生成了一个行程界面，你拖动日期，删掉一个不合适的酒店，又保留了一个待确认的安排。过一会儿，你让它换一种更适合手机的布局。

你当然不希望已经确认的行程跟着布局一起重新生成。你也不希望下一位接手的 agent 必须从屏幕里重新猜测：哪个项目已经决定，哪个只是建议，这个按钮究竟会改变什么。

这个旅行场景让问题具体了一点：生成一个界面，和让一件工作穿过多次界面变化继续存在，是不同的工程任务。

不能简单地说，今天的交互回答都没有状态。OpenAI 的帮助文档明确提到，一些组件的状态可以在同一聊天刷新后保留，但不会跨聊天线程延续。这已经是状态管理。我们真正需要继续追问的是：状态属于什么对象？它在哪个范围内有效？谁可以改变它？换一个呈现方式以后，操作指向的还是不是同一个对象？

这些问题不只属于 OpenAI。过去的软件也要回答它们，只是 Generative UI 把变化的速度提高了。原来可能几个月改一次的界面，现在可能在一次对话里改好几次。依靠开发者记住“这个按钮大概对应那个接口”的办法，开始变得吃力。

行业里已经出现了不同方向的回答，而且它们并不是一张谁替代谁的排行榜。

MCP Apps让工具能够向支持它的宿主提供交互界面。工具声明 UI 资源，宿主在隔离环境中呈现它，界面与宿主之间可以交换消息、调用工具和传递上下文。它解决的是一个很实际的问题：工具提供者怎样把可交互体验带进用户正在使用的 AI 应用里。

MCP-UI则需要放在这条演进线上理解。项目现在提供 MCP Apps 的实现工具，同时保留实验和兼容工作。把 MCP-UI 和 MCP Apps 写成两个互不相干的竞争标准，反而会让人读糊涂。

A2UI选择了另一条边界：发送声明式的界面描述，由客户端用认可的组件来呈现。它包含数据绑定和交互回传，不只是生成一批静态卡片。这给客户端留下了决定具体外观和组件实现的空间。

这些方案可以组合。A2UI 的文档本身就讨论了与 MCP Apps 的配合。OpenAI 这次公开的 Intelligent UI 产品说明，也不足以让我们断言它内部用了、或者没有用某一种同类协议。把尚未公开的实现猜成事实，没有必要。

我更愿意用“各自先稳定哪一条边界”来理解它们：

一个系统完全可以跨越这张表的几行。AFS-UI 值得讨论的地方，是我们把注意力放到了界面背后的那一层。

我从旧系统里带走的东西

我从 Apple II 开始接触计算机。后来写 DOS 程序，接触字符界面的窗口、Windows 开发，又在 Unix 工作站上使用 X Window。再后来是浏览器、动态网页、Ajax，以及 React 这样的前端工具。

如果把这段经历讲成“我用过多少古董”，对今天的听众大概没有多大意义。没有使用过绿色字符终端的人，为什么要对我的怀旧产生共鸣？

但有些当年让我吃惊的问题，今天仍然很好理解。比如：程序一定要运行在显示它的那台机器上吗？一个程序的工作，能不能换一个地方看？窗口的外观为什么必须由应用自己决定？

X Window 给我留下的印象，正是这些边界可以拆开。运行应用的地方和接收显示、输入的地方，可以在网络的不同位置；窗口管理器又可以参与决定窗口如何摆放和装饰。用今天的话说，你可以把显示端看成系统连接的一种设备，而不是把每个应用都想成一块封死在本机屏幕里的东西。X 的体系说明保留了这套客户端、显示服务和窗口管理器的分工。

TWM 截图，DoWhile，2006，公有领域。原图与说明。它展示了显示与窗口管理可以成为独立职责的历史背景。

Unix 和 Plan 9 给我的另一个启发，是命名空间。不同东西背后的实现可以很不一样，使用者却能通过一致的路径去找到它们。Plan 9 把这种思路推进到了分布式环境中的资源组织。原始论文值得读，尤其是当我们今天又开始为 agent 设计工具、资源和上下文的时候。

文件系统当然没有几十年完全不变。文件路径也不是世界上所有数据最合适的表达方式。但“给对象一个可找到的名字，再把名字背后的实现分开”这个抽象，的确经受住了很长时间的技术变化。

打开交互式界面历史时间线。可以沿年代浏览照片和旁支故事，不必在本文里读完一整部界面史。

这就是我演讲标题里 What Endures When Everything Evolves? 的意思。要留下来的，未必是某一代窗口的样子，更不是某个前端框架。而是一些把变化隔开的约定。

AFS-UI 从 X Window 借鉴显示与计算分离的思路，从文件系统借鉴统一寻址。但它面对了一个新的条件：使用界面的不只有人，还有 agent。

人看到一个按钮、一个状态、一段正在进行的工作。Agent 应该也能通过明确的结构找到它们，理解有哪些操作，而不必每次都把屏幕重新猜一遍。视觉理解仍然有价值，已有网页也可以通过 DOM、可访问性树或者 API 被操作。我们是在问，能不能从系统设计一开始，就让人和 agent 都拥有合适的入口。

沿着一个地址，看看实际发生了什么

先把几个缩写放一边。看一个我们为演讲准备的实际实验。

屏幕上有一小块界面，其中一行状态文字是 “Preparing the keynote”。在运行中的 Web Device 会话里，这个文字节点可以读出来。把当前会话的路径简称为 S，它的地址就是：

S = /dev/ui/web/sessions/<当前会话>
S/tree/demo-status

读到的结构包含节点的 id、类型以及内容。省略样式字段后，它大致是这样：

{
  "id": "demo-status",
  "type": "text",
  "props": { "content": "Preparing the keynote" }
}

本文三张实验图来自同一次本地 AUP 会话，ARC 2.0.0-beta.62，2026 年 10 月 8 日采集。它们是运行结果的记录，不是插画或正在本文中执行的演示。

接下来，我们把父节点的布局从纵向改为横向。画面的位置变了，但 demo-status 仍然是原来的节点，仍然可以从同一个路径读到原来的文字。

变的是父节点的排列方式。这个实验没有删除、重建或重新命名状态节点。

再下一步，通过会话提供的动作更新这个节点：

exec S/.actions/aup_patch

{
  "ops": [{
    "op": "update",
    "id": "demo-status",
    "props": { "content": "Ready for review" }
  }]
}

连接着的浏览器不刷新就出现了新文字。随后重新读取 S/tree/demo-status，也得到 “Ready for review”。

这件小事里，有两个变化被明确地区分开了：界面怎样排列，以及一个已知节点的内容怎样改变。操作完成后，我们还能回到原来的地址确认结果。Agent 不需要靠截图里的坐标去认出那行文字。

这个实验很小，也有意保持很小。这里的节点属于 UI 会话，不是一个已经持久化的业务任务；会话路径不能冒充永久地址。它没有证明重启后状态保留，没有证明任意 provider 可以无代价地替换，也没有证明多个观众的屏幕已经同步。随便给一个对象加上路径，并不会自动得到这些能力。

但它已经把我们的讨论从“AI 能画出什么”推进到了“系统可以对什么做操作，以及怎样确认操作结果”。

现在再解释名字，就容易一些了。AFS，Agentic File System，是组织和访问操作上下文的一套文件系统式接口。上下文可以来自不同 provider，背后可以是文件、服务或运行中的系统资源。路径把它们放进一个可以探索的空间，不要求底层都变成磁盘上的普通文件。

AFS-UI 把界面放进这套操作上下文。界面结构可以被寻址，显示端把它呈现给人，程序则可以通过受支持的操作与它交互。这里说的 projection，是同一上下文的一种呈现，不是对每一个像素建立一个文件。

AUP，Agentic UI Protocol，描述 UI 的结构及相关交互约定。Web Device 则是把这些描述落实为浏览器界面的具体显示设备实现。协议与设备不在同一层：换一种设备，不应要求业务概念跟着改名；但设备能呈现哪些组件、如何处理输入，仍然需要明确的能力和实现。我们的 AFS-UI 学习材料把这些层次拆开讲得更详细。

读者可能已经想到一个很合理的反问：正常的网页加 API，也能做到这个吧？

能。

如果一个网页和 agent 使用同一个后端对象，操作有稳定语义，权限在服务端执行，结果也可以被读取确认，它已经有了我们关心的很多性质。AFS-UI 不需要否认这种设计，才能成立。

我们的取舍，是把资源发现、寻址和操作的共同约定尽量放到系统层。这样，当越来越多界面、provider 和 agent 加进来时，不必每一对组合都重新解释一遍“这里这个东西，对应那边哪个东西”。这个约定是否真的省掉了工作，要在实现和维护中检验，不能只凭架构图宣布胜利。

更强的例子，是把界面连到一个真正的业务任务。人按下“完成”和 agent 执行相应操作，应当落到同一个业务规则上；重新排列界面不应改变任务身份。这个目标还要求业务 provider、授权和状态生命周期共同配合。上面的文字节点实验展示了其中一段机制，并不等于这个业务场景已经得到验证。

生成器越自由，哪些约定越不能随便变？

回到 OpenAI 的 Intelligent UI。它让人更容易看见一件事：未来的界面不一定是开发者事先为所有人画好的同一套页面。系统可以根据当前问题，决定这一刻怎样呈现才有帮助。

我很喜欢这个方向。但生成器的自由，最好放在系统能够承受变化的地方。

它可以决定把状态放在左边还是右边，适合用图还是表格，手机上先展示什么。它不应该因为换了一种画法，就悄悄改变一个操作的含义，更不应该替用户扩张权限。一个写着“预览”的按钮，不能在新一轮生成后变成真的提交，仍然让人以为它只是预览。

路径有助于指出对象，却不能代替规则。知道一个地址，并不等于有权操作它。界面上的确认也不能成为绕过服务端校验的理由。并发修改、撤销、断线重连，以及设备之间的能力差异，都不会因为我们选择了文件系统式接口而消失。

所以，我并不想把 Generative UI 的评价停在“这次生成得漂不漂亮”。那是必要的，只是不够。

我们还应该实际试一试：改变布局后，原来的操作目标是否还找得到？换一个 agent 后，它是否能发现允许的动作，而不是猜一个接口？操作被拒绝时，界面会不会仍然装作成功？上下文失效后，系统能不能告诉人为什么不能继续，而不是再生成一块看起来很正常的屏幕？

这些问题也应该拿来检验 AFS-UI。统一寻址有代价：命名要设计，操作含义要维护，能力差异要处理。我们愿意付出这份成本，是因为我们相信它能让界面、agent 和上下文的变化少牵扯彼此。这个判断需要持续由实际系统来证明。

这也解释了为什么我想用 AFS-UI 来讲这场演讲。胶片不是一段产品介绍之后才出现的附加 demo；它从开始就在那里。观众不需要先记住 AFS、AUP、Web Device 的全称，才能使用它。等理解了背后的结构，再回头看同一个画面，才会发现原来值得关注的不是它长得像不像一个新的 UI。

OpenAI 让“回答可以变成可操作的界面”更加可见。我们想接着回答的是：当这些界面不断变化，人和 agent 怎样继续在同一件工作上合作。

界面可以重新生成。已经做出的决定、正在操作的对象，以及下一步动作的含义，不该因此变得含糊。

相关资料：文中对 Intelligent UI 可用范围与状态行为的描述以 2026 年 10 月 8 日公开资料为准；产品后续可能变化。继续阅读 OpenAI 发布说明、Intelligent UI 帮助文档、MCP Apps 官方文档、MCP-UI和 A2UI。演讲与配套知识见 AFS-UI 胶片和 AFS-UI 学习入口。