用 A2UI 缓解数据看板蔓延

当组织增加报表、筛选器、标签页和角色专属视图的速度，超过清理与合并速度时，就会出现数据看板蔓延。问题不只是界面拥挤：用户难以找到正确视图，产品团队要维护大量相似配置，安全团队也必须在持续扩大的界面中保持权限一致。

A2UI 可以让 Agent 用声明式消息描述当前任务所需界面，再由客户端使用已批准的原生组件渲染。它不会自动消灭看板，也不会自动改善数据质量或解决权限控制；它只是为“界面取决于当前问题”的场景增加一条呈现路径。

固定看板为什么不断增加

多数看板最初都有合理需求：团队需要稳定查看某个流程或指标。当每个新问题都变成永久页面时，蔓延就会发生：

这些既是界面问题，也是组织与数据治理问题。只有能够降低可测量负担时，才应引入生成界面。

例如，客服负责人提出：“列出最近 24 小时尚未解决的企业客户事故，按严重程度分组，并提供升级处理按钮。”固定产品通常要求用户打开看板、选择时间、客户类别和状态，再设置分组，最后跳转另一个工具执行升级。

Agent 可以把请求转换成受限查询，并生成包含摘要、分组列表和已批准 Action 的 A2UI Surface。任务结束后，该 Surface 可以删除。宿主仍使用自己的列表、标签、按钮与对话框组件，因此视觉风格和基础无障碍能力不依赖模型生成标记。

以下条件同时存在时，这种模式更有价值：

对于少量稳定且高频的流程，固定页面通常更快、更容易测试，也更容易培训。生成界面不是默认替代方案。

在 A2UI v0.9 中，Agent 创建 Surface，提供或更新组件，更新数据模型，最后删除 Surface。客户端把组件描述映射到宿主自有 Catalog。正常协议载荷不发送可执行 UI 代码。

这种设计降低了一类风险，但不能自动保证没有 XSS 或越权。如果渲染器接受原始 HTML、危险 URL 协议、任意远程 Catalog、未经净化的 Markdown 或高权限 Action，依然不安全。宿主必须校验消息、限制组件与 URL、净化允许的富文本，并授权每个高影响操作。

协议也不负责决定业务数据如何查询。数据权限应在数据源或服务边界执行，不能根据某个组件是否可见来推断。用户在常规应用中无法读取的客户记录，也不能通过 Agent 生成表格暴露。

不要一开始替换整个产品外壳。先选择一个操作摩擦较高的分析任务，定义允许的组件与 Action，并记录改造前基线。可衡量指标包括回答耗时、导航步骤、放弃查询、支持请求、无障碍缺陷和授权失败。

一个小型试点可以只支持：

应避免任意 HTML、开放式跳转、无限制文件访问和“调用任意 API”之类的通用 Action。只有现有 Catalog 具备明确测试覆盖和使用证据后，才增加能力。

任务型界面经常流式传输，因此部分状态是正常情况。标题可能先于表格到达，传输也可能在组件到达后、数据到达前中断。应分别设计加载、空数据、非法、离线和权限拒绝状态。

更新必须确定且限定在单个 Surface。重复消息不能重复执行高影响操作。删除 Surface 时要释放组件状态、绑定和回调。遇到不支持组件时，应显示安全降级并记录结构化错误，不能直接渲染原始内容。

无障碍仍是产品要求。流式更新不能抢走焦点；重要状态应适度播报；筛选器需要标签；全部 Action 必须可通过键盘操作。由于组件实现属于宿主，这些保证应内置于 Catalog，而不是让 Agent 每次生成。

生成界面应补充而不是自动替换稳定导航与核心流程。账号管理、权限、账单、法律同意、破坏性管理等任务更看重一致性与可审计性，适合继续使用固定页面。

受限探索、摘要、对比和上下文操作适合任务型 A2UI Surface。当某个生成模式变得高频且结构稳定时，可将其提升为固定产品功能，避免生成层本身变成第二种蔓延。

采用前确认：