你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
这些 Generative UI 方案怎样比较？
按职责、地址、状态与交互合同比较，而不是只按名字排队。
名字里都有 UI，不表示它们解决同一层问题。这里的“合同”指各方约定的消息格式、操作含义和能力边界。先比较职责，再比较合同，最后才决定哪些可以一起使用。下面是对官方说明与 Arc 实现的架构对照，不是性能测试或优劣排名。
先分清正在比较什么
| 项目或概念 | 主要讨论对象 | 学习入口 |
|---|---|---|
| AFS / AFS-UI | 可操作上下文及其界面投影 | 上下文 · 界面 |
| AUP | 节点、数据连接、事件与设备能力 | 协议 |
| A2UI | 声明式界面及其数据模型更新 | A2UI |
| MCP Apps | MCP 工具的交互界面与宿主合同 | MCP Apps |
| MCP-UI | 围绕 MCP Apps 的实现工具及旧接口兼容 | MCP-UI |
| AG-UI | agent 与用户应用之间的事件交换 | AG-UI |
| Flutter GenUI SDK | Flutter 中的生成式界面实现与编排 | Flutter GenUI |
| Stitch | 界面的设计与迭代工作流 | Stitch |
这些行并不互斥。例如，A2UI 与 AG-UI 的职责可以配合；Flutter GenUI 使用 A2UI；MCP-UI 工具实现 MCP Apps。不要把同一生态的协议与 SDK 重复计算为两个独立阵营。
表达、状态与动作分别在哪里？
| 边界 | AUP / AFS-UI | A2UI |
|---|---|---|
| 界面结构 | 带可识别 ID 的节点，类型、属性和子节点（不是用户身份） | 组件描述与组件关系 |
| 数据连接 | 从路径读取资源、把输入写回资源、用资源更新节点属性；见绑定 | 组件绑定到界面数据模型 |
| 交互 | 事件绑定到明确的 AFS 操作目标 | 用户动作按协议传回并处理 |
| 呈现 | 按目标渲染器与能力合同实现 | 客户端依据可用组件目录实现 |
| 还要问什么 | 资源范围、身份、权限和状态归属如何配置？ | 数据模型与应用业务资源如何连接？ |
AUP 侧参见 节点与绑定；A2UI 侧参见官方 组件结构、数据流 与 动作。最后一行是本专题提出的评估问题，不是在断言另一方缺少某个功能。
| 观察问题 | MCP Apps | AG-UI |
|---|---|---|
| 主要连接 | 工具、UI 资源与宿主 | agent 后端与用户应用 |
| 界面表达的重点 | 宿主承载的 HTML UI | 事件通道；具体界面另由应用及集成方案表达 |
| 数据与交互 | UI 与宿主按消息合同交流，可请求工具调用 | 消息、工具调用与状态等事件 |
| 要核对的边界 | 宿主支持、沙箱与能力策略 | 两端支持的事件与状态处理 |
资料：MCP App 构建合同 · AG-UI 事件模型。
AFS-UI 的论点应该落在哪里？
本专题关注的是：能否让界面、资源与操作，在一份明确的可寻址上下文中保持联系？ 人使用投影后的画面，agent 可以在获授权的范围内使用相应的结构与操作入口。更换视图时，应检查哪些业务地址和操作合同仍然成立。
这不是“别人只有图片，我们才有结构”。A2UI 有声明式结构和路径绑定，MCP Apps 有资源与工具合同，AG-UI 有状态事件。更有说服力的研究问题是：各自的地址与状态边界在哪里，跨过这些边界时需要多少适配，如何验证改变显示方式没有改变业务操作。
展开一个共同例子：同一场投票，两种视图
下面是假设应用设计，地址也是示例；不是已经运行的跨项目演示。
讲者问：“最希望哪个部分保持稳定？”观众选择“资源地址”或“操作含义”。讲者先看柱状图，再把结果换成表格。一次有效切换应保留已经投出的票。
在一个采用 AFS-UI 的设计里，可以把职责明确写成：
| 对象 | 示例安排 | 改成表格时怎么办 |
|---|---|---|
| 投票结果 | /example/poll/results 由业务 Provider 提供；Provider 是把资源接入 AFS 并实现操作的适配层 | 仍读这个资源，改变显示类型 |
| 投票动作 | /example/poll/vote 是接收选项的执行入口 | 按钮仍调用这个动作，不直接改统计数字 |
| 权限与规则 | 执行动作的一侧检查参与者身份、投票是否开放及重复投票规则 | 表格或图表都不替代这些检查 |
| 显示端 | 讲者屏幕和观众页面分别读获准访问的结果；应用接好支持的订阅或刷新机制 | 两端得到新结果，各自选择图表或表格 |
这里“共享状态”指投票记录与结果归业务资源管理。一个人的滚动位置或当前选择的显示方式可以留在自己的显示端。界面节点的 ID 只是让系统识别某个图表、表格或按钮，与参与者的身份不同。
采用 A2UI 时，可以让图表或表格组件绑定界面数据模型中的 /poll/results。业务服务仍保存票数；应用把最新结果送进数据模型，再把用户的投票动作接到业务服务。A2UI 在这段链路中定义界面表达和更新；业务持久化、投票规则以及两个客户端如何共享同一场投票，仍要在应用集成中落实。参见官方数据流。
采用 MCP Apps 时，可以把结果界面做成工具关联的 HTML UI；界面通过宿主请求投票工具，业务服务处理后再返回结果。宿主是否支持相应消息与能力，是这条路径的一部分。两个宿主怎样得到同一份最新结果，还需要应用设计。参见官方构建说明。
因此，可以比较的具体问题是：换掉图表以后，是否还读取同一个结果、调用同一个动作，并执行相同规则？AFS-UI 的设计选择是把资源与动作都放进共同的可寻址工作环境；另外两种方案也能连接同一业务服务，但连接落在各自协议与应用之间的边界上。是否减少适配工作，需要实现并测量，不能从这张示意表直接得出。
资料核对：2026-09-26。外部项目持续演进，采用具体 API 前请回到官方版本文档。