你对 Agent 说：“分析一下昨天投放消耗为什么下降。”
它没有让你先选账户、再进报表、再配置筛选条件，而是现场生成一张临时工作台：左边是账户和时间范围，中间是趋势与异常计划，右边可以调整变量，模拟不同预算下的结果。
十分钟后，问题分析完了。这张工作台完成使命，被保存为一份可追溯的结果，不必成为产品导航里的永久页面。
这正是 Agent 现场生成 HTML 最有吸引力的地方：过去一项需求因为低频、个性化或排期不划算，只能退化成一段文字或一张表；现在，Agent 可以为当前问题即时生成一个可操作界面。
但如果你接着点击“把预算调整到 5 万”，事情就变了。
一张分析页可以临时生成，预算写入不能靠一段临时代码自行决定。系统必须校验账户权限、展示影响范围、触发人工确认，并等待业务服务返回权威结果。
所以，我对“所有界面都由 Agent 现场生成”的判断是：全动态 HTML 会成为长尾任务的重要形态，但不会成为所有企业交互的唯一终局。可见内容可以越来越动态，身份、权限、权威状态、风险提示与审计反而要更稳定。
全动态 HTML 最先改变的，是那些“不值得开发”的界面
固定页面有一笔隐形成本。
产品经理要先抽象共性，设计师要覆盖状态，开发要接数据和动作，测试要验证边界。只有需求足够高频、稳定，这笔投入才划算。
于是，大量长尾需求被挡在页面之外：
- 为某次会议临时做一个数据对比器；
- 按一名用户的知识水平生成交互讲解；
- 围绕一组特殊数据搭一个只用一次的模拟器；
- 把零散材料临时整理成一张可筛选、可追问的工作台。
开放式 Generative UI 改变的是这笔账。Google Research 展示的 Dynamic View 路线，可以围绕请求生成完整 HTML、CSS 和 JavaScript。浏览器本身又是通用运行环境，能承载表单、图表、布局、动画和交互逻辑。
这意味着，界面不必先成为一个长期产品功能，才有资格被创建。它可以只为一次任务存在。
但材料同时给出了另一面：完整生成有时需要一分钟以上，也会出错；相关人类评审是在忽略速度的情况下，更偏好生成式 UI。它证明了表达潜力，还不能证明生产稳定性。
因此，近期最值得做的不是把首页、导航和专业工作台全部推倒，而是找出那些低频、一次性、只读或可逆的场景。它们过去的开发成本高于业务价值，现在可能第一次有了合理解法。
它不是“让模型吐一段 HTML”这么简单
一个能演示的动态页面，模型返回代码、浏览器加载出来就够了。一个能长期使用的产品，至少还需要五层能力。
第一层是生成。Agent 要理解用户目标，决定信息结构、控件和交互，再产出可运行内容。
第二层是运行。生成的代码要进入隔离环境，限制网络、存储、跨页面访问和资源占用。MCP Apps 采用沙箱 iframe 承载独立 HTML，就是一种隔离思路。但“服务器提供一块独立 UI”和“模型每次现场写完整页面”仍是两回事，不能混为一谈。
第三层是能力。页面可以读取哪些数据、调用哪些工具、执行哪些本地函数，必须由宿主产品授予。界面生成权不等于工具执行权。
第四层是状态。用户正在编辑的值、Agent 运行到哪一步、业务数据库是否真的写入、历史里应该保存什么，不能只留在临时 DOM 里。
第五层是质量。Schema 校验、代码扫描、缓存、预生成、自动评测、超时与降级，共同决定用户看到的是工作台，还是一块加载失败的空白区域。
这里也能看出 A2UI 与开放式 HTML 的核心差异。
A2UI 的选择是：Agent 描述，客户端实现。Agent 在可信组件目录内表达“需要什么”，Renderer 用已有组件渲染。开放式 HTML 则让 Agent 同时参与设计与实现，表达空间更大，运行风险也更高。
这不是先进与落后的区别，而是控制权放在哪里。
自由度越高，信任成本越高
用户看到一张结构合理、按钮精致的页面，很容易产生“它已经准备好执行”的错觉。可视觉正确只是最浅的一层信任。
一套动态界面至少要通过四层信任。
内容信任：这组数据来自哪里，采用什么口径，更新时间是什么？一张图生成得再漂亮，也不能替代来源和口径。
交互信任：这个按钮会做什么，输入如何校验，危险动作是否始终使用一致术语和提示？如果“删除”“暂停”“提交”每次出现在不同位置，用户很难建立稳定预期。
执行信任：当前用户是否有权限，写操作是否经过业务校验，高风险节点是否把判断权交还给人，后端是否返回了权威回执？页面上的成功动画不是业务成功。
追责信任：谁在什么时间基于什么输入做了什么，失败后能否恢复，历史能否复现？如果动态页面结束后只剩一张截图，系统就失去了决策凭证。
沙箱能降低任意代码越界的风险，却不能自动解决错误数据、错误动作参数、提示词注入、跨租户访问和业务欺诈。
产品边界因此应该很明确：生成自由度与动作风险反向配置。展示和探索可以开放，业务写入必须收敛；低风险操作可以让 Agent 自主推进，支付、投放、删除、外发等动作必须回到可信组件、权限、HITL 和审计。
个性化不是每次都换一套界面
全动态 UI 还有一个容易被高估的价值：个性化。
理论上，Agent 可以按角色、设备、习惯和当前任务生成“最适合这个人”的页面。但“最适合”并没有稳定答案。统一材料收录的一项研究中，20 位设计师对 600 个 UI 的平均一致性只有 kappa=0.25。这至少说明，不同人对相似设计概念的理解存在明显分歧。
如果系统只凭一次对话猜偏好，个性化很可能退化成随机变化。
更麻烦的是，专业用户依赖肌肉记忆。相同动作的位置、术语和反馈越稳定，操作越快。团队协作也要求同一个问题可以复现：客服要能看到用户当时的视图，同事要能分享同一分析，审计要能确认当时展示的影响范围。
所以，动态界面仍要保留稳定锚点：
- 身份、导航、权限和历史入口；
- 高风险动作的名称、位置和确认方式；
- 组织统一的数据口径与业务术语；
- 可恢复的默认视图；
- 将当前界面固定为模板、分享和复用的能力。
个性化的目标应该是减少与当前任务无关的信息，而不是让用户每次重新学习产品。
哪些场景先开放，哪些必须收紧
判断一个场景是否适合现场生成 HTML，不要只问“模型能不能做”，要问三个更具体的问题：
- 出错后，用户能否及时发现？
- 结果是否可逆？
- 过程是否可追责？
教育模拟器、个性化讲解、临时数据探索、低风险内容工具和一次性内部应用，通常更适合开放生成。它们的表达形式难以预定义，长尾价值高，失败影响也相对可控。
高频专业工作台、多人长期协作、弱网或离线场景、高无障碍要求场景，需要更谨慎。这里的主要成本不是生成，而是一致行为、共同视图、跨端兼容和长期维护。
支付、投放、删除、外发、跨租户和强监管动作，则不应让现场生成的代码直接获得完整执行权。动态 HTML 可以负责解释、预览和模拟，最终操作要进入可信业务组件和确定性流程。
放到智投场景，这条边界很直观。
临时分析报告、数据探索和模拟推演，可以考虑在沙箱内使用开放式 HTML；预算修改、投放启停、审批和项目管理，应继续使用可信组件、业务权限与人工确认。
这只是基于内部方案的产品推演。现有材料不能证明智投已经上线开放式 HTML，也没有真实指标支持效果判断。
近中远期：动态内容会增加，稳定层不会消失
近期，全动态 HTML 更可能先进入只读报告、模拟器、教育、探索和一次性内部工具。产品的主结构仍是稳定 Shell 和可信业务组件。团队要先补的能力不是“生成更多样式”，而是沙箱、来源展示、回退和基础评测。
中期，同一个产品会按任务风险选择不同表达层：
高频 / 高风险 → 可信业务组件
中长尾 / 中风险 → A2UI 声明式 Surface
极长尾 / 低风险 → 沙箱 HTML
纯后台任务 → 无界面 Agent
动态界面也不会用完即丢。它可以被保存、固定成模板、分享给同事，并在后续任务中复用。产品团队管理的对象将从“有哪些页面”，扩展为能力、约束、风险等级和评测标准。
远期，即使模型、硬件、缓存和自动评测让生成成本接近实时，大量可见内容确实可能按任务即时出现，固定页面的数量也可能下降。
但这不等于产品只剩一个空白输入框。
身份、权限、权威状态、风险提示、审计和高风险动作仍需要稳定系统。它们不是界面的装饰，而是企业产品能够被信任和问责的基础。
更可能的终局是稳定 Shell 承载身份与责任，可信组件承载高风险动作，A2UI 负责受控组合，沙箱 HTML 覆盖极长尾，无界面 Agent 处理后台任务。
到了那时，产品经理确实会少画一些固定页面，但工作不会变少。我们需要定义结果、约束、状态、风险和验收标准，还要决定哪些东西可以变化，哪些东西必须永远保持稳定。
真正的产品边界，恰恰会在界面可以无限变化之后，变得更重要。
参考资料
- Google Research：Generative UI
- A2UI：How Does A2UI Compare
- Efficient Personalization of Generative UIs
系列导航
- 上一篇：【A2UI】Agent 组页面，低代码管资产（07-a2ui-low-code）
- 下一篇：【A2UI】企业路线图：从受控组件到动态组合（09-enterprise-a2ui-landing）