假设你对 Agent 说：“帮我做一张本月的投放复盘页。”
一分钟后，你可能看到三种完全不同的产品：
- 一份固定格式的复盘报告，只是数据换成了本月；
- 一块临时工作台，图表、筛选器和异常卡片按任务动态组合；
- 一个刚刚生成的完整网页，布局、样式和交互都是现场写出来的。
它们都可以叫“生成式 UI”，但背后的能力、风险和交付成本差得很远。
产品选型最容易犯的错，是把三种路线排成从保守到先进的升级阶梯：模板最初级，组件树居中，现场写网页才是终局。我的判断正好相反：这不是成熟度阶梯，而是三档控制权。选择哪一档，取决于任务允许 Agent 决定到什么程度，以及出了问题由谁兜底。
路线一：选模板，把不确定性压到最低
第一种是 Controlled Generative UI，可以理解为“受控生成”。
前端已经做好了复盘报告、审批卡片、进度面板等完整组件。Agent 不负责设计布局，也不现场编写交互，只需要决定调用哪个组件、填入什么数据。
还是投放复盘的例子。系统识别出用户要看月度复盘，于是调用固定的报告组件，再把消耗、转化、异常计划等数据填进去。图表位置、筛选方式、按钮动作和异常状态，都由前端提前实现。
它的优势很直接：
- 路径短，通常能更快出现首个可用界面；
- 布局和行为稳定，测试对象明确；
- 品牌、权限、埋点和无障碍可以统一处理；
- 高风险操作能固定确认位置、术语和业务校验。
代价也很明确：Agent 只能在产品已经准备好的答案里做选择。遇到新场景，要么复用一个并不贴切的模板，要么等待前端增加新组件。业务越复杂，模板、分支和组件映射越容易膨胀。
所以 Controlled 不是“没有生成能力”，而是把生成限制在选择与填充。它适合高频、规则明确、错误代价高的任务，例如投放操作、审批确认、固定报表和标准流程。
路线二：组组件，在白名单里获得自由
第二种是 Declarative Generative UI，也就是声明式生成。
Agent 不再只能选择一张完整模板，而是可以从客户端允许的组件目录中挑选零件，描述它们的结构、数据和动作。客户端的 Renderer 再用可信组件把描述渲染成界面。
A2UI 走的就是这条路线。这里不展开协议细节，只保留一个必要背景：Agent 决定呈现什么，客户端决定具体怎么画。Agent 可以提出“上方放异常摘要，中间放趋势图，下方放计划筛选和处理按钮”，但它不能凭空调用客户端没有注册的组件，也不需要把一段任意 JavaScript 交给产品执行。
这给了产品一个中间地带。
投放复盘不必永远长成同一张报告。只看异常时，可以减少总览、增加问题卡片；需要比较账户时，可以组合筛选器和对比图；准备汇报时，可以突出结论和依据。界面结构会随任务变化，但组件、动作、样式和权限仍在产品的可信范围内。
这条路线的成本不会凭空消失，只是换了位置：
- 产品要定义一套 Agent 能理解的组件目录；
- 组件的能力、适用条件和限制要描述清楚；
- Agent 输出的结构必须经过解析、校验和失败降级；
- 不同客户端的 Renderer 和组件版本要保持兼容；
- 界面临时状态、Agent 运行状态和业务结果仍要同步。
也就是说，Declarative 用 目录与协议成本，换取模板路线没有的组合自由。它适合“界面形态会变化，但可用能力可以事前定义”的任务，例如动态表单、多维比较、审批流程和临时分析工作台。
路线三：现场写网页，表达力最大
第三种是 Open-ended Generative UI，也就是开放式生成。
Agent 可以现场生成 HTML、CSS、JavaScript，甚至完整的小应用。它不再受现有组件目录限制，可以为一个很长尾的需求临时创造新的布局和交互。
这条路线最有吸引力的地方，是不用先证明某个场景值得进入产品 Roadmap。一个教育模拟器、一份临时数据探索工具、一个只用一次的内部页面，都可能在需求出现后直接生成。过去因为开发成本太高而不值得做的界面，现在有机会被覆盖。
但“网页生成出来”只是第一步。
统一研究材料引用的 Google 开放式 GenUI 研究显示，完整生成的体验具有很强表达力；材料也明确记录，某些生成可能超过一分钟并偶有错误，而且相关偏好评测忽略了速度。这个结果不能外推为所有开放式生成都很慢，但足以提醒产品团队：Demo 里的可生成不等于可交付。
开放式路线需要额外回答：
- 生成代码能访问哪些网络、数据和本地能力？
- 页面出错、卡死或消耗过多资源时如何隔离？
- 每次布局变化后，回归测试和无障碍怎么保证？
- Web、移动端和桌面端是否表现一致？
- 用户下次回来时，看到的是原页面、代码快照，还是重新生成的结果？
- 一次性页面产生的业务动作，由谁授权和审计？
沙箱 iframe 是常见的隔离思路。这里还要区分一个容易混淆的概念：MCP Apps 可以在沙箱 iframe 中承载 Server 提供的独立 HTML，但它不等于模型每次都在现场生成网页。沙箱解决的是部分隔离问题，不会自动解决业务权限、数据真实性和操作审计。
因此，Open-ended 更适合低风险、低频、形态事前难以枚举，并且可以接受等待和隔离的任务。对于预算调整、删除、外发、跨账户操作等场景，即使页面可以现场生成，执行权不能交给生成代码。
三条路线，比较的不是“AI 含量”
把三条路线放在一起，差异会更清楚：
| 维度 | 选模板 Controlled | 组组件 Declarative | 写网页 Open-ended |
|---|---|---|---|
| Agent 的决定权 | 选组件、填数据 | 在 Catalog 内选结构、组件和数据 | 生成布局、样式与交互代码 |
| 首个可用界面 | 通常最快 | 居中，可通过流式渲染改善 | 通常更慢，受生成和校验影响 |
| 表达空间 | 低 | 中高 | 最高 |
| 安全边界 | 预制组件与业务规则 | Catalog、Schema、Renderer | 沙箱、权限和运行时隔离 |
| 可测试性 | 高 | 需要协议与组合测试 | 需要生成结果和运行时测试 |
| 品牌与跨端 | 最容易统一 | 由 Renderer 统一 | 每次生成都要重新约束 |
| 长尾覆盖 | 弱 | 中强 | 最强 |
| 主要债务 | 模板和分支持续增长 | 目录、验证、版本和状态治理 | 隔离、评测、性能和维护 |
这张表不是绝对性能排名。统一材料没有提供三条路线在同一任务、同一模型和同一设备上的量化对照，因此不能写成“声明式一定快几倍”或“开放式一定需要一分钟”。
更重要的差异是：自由度越高，越多运行时兜底责任会从预制工程资产转移到生成、验证和隔离系统。模板路线靠提前开发和测试兜底；声明式路线靠组件白名单、协议校验和 Renderer 兜底；开放式路线则要在每次生成后重新完成更多验证。
三条路线也各有反例。模板不代表零成本，场景一多同样难维护；声明式不代表天然安全，错误数据和越权动作仍可能通过合法组件发生；开放式也不代表不能进入生产，只是需要更强的隔离、评测和权限设计。
产品选型：先问三件事
比“哪条技术更先进”更有用的，是按顺序问三件事。
第一，错误代价有多大？
先用错误代价给自由度设上限。
如果任务涉及预算、删除、外发、跨租户或合规数据，优先使用 Controlled；确实需要动态组合时，可以进入 Declarative，但业务动作仍要经过后端权限、校验和人工确认。
如果任务只读、可撤销、影响范围小，才有条件向更高自由度开放。
第二，界面形态能否事前定义？
如果流程和布局长期稳定，模板通常最省总成本。
如果组件类型已知，但顺序、数量和组合会随任务变化，Declarative 更合适。它解决的不是“什么都能画”，而是“在已知能力里，不必为每种排列重新做页面”。
如果连需要什么组件都难以提前枚举，需求又足够低频，Open-ended 才开始显示价值。
第三，交付约束有多强？
首屏速度、弱网、跨端、强品牌、无障碍、审计和长期维护要求越高，路线越应该向 Controlled 或 Declarative 收缩。
一次性、低风险、允许等待、可以沙箱隔离，而且展示形式本身有明显价值的任务，才值得向 Open-ended 放开。
这三步的顺序不能反。很多方案先被“现场生成完整网页”的效果吸引，再补权限和状态设计；更稳妥的做法是先确定风险上限，再讨论形态自由。
智投为什么更适合混合路线
从目前可读的智投内部规范看，它采用的是一条 Controlled + Declarative 的混合路线。
Skill 按步骤输出结构化 JSON 指令，前端根据 type 渲染通用组件。规范定义了 collect、select、processing、review、confirm、upload、complete、error、message 九类交互形态。
其中，“九类形态对应预制组件”属于 Controlled；“Skill 通过结构化指令决定当前步骤呈现什么内容”又带有 Declarative 的方向。这样的设计把意图理解和流程变化留给 Agent/Skill，把组件渲染、交互呈现和品牌一致性留在可信前端。
证据边界也必须说清：内部文档仍列出了 P0 到 P3 的开发优先级，因此它能证明方案和规范存在，不能证明九类组件已经全部上线，更不能推出真实延迟、完成率或用户反馈。
即便只讨论方案，这条路线的取舍仍然成立。广告投放包含账户权限、预算、审批和外发等高风险动作。为了让产品看起来更有“AI 味”，把这些界面全部改成现场生成，并不会提高任务价值，反而会扩大验证范围。
更合理的结构是：
- 高频、高风险操作使用可信业务组件；
- 规则内的中长尾任务允许声明式组合；
- 临时分析、模拟推演等低风险极长尾需求，再评估沙箱 HTML；
- 身份、导航、权限、历史和业务权威状态保持稳定。
反方观点是，模型能力继续提升后，固定组件和 Catalog 会逐渐成为历史。这个判断在“能否生成”层面可能越来越接近事实：生成会更快，错误会更少，自动评测也会进步。
但企业产品还要解决“谁有权执行、结果是否真实、出了问题如何恢复、历史如何审计”。这些问题不会因为模型更会写网页就自动消失。
所以，三条路线真正划分的不是 AI 能力，而是产品愿意交出多少控制权。模板、声明式组件和开放式网页会长期共存。产品经理要做的，也不是押注唯一终局，而是让每一类任务获得刚好够用的自由度。
A2UI 系列导航
上一篇：01｜【A2UI】Agent 开始“说界面”
下一篇：03｜【A2UI】聊天是否是最好的交互方式