Introducing AFS-UI：人与 agent 共享的界面
AFS-UI 是 Arc 的界面系统。它把界面结构、相关状态和支持的操作放进 AFS 的可寻址空间，让人和 AI agent 都能直接使用同一个系统。
人看到文字、图表和按钮，通过点击、输入或触摸操作。Agent 则可以通过路径找到对应的界面节点，读取结构和状态，并执行所支持的操作。它不必先把界面当成一张图片，猜出按钮的位置和文字的含义，才能开始工作。
这是我们构建 AFS-UI 最主要的原因：让界面从一开始就同时服务人和 agent。两者的输入方式可以不同，但应该能够指向相同的对象，理解相同的状态，并通过明确的约定参与同一件工作。
Generative UI 让这个问题更加重要。界面可以根据当前任务生成，也可以随对话重新排列。如果程序访问界面的方式只剩下识别它此刻的外观，每一次布局变化都会带来新的辨认工作。AFS-UI 为 agent 提供了另一种入口：先找到对象，再对它进行操作。
同一个界面，两种访问方式
看一个简单例子。屏幕上有一行状态文字，显示 “Ready for review”。人直接读到它；agent 可以通过对应节点的路径，读到这是一个文字节点，以及它的当前内容。
我们为 AFS-UI 演讲准备的真实会话里，这个节点名叫 demo-status。把当前会话路径简称为 S，节点地址是 S/tree/demo-status。父级布局从纵向改成横向后，这个节点仍然可以从同一个地址找到。随后更新它的内容，连接中的浏览器就显示新文字，沿原来的路径也能读回结果。
本地运行截图，ARC 2.0.0-beta.62，2026 年 10 月 8 日。这是同一 UI 会话中的寻址与更新示例；会话地址的有效范围与业务数据的持久保存是不同问题。
按钮也是同样的思路。人看到的是可以点击的控件；agent 可以查看它的结构和事件所关联的操作。具体应用把这个操作连接到业务规则后，人和 agent 就可以通过各自的入口，对同一件事采取行动。路径指明对象，操作约定说明能做什么，授权决定谁有权做。
这里的共同基础是对象与操作的对应关系。人不需要学习路径才能使用界面，agent 也不必模仿人移动鼠标，才能访问系统已经明确表达的结构。
视觉理解仍然有用，例如判断图表是否清楚、布局是否拥挤，或者操作没有结构化入口的外部软件。DOM、可访问性树和 API 也早已让程序获得了屏幕之外的信息。AFS-UI 的选择，是进一步把界面纳入应用其余资源所使用的寻址与操作体系，使它成为系统的一部分，而不是需要另外辨认的一张画面。
AFS 提供基础，AFS-UI 把界面接进来
AFS 是 Agentic File System。它借用了文件系统里一个熟悉的办法：用路径找到资源，用一致的操作方式访问它。通过不同的 provider，文件、内容、服务或运行中的资源可以进入这个空间。Provider 可以理解为把某一类资源接入 AFS 的实现。
这些资源不必都是磁盘上的文件。路径的作用，是让使用者知道资源在哪里，以及怎样进一步了解它。至于路径背后是本地数据，还是一个服务，由相应的实现处理。
AFS-UI 把这个思路延伸到界面。人所使用的画面，可以成为这份上下文的一种呈现；界面本身的结构也能够在受支持的会话中被找到、检查和操作。这里的“上下文”包括工作所需的数据、当前状态和可用动作，不只是聊天记录或一段给模型看的 prompt。
理解下面几个名字，就能分清它们的职责：
| 名称 | 它负责什么 | 可以怎样理解 |
|---|---|---|
| AFS | 资源的寻址、发现与访问 | 系统中找得到、用得上的资源空间 |
| AFS-UI | 界面如何参与这个空间，供人和 agent 使用 | 整体的界面系统 |
| AUP | 描述界面结构及相关交互约定 | 表达界面的协议 |
| Web Device | 将内容、页面和组件组织成网站 | 面向 Web 的网站实现能力 |
这套设计受到 Unix、Plan 9 和 X Window 的启发：资源可以有统一的名字，显示与计算可以分开，窗口如何组织也可以由独立的机制处理。AFS-UI 把这些思路用于人和 agent 共同工作的环境，不要求使用者先了解那些历史系统。
AUP 描述界面，Web Device 组织网站
AUP 是 Agentic UI Protocol。 它用结构化描述表达一个界面包含什么，以及它怎样连接到数据和操作。
例如，一张任务卡片可以包含标题、状态、输入框和一个动作。AUP 可以表达这些元素的类型、属性、组织关系，以及受支持的数据绑定和事件。text 表达文字，input 接收输入，action 表达动作，view 组织元素。这些基础类型称为 primitives，也就是界面协议的基本词汇。更丰富的类型还可以表达表格、图表或地图；具体设备支持哪些类型和交互，要看对应实现。
AUP 不要求每一次界面变化都调用模型。界面描述可以由开发者编写，由程序组装，也可以由 AI 生成。生成方式可以变，描述应当如何被解释、事件怎样连接到操作，仍然需要明确约定。
Web Device 解决的是把这些能力落实为一个网站时，需要补齐的事情。
以你正在阅读的文章为例，除了标题和正文，它还有自己的网址、语言版本、站点导航、主题样式，以及分享出去时显示的标题和图片。整站还需要组织内容、装配页面和生成可访问的输出。这些属于 Web Device 的职责，不是给 AUP 多加几个基础节点就会自动得到的东西。
一个 Web Device component 是可复用的网站呈现单元。例如，文章头部组件可以接收标题、作者和封面，再把它们呈现出来；导航组件负责站点入口。页面布局把这些单元组合起来。因此，text 这样的 AUP primitive，与“文章头部”这样的网站组件，处在不同层次。前者是表达界面的基本类型，后者是围绕具体呈现任务组织起来的实现。
区分它们有一个很直接的方法：如果关心“这个控件表达什么、与哪个操作相连”，先看 AUP。如果关心“这篇文章在哪里、怎样切换语言、整站头部怎样复用”，先看 Web Device。它们协作，但不互相替代。
还有一个容易混淆的名字：浏览器里的实时 UI Device 会话。前面的 demo-status 示例使用的是这类会话，它负责运行中的界面树、事件与更新。Web Device 则负责网站的组织、渲染和发布。两条路径有相关的界面能力，但不能只因为最后都出现在浏览器里，就把它们当作同一件事。
今天，ArcBlock 的网站、Learning 知识地图和演讲胶片，已经使用这套技术的不同部分。它可以承载一个正式网站，也可以支持更贴近当前任务的交互界面。要做哪一种体验，决定了需要组合哪些能力。
同一份工作，可以有不同的设备入口
这里的 device，不只是桌上摆着的一块屏幕。它也可以是一种输入、输出和交互环境。终端擅长文字与命令，浏览器擅长图形、表单和丰富内容；当前 UI Device 实现中已经有终端与浏览器后端，网站还可以使用前面介绍的 Web Device 能力。
概念示意，图中界面并非产品截图。上方的 Terminal 与 Web 对应已有实现方向；下方的 VR／3D、RPG／MUD 和 Voice 是未来设备设想。共同底座不意味着同一份界面描述已经能够自动运行在所有设备上。
想象同一项“审核探险计划”的任务。终端可以显示它的标题、状态和可执行命令；网页可以呈现一张任务卡。未来的 VR Device 可以把它放进一个空间工作台，RPG Device 可以把它呈现为房间里的任务对象，MUD Device 则可以用文字描述场景、接受命令。MUD 是一种以文字和命令参与共享世界的交互形式。这里保留下来的是任务的身份、相关数据和操作含义，具体如何看见它、如何表达操作，可以因设备而异。
智能音箱更能说明这个设计为什么需要设备能力适配。它能听、能说，也许有几个触摸按钮，却没有地方显示一张完整表格。如果要在这样的设备上使用同一项任务，我们设想它可以读出状态、按需解释细节，再用语音请求确认。这里的“降级”是换一种设备能表达的方式，尽量保留任务的意义。涉及确认的动作不能因为没有按钮，就省掉确认。
这些未来设备需要各自的实现，也需要为具体交互设计合适的替代方式。一个三维模型不能保证仅靠一句话就表达清楚；无法合理转换时，系统应当说明限制，或者让用户转到合适的设备继续。AFS-UI 提供的方向，是让呈现可以变化，而背后的资源仍然有明确的名字与操作约定。
相近的 UI 名称，分别在解决什么？
这一领域的名字很多，但它们并不都在同一层。产品里的一个交互体验、描述界面的协议、连接 agent 与应用的协议，以及承载网站的运行系统，可以同时存在。
下面按各自公开资料中的主要职责来比较，不把名称相近直接理解为相互替代：
| 方案 | 主要关注点 | 与 AFS-UI 的区别或联系 |
|---|---|---|
| ChatGPT Intelligent UI | 让 ChatGPT 为问题选择并生成可交互的回答形式 | 它是产品体验与模型能力；AFS-UI 关注界面在可寻址系统中怎样被访问和操作 |
| A2UI | 发送声明式 UI 描述，由客户端组件呈现，支持数据绑定与交互 | 与 AUP 在描述界面这一层有相近问题；AFS-UI 还关注界面与 AFS 资源空间的关系 |
| MCP | 让 AI 应用访问外部工具、资源与上下文 | 是连接外部能力的协议，本身不等于一个界面描述系统 |
| MCP Apps / MCP-UI | 工具向宿主提供可交互的 UI 资源，并与宿主通信；MCP-UI 提供相关实现工具 | 重点在工具界面与宿主的结合；AFS-UI 的入口是 AFS 中的界面结构及操作 |
| AG-UI | 通过事件连接 agent 后端与面向用户的应用，传递消息、工具调用和状态变化 | 重点在前后端交互流；它与描述界面的方案可以配合 |
| OpenAI 插件开发 | 组合技能、MCP 服务和可选界面，接入 ChatGPT 与 Codex | 是宿主集成与分发路径，与 ChatGPT 自身的 Intelligent UI 产品能力需要区分 |
| AFS-UI | 让人通过呈现、agent 通过路径，访问对应界面结构与支持的操作 | 以 AFS 为基础，AUP 表达界面，具体设备和网站能力负责呈现与使用 |
MCP Apps 并非只能显示静态内容，A2UI 也不只是卡片格式。它们都包含交互方面的约定；AG-UI 同样关注状态。AFS-UI 的价值不建立在假设这些方案“没有状态”或者“不能操作”之上，而在于把界面与系统其余资源放进共同的寻址和操作环境。
这些层次可以组合。组合是否可用，仍取决于具体实现的适配和能力，不能从表格推导出已经互相兼容。以上外部方案按 2026 年 10 月 10 日公开资料核对。
对于已经有稳定 API 和可访问性支持的应用，AFS-UI 提供的是另一种系统组织方式，而不是要求重做所有界面。它尤其值得考虑的场景，是人和 agent 都需要反复进入同一份工作，或者界面经常改变而资源与操作含义需要保持清楚的应用。它不会自动把任意外部软件变成 AFS 界面，也不会因为有了路径就取消授权、持久化或并发控制的需要。
如果只记住一个概念，那就是：同一个界面，应当既能让人看懂和操作，也能让 agent 找到和操作。AFS-UI 用路径与结构，为后者提供直接入口。
从 AFS-UI 学习入口开始，可以继续了解 AUP、AUP 与 Web Device 的分工和界面寻址。关于这套设计背后的故事，见《界面会变，工作应该留下》；具体使用约定见 AUP 文档与 Web Device 文档。