万物演进，什么应当保持？——演讲审阅稿

这张索引用于阅读，不属于口述讲稿。编号对应胶片与下文段落；点击主题可查看例子、边界和技术来源。

本稿供演讲者审阅，第一人称经历来自本人提供的设计背景。研究建议与具体措辞仍待确认；它不是按中文语速计时的演讲稿。

01 · 我们要问的问题

我们已经很擅长问：AI 能怎样改变界面？它能生成一个页面吗？能调整工作流程吗？能在此时此刻，为这个人组合出适合的控件吗？这些问题都很有价值。今天我想再问一个问题：当这些东西都能变化时，什么应该保持稳定？

我的出发点是在 Arc 中构建 AFS 和 AFS-UI 的经验。我会用这个具体实现展开讨论。我们关心的是软件架构：当系统的各个部分分别演进时，人、agent、数据和显示端怎样继续协作？

这场演讲本身就运行在我们讨论的网站与演示能力之上，因此有一个真实系统可以观察。它也给我们提出了一个要求：说清楚这个运行中的例子证明了什么，以及哪些判断还需要另外的实验。

02 · 画面变化时，什么也跟着变了？

想象一个叫作“准备主题演讲”的任务。它有标题、状态，还有一个将它标记为“可供审阅”的操作。今天，它是一张卡片；明天，模型生成了更合适的布局，它变成一行表格；下周，同一个任务又出现在分步骤的引导流程里。

我希望四项约定能在改版后继续成立：这是哪个任务、操作产生什么效果、谁有权执行操作，以及每个视图怎样连接到它的状态。这是我接下来会反复回到的契约。

人可能需要重新熟悉控件的位置。但 agent 是否也必须换一种方式识别任务？已有集成是否需要换一种方式读取状态？“标记为可供审阅”的效果，是否应该随着按钮的变化而变化？

已有 API 和支持多种视图的应用已经解决了其中一些问题。我们的尝试，是把资源、界面结构和操作放进共同的可寻址环境，让参与者能通过同一个系统发现它们的关系。这是否减少了耦合，是可以检验的问题。

03 · 关于 X Window 的一段记忆

这个设计背后的一段经历，可以追溯到大约 1993、1994 年我接触 X Window 的时候。让我震撼的是一件很具体的事：程序可以在一个地方运行，却把界面呈现在另一个地方的显示器上。报告不必被绑在执行计算的那台机器的屏幕上。

在 X 的术语中，server 负责显示与输入，应用 client 可以运行在远端。如果先接触的是 Web 应用，这个命名可能听起来有点反过来。但真正有意思的是这种分离：计算发生的地方，与人看到并控制计算的地方，是两个不同的架构角色。

我想把这个问题带到有 agent 的世界里：如果显示端被当作系统中的一种设备，而操作所依赖的上下文不被困在某一次界面渲染中，会出现哪些可能性？

04 · 保留边界，重新选择实现机制

我从 X Window 中借鉴的是职责的分离。今天提出类似的架构问题，并不需要复制它的协议、传输机制或安全假设。

显示技术可以更新，交互方式可以更新，描述视图的机制也可以更新。在这些变化中，我们仍然需要知道：应用的工作在哪里发生，显示端怎样参与，以及参与者可以执行哪些操作。

这就是我所说的“延续下来”：有一份契约，让其他部分能以更小的扰动发生变化。契约本身也可以演进，但这种演进应当明确，并且能被依赖它的各方理解。

Unix 对 AFS 的影响也是如此。共同接口的价值，在于它让不同工具能够合作完成工作。而这种价值必须经得住底层资源真实差异的考验。

05 · Everything is context

AFS 是 Agentic File System。它使用类似文件系统的接口，组织 agent 或应用可以处理的资源。这些资源可以是文件、服务，也可以是运行中系统的一部分。

“Everything is context”需要准确理解。它不是说一切都是文本，也不是说应该把所有资源复制进模型的 prompt。它意味着工作环境可以被呈现为可发现、可寻址、可操作的对象。

Prompt 是这个环境的一种使用者，面向人的界面是另一种，执行操作的工具也是一种。它们各自需要以适当的形式，访问环境中适当的部分。

这也限定了我们的主张：组织上下文并不等于解决认知。模型仍然可能误解资源、选错操作，或者作出没有依据的推断。架构让这些活动有了更明确的位置。

06 · 地址让操作有明确的目标

继续看“准备主题演讲”这个任务。在架构示例中，我们给它一个示意地址 /work/tasks/keynote。读取它可以得到标题和状态；支持的操作可以在资源旁边被发现。使用者可以引用任务，而不必描述它的卡片位于屏幕哪里。

这个引用包含环境和路径两部分。可以理解为：“这个项目的工作空间中的 /work/tasks/keynote。”把路径复制到另一个工作空间，不会自动指向同一个任务。引用跨越边界时，我们必须保留或转换它所在的上下文。

在选定的工作空间内，界面改版不应要求更换这个引用。移动任务或替换任务，则是另一种变化：应用需要保留别名、迁移使用者，或者明确告知旧引用已无法解析。

因此，斜杠分隔的名称只是开始。有用的约定还要说明：它标识什么对象、在哪里解析，以及使用者能依赖它多久。这才是这里所说的稳定可寻址性。

07 · Provider 保留真实差异

Provider 把资源的具体实现接入 AFS 接口，mount 则把它放进命名空间。在这个例子中，provider 可以把任务集合暴露在 /work/tasks 下。数据可能仍然位于某个服务中；挂载并不意味着把服务复制成了本地目录。

现在考虑替换这个服务。兼容的替代实现仍须返回约定的标题和状态，声明支持的操作，并保持操作的效果。如果原来的 provider 拒绝只读用户将任务标记为可供审阅，而新 provider 却接受了，那么即使两者都返回有效 JSON，契约也已经被破坏。

共同接口还必须让差异可见。替代实现也许支持读取但不支持写入，也许不能发出变更通知。使用者需要先知道这些，才能判断编辑器或实时视图能否正常工作。

这就是 provider 边界所承载的意义：用共同方式发现和调用操作，同时明确能力与行为。它给我们一个比较实现的位置，并没有免除比较本身。

08 · 操作也是契约的一部分

对于这个任务，读取操作取得当前状态；示例中的“标记为可供审阅”操作把状态从草稿改为可供审阅。即便生成的界面把相应控件摆在一起，它们仍然是不同操作。

假设两个人同时打开草稿。一个人将其标记为可供审阅，另一个人还在编辑旧副本。契约必须说明：这个基于旧状态的编辑会被拒绝、合并，还是允许覆盖新值？如果 provider 支持条件写入，调用方可以提交自己读取时的版本；版本已变化时，收到冲突结果。界面随后就能提供有意义的恢复方式：获取新状态，请用户协调差异。

只读用户的写入被拒绝，是另一种结果。重试不能像处理版本冲突那样解决权限问题。Provider 与授权边界必须保留这些区别。

AFS 提供共同的操作词汇。这个例子还指定了任务 provider 应满足的应用行为，并不声称所有 provider 都采用相同的并发规则。把卡片改成表格行，不应该改变这些规则。

09 · 人看到界面，agent 通过地址访问

现在回到界面。人看到任务标题、状态和控件；agent 应当能够通过地址访问对应的对象、状态和所支持的操作。

这是我最希望强调的 AFS-UI 特点：当系统能够直接暴露已知的应用结构时，agent 不应该只能从像素重新推断这些结构。

当然，agent 已经有其他选择：浏览器暴露 DOM，无障碍树描述许多控件，应用也提供 API。这里的问题是，界面怎样参与系统其余部分所在的共同操作环境，使这些连接不必在每个交互表面上各自重做一遍。

这是一种语义上的对应关系，不是承诺每一道阴影、每一个装饰像素都有路径。理解外观时，图像与视觉推理仍然有价值。我们要保留的是一条直接通向应用已知含义的访问途径。

10 · 用小例子把区别呈现出来

这里有两个用途不同的例子。Learning 页面上的小型本地模型，可以把任务从卡片切换为表格行，同时展示保持不变的示意地址。它帮助读者快速理解想法。

我们还在本地运行时测试了一个真实 AUP session。AUP 是 Agentic UI Protocol，用来描述界面节点及其连接。这个 session 有一个名为 demo-status 的文本节点。读取它在 AFS 树中的路径，可以得到节点类型和屏幕上显示的内容。调用 session 的 patch 操作修改内容后，连接着的浏览器无需重新加载就会更新。

随后，我们把父节点的布局从纵向改为横向，再改回来。状态节点保留了自己的身份与可读取路径。这是在实际界面结构上完成的一次小型、可重复的变化实验。

必须说明它的范围：demo-status 是 UI 节点，还不是带有业务规则的任务服务。我们观察到了节点可寻址性，以及向一个显示端交付更新。把这个节点连接到假设的任务资源，是下一步应用工作。区分这两个例子，才能既解释设计，又展示已实现的机制，而不把它说成完整任务应用。

11 · 上下文与投影承担不同职责

图中有两种边界。资源投影决定参与者能使用哪些工作资源；视图投影决定怎样呈现这些可用资源。接下来使用这两个完整名称，以免混淆。

对于这个任务，资源投影可以向审阅者开放标题和状态，同时隐藏作者的私人笔记。视图投影则可以把这个可访问的任务显示为卡片或表格行。视觉改版改变后者；审阅者访问范围的变化改变前者。

AFS-UI 的核心想法，是把界面视为操作上下文之上的视图投影。模型提出新的呈现方式时，不必重新定义任务及其操作。界面结构本身也能进入可寻址环境，真实状态节点的实验已经展示了这一点。

这让调试问题更准确：是对象变了，参与者的资源范围变了，还是只有视图变了？不同答案会把我们带到系统的不同部分。

12 · 明确状态应该属于哪里

任务是否可供审阅，属于共享工作状态；审阅者浏览器的滚动位置，属于那个显示端。选中哪个任务，可能是个人状态、session 状态或共享状态，取决于应用。共同资源环境不会替我们作出这些归属决定。

如果每个显示端都用自己的浏览器变量保存任务状态，就会产生需要协调的副本。如果把每个人的滚动位置放进同一个共享资源，几个显示端可能会争抢该看哪里。明确状态及其所有者之后，这两种错误都更容易描述。

这场演示也一样。演讲者当前所在的幻灯片可以与跟随者共享；观众的私人笔记应该保持私有。离开跟随模式的读者，可以保留自己的本地页码。

这些是普通的应用决策，却会带来直接可见的后果。有用的基础应当为它们提供明确的对象、操作和边界，而不是让状态归属隐含在最先渲染出来的组件中。

13 · Display、session 与 connection

Display 是呈现视图、接收交互的地方；session 组织某个交互上下文关联的状态；connection 传递消息。三者的生命周期和职责可以不同。

本地实验说明了为什么必须区分。第二个浏览器可以打开同一个私有 session，并取得当前视图。但随后的一次 patch 到达了第一个浏览器，没有到达第二个。因此，把同一个 session 标识打开两次，并不足以建立我们想要的观众跟随行为。

运行时还有独立的 live-channel 机制，提示了另一条集成路线，但我们尚未完成所选部署方式下的浏览器级验证。这是一个有用的实现发现：期望的参与策略必须匹配实际的消息交付机制。

用户的问题更直接：重新连接后，我的工作还在吗？这块屏幕会跟随另一块屏幕吗？我能独立浏览吗？架构需要给出具体答案，而不只是画出几个显示端。

14 · 一场演示，多种参与策略

想象把现场观众接入同一场演示活动。跟随者读取演讲者的页码；独立阅读者保留自己的页码；投票参与者通过投票操作提交答案。这是三种策略，而不是同一个连接的三个名称。

在实现增强 demo 之前，就可以先描述契约：只有演讲者能修改共享页码；跟随者收到变化，晚加入的人取得当前页；投票者可以提交允许的答案，但不会因此获得编辑幻灯片的权限。

我们也可以指定失败后的行为：断线重连后，跟随者应该恢复到当前页，而不是重放中间每一次翻页，仿佛演讲重新开始。应用必须选择并实现这样的恢复方式。

这个多显示端应用是下一项实验，尚不是私有 session 测试所证明的结果。架构上的进展在于：消息交付、状态归属和执行权限现在可以分别测试。

15 · 共享上下文，不同的资源世界

回到任务工作空间。作者看到任务和私人笔记，审阅者看到任务却看不到笔记。AFS 资源投影可以选择资源、改变它们出现的位置，并限制可用操作。

假设双方都看到 /work/tasks/keynote。要说他们共享同一个任务，应用必须知道这两个引用解析到同一个底层资源。路径字符串相同还不够。如果其中一个资源视图重命名了入口，跨视图引用就需要对应映射。这也是为什么从一开始，我们的稳定引用就包含工作空间。

这种有边界的资源视图，在 AFS 中有时被称为 Small World。它让参与者在适合自己的系统范围内工作。审阅者不必看到作者能看到的一切，也能协作处理同一个任务。

可寻址仍不等于有权操作。执行边界必须落实允许的操作。同样，限制资源可见范围，也不会使其中的恶意内容变得可信。范围、授权和解释，仍是不同职责。

16 · 组合不只发生在屏幕上

当资源与操作能够被一致地寻址时，组合就可以超越把组件并排摆放。一个视图可以使用其他位置提供的资源；另一个视图也可以使用这个可操作的资源对象；provider 内部可以变化，同时保持使用者依赖的契约。

这个架构目标的价值，是允许系统分部分演进。模型、渲染器、资源 provider 和交互方式，不应总是要求周围所有部分一起替换。

但组合也带来义务：两个使用者可能竞争更新同一状态，引用可能失效，操作可能随版本变化，访问权可能被撤回。共同命名空间给这些情况提供表达的位置，并不会自动解决它们。

实际要问的是：每个边界保持什么约定？如果无法描述，就应当谨慎使用“可组合”这个词。成功组装一次，其证据强度低于经历实质变化后仍能持续协作。

17 · 看看运行中视图的背后

对于真实 session，inspector 应当让我们跟随一条具体链路：先读取 demo-status，与浏览器显示内容比较；再通过 session 操作 patch 这个节点；最后，在结构树和连接着的显示端上观察新内容。

这些观察针对 AUP 结构。浏览器 DOM 回答的是另一个问题：渲染器怎样把节点变成 HTML？内容文件又回答另一个问题：作者写下的材料来自哪里？检查工具只有清楚标明正在查看哪一层，才真正有用。

对于完整任务应用，还可以沿着链路继续向后追溯：哪个资源提供状态？哪个操作修改状态？在哪里检查权限？哪次更新导致显示节点变化？这样，检查工具才能解释应用，而不只是一个漂亮的 JSON 面板。

长期来看，我们希望整个网站都能接受这样的检查。小型 session 实验提供了已经验证的起点；把精致的 inspector 集成进演示，仍是另一项工作。

18 · 这场演示已经证明了什么

用四个名称概括架构：AFS 组织资源及其操作；AFS-UI 是工作上下文之上的界面架构；AUP，即 Agentic UI Protocol，描述界面节点、绑定与事件；Web Device 提供网站所需的内容、路由、语言、主题和渲染机制。

假设的任务贯穿这些角色：provider 在 AFS 中暴露任务；AUP 视图把状态节点连接到相应数据，把交互连接到相应操作；渲染环境呈现视图。Web Device 是这个网站采用的实现，协议词汇与网站主题组件属于不同层。

今天的证据来自两处：原生演示与关联的 Learning 页面，验证了网站内容到呈现的路径；隔离 session 实验，验证了真实节点检查、patch，以及保持节点路径的布局变化。两者都不是比较性能的实验结果。

进一步的任务 provider 与观众跟随实验已经提出，但尚未完成。因此，我们有一个可检查的具体实现，也有清楚的研究主张边界。

19 · 比较各自标准化了哪条边界

这里重点看两个相关方向。A2UI 通过流式消息描述声明式界面，区分结构和状态，并支持基于路径的数据绑定。MCP Apps 通过 UI 资源和宿主通信机制，把交互式 HTML 界面连接到 MCP 宿主。

这些都是真实的架构契约。说其他方案只有像素、没有状态或路径，是不准确的。问题应该是：每份契约规范的是哪条边界？

对于任务示例，A2UI 帮助描述状态显示，并绑定到界面模型中的数据；MCP Apps 为嵌入式任务界面与宿主、工具之间的通信提供定义；AFS-UI 强调界面结构与更广泛资源环境的关系，两者都可以在其中被寻址和操作。

侧重点不同，不等于优越性或不兼容性的证明。适配器也许能连接这些方案，但需要检查实际行为。Learning 比较材料包含其他 SDK 与工具；本次演讲的问题更集中：任务视图变化时，每个参与者还能依赖哪份契约？

20 · 让稳定性的主张可以被检验

我们已经完成一个小型变化实验：真实 session 的布局从纵向变为横向，而状态节点的路径和值保持不变。读取节点的使用者不必寻找新的屏幕位置。这说明的是布局变化下的界面身份保持，并不证明对所有渲染器或 provider 都独立。

现在，用任务示例提出更强的实验：先有任务资源、卡片视图，以及读取状态并调用“标记为可供审阅”的 agent。保持资源 provider 不变，把卡片替换为表格行。Agent 应当继续使用同一个资源引用与操作，操作仍产生相同状态转换。

失败可以被具体识别：旧引用无法解析，操作产生了不同效果，或者只读审阅者突然能够修改任务。即使表格看起来正确，也不能弥补这些失败。

然后单独改变另一部分：替换 provider，同时保持所承诺的契约。重复相同的任务用例和操作被拒绝的用例。分别改变不同部分，才能看出哪条边界保持成立、哪条引入了耦合。这才是支持更广泛稳定性论证所需的实验。

21 · 衡量维持这些关系的成本

一种评估方式，是比较同一个应用的不同实现，在受控变化下的表现：替换渲染器或 provider 后，使用方需要作出哪些改动；失效引用造成哪些故障；保持操作语义需要多少工作。

也可以比较 agent 完成任务时的不同访问方式：视觉交互、结构化界面访问，以及应用支持时的直接操作访问。比较必须使用相同的任务定义，并仔细说明各自能力。如果给某个系统额外的特权信息，却把全部差异归因于架构，就会产生误导。

对于多显示端，可以衡量更新行为、断线恢复，以及共享状态与私人状态是否正确分离。对于访问边界，拒绝操作的行为与成功执行同样重要。

这些是建议的评估方向，不是今天报告的结果。实现让问题具体到可以研究；比较收益则需要有基线、失败用例和充分复现细节的研究设计。

22 · 可寻址性也带来义务

明确表达操作环境有成本。必须决定哪些对象值得拥有稳定身份、哪些地址是临时的，以及契约变化时怎样通知使用者。Provider 需要实现兼容行为，而不只是相似的方法名。

Inspector 能帮助理解系统，但访问边界处理错误时，也可能暴露信息。共享视图能简化协调，也可能让状态归属错误同时影响多个用户。结构更明确，并不会消除认真设计的必要性。

有些领域中，视觉表示承载的信息很难由简单对象模型充分表达。绘画、照片或空间布局仍可能需要视觉推理。我们应当暴露已有的有意义结构，同时保留完成其他工作所需的视觉工具。

因此，决策在于：哪些稳定抽象值得投入成本去维护？当抽象保持了应用真正关心的关系，并使剩余差异更容易理解时，它才有价值。

23 · Learning 系统也可以呈现这个想法

关联的 Learning 内容保留了详细定义、primitive 目录和比较来源，演讲结束后仍可继续查阅。读者可以从自己感兴趣的问题出发，沿着关联继续探索。

最后再回到“准备主题演讲”。我们从卡片出发，逐步区分任务资源、界面节点、显示端和参与者的执行权限。这些区别让我们找到四项需要保持的约定，也能具体识别它们何时被破坏。Learning 页面可以逐项展开，而不必把这场演讲变成参考手册。

24 · 什么应该延续下来？

任务可以从卡片变成表格行，同时保持关于身份、操作效果、访问规则，以及它与视图之间关系的约定。这些是讨论 Generative UI 时，我希望大家检查的基础。

真实 session 展示了其中一个小片段：布局变化时，节点保留路径；通过地址发起的更新到达连接着的显示端。任务 provider 场景将这种机制扩展为应用契约。提出的变化实验，将帮助判断这份契约在更有挑战的替换中能保持多少。

AFS-UI 是把这些关系纳入一个可检查的操作环境的一次具体尝试。它更广泛的收益，应当通过应用和比较证据来判断，也要计入维护契约的成本。

这个问题很古老，也重新变得紧迫。X Window 让我看到计算与显示可以是不同角色；Unix 展示了共同名称与操作的价值；Generative UI 让视图变得格外流动。这使我们有理由重新思考这些想法：当视图不断变化时，人和 agent 应该能够依赖哪些约定？

25 · 留给讨论的三个问题

讨论 Generative UI 时，我希望留下三个开放问题：模型改变界面之后，其他参与者应该能够依赖什么契约？怎样测试契约能否经受渲染器、provider 或显示端的变化？怎样保留有用的共享上下文，同时给每个参与者适当的资源视图和权限？

这些问题跨越界面生成与系统设计，也把实现工作连接到可用性、测试和长期演进研究。

幻灯片与 Learning 内容提供了具体起点。下一步有价值的工作，是把一项主张检查到足够清楚，让我们能对什么证据可以支持或反驳它达成共识。谢谢。

01 · The question

从“AI 能生成什么”转向“哪些基础应当稳定”。以 Arc 中 AFS 与 AFS-UI 的具体实现提出架构问题，不把这场演讲讲成产品功能清单。

02 · Change

用“准备 keynote”这个任务贯穿全场。它可以从卡片变成表格行，但任务身份、操作效果、参与者权限，以及视图与状态的连接这四个约定应保持明确。已有 API 与多视图架构也解决其中一部分；AFS-UI 的探索是把资源、界面结构和操作放进共同的可寻址环境。

03 · An architectural memory

讲述约 1993—1994 年接触 X Window 的个人经历：程序运行的位置与显示的位置分开，报告可以出现在另一块屏幕上。X server 负责显示与输入，client 可以在远端。

04 · What endures

借鉴的是职责分离，不是照搬 X 的传输、协议或安全假设。稳定的合同也可以演进，但应显式说明怎样变化、影响谁。

05 · AFS

AFS 是 Agentic File System。Everything is context 指任务能接触的操作环境，不表示全部信息都要进入提示词，也不表示组织信息就解决了理解问题。

06 · Addressability

示例地址统一为 /work/tasks/keynote，并始终连同“哪个工作空间”解释。稳定不等于永远不能改名；移动资源时要保留映射、迁移引用，或明确报告旧引用失效。

07 · Providers

Provider 把实际资源接到 AFS，mount 决定入口。替换任务服务时，标题、状态、动作效果与权限规则仍需兼容。能返回同样格式的 JSON，不足以证明合同相同。

08 · Operations

同一个任务用读取、标为可审阅、过期版本冲突和只读用户被拒绝，说明操作语义。条件写入只适用于提供该能力的 Provider，不能说所有资源都有相同并发规则。

09 · AFS-UI

重点讲人和 agent 对同一系统的访问：人看画面，agent 可以使用对应的结构和操作入口。承认 DOM、无障碍树、API 也提供结构；问题在于能否把它们纳入一致的操作环境。

10 · Teaching model

先区分两个例子：Learning 中卡片与列表切换是本地教学模型；实际 AUP 会话中，读取 demo-status 路径能看到屏幕文字，patch 后浏览器不刷新就更新。父布局改成行再改回列，节点身份与路径保持。这个实测证明 UI 节点寻址和单显示端更新，不等于已经接入完整任务业务服务。

11 · Projection

固定使用 resource projection（资源投影）与 view projection（视图投影）两个完整名称。审阅者能看任务但不能看私人笔记，是资源范围；卡片或表格行，是呈现方式。调试时先判断究竟哪一层改变。

12 · State ownership

同一个任务的状态可以共享，滚动位置可以是显示端本地状态，选中项则按应用决定归属。再映射到演讲：跟随页码可共享，个人笔记和退出跟随后的位置可私有。

13 · Display and session

实际测试发现，同一私有 session 的第二个浏览器能取得初始画面，但后续 patch 只更新第一个。因此相同 sid 不能当作观众广播的证据。源码和运行时另有 live channel；当前部署的浏览器入口仍未验证完成。

14 · Participation policy

把跟随、独立浏览、投票分别定义为应用策略，写清谁能更新哪一个状态、晚加入看到什么、断线如何恢复。这是下一步实验，不宣称已经实现。

15 · Small World

同一个任务在作者与审阅者的资源范围中可以有不同入口。证明协作的是解析到同一个底层资源，而不是两个路径字符串碰巧相同。资源范围、执行授权与对内容的理解仍是不同责任。

16 · Composition

组合既涉及界面，也涉及资源、操作与权限。一个 surface 能嵌入另一个视图，并不自动证明业务语义、状态或授权已经一致。

17 · Inspection

围绕 demo-status 走实际链路：读节点、对照画面、执行 patch、观察树和显示更新。AUP 结构、DOM、内容文件回答不同问题。完整应用还应继续追到数据来源、业务动作和授权；本站通用检查器仍待集成。

18 · A running implementation

在一处定位四个名称：AFS 组织资源与操作，AFS-UI 是围绕工作上下文的界面架构，AUP 是节点/绑定/事件协议，Web Device 承担站点实现。网站胶片与隔离会话实验各有已验证范围，业务 Provider 替换与观众同步仍需实验。

19 · Related work

现场只展开 A2UI 与 MCP Apps 两个比较对象，把其他 SDK 和工具留给 Learning。比较它们为同一个任务保持哪一层合同，承认已有状态、路径和交互能力，不做无依据的优劣排名。

20 · Evaluation

先复述已完成的布局切换实验，再提出更强的任务实验：卡片换成表格行，agent 仍使用同一任务引用和动作；再独立替换 Provider。旧引用失效、动作变义、权限意外放开都算失败，即使画面仍好看。

21 · Research questions

这些是建议评估方向，不是已经取得的实验数据。比较 agent 访问方式时应保持任务与权限条件可比，不能把额外特权误归因为架构收益。

22 · Limits

稳定的基础也带来责任：地址失效怎么办、状态归谁、如何兼容、失败怎样解释、权限在哪里实施。演讲需要坦诚呈现这些成本。

23 · Learning

Learning 作为会后细读入口简短带过，随即回到贯穿例子，收束任务资源、界面节点、显示端与权限四个角色，避免演讲末段变成另一场网站介绍。

24 · The thesis

回到卡片变成行这个起点，区分实际节点实验与更广泛架构假设。稳定的约定为变化提供依托；独立演进的收益与维护成本仍需通过应用和比较实验检验。

25 · Discussion

邀请听众用自己的系统回答：什么必须保持？哪个变化能够检验它？然后进入问答与学习网站。