假设一个团队从一张协议流程图开始做 A2UI：
Agent 输出 JSON，前端识别组件，页面上流式出现表单、卡片和按钮。Demo 跑通以后，协议接入确实完成了。
但用户可能只是多看到了一张动态卡片。任务有没有更快完成，数据有没有真正写入，失败后能不能恢复，没人说得清。
问题不在协议。企业落地 A2UI 的第一目标，不应该是接入协议，而是跑通一个值得动态交互的业务闭环。
截至 2026 年 7 月 28 日，A2UI 官方把 v0.9.1 标为当前生产版本，v1.0 仍是 Candidate。更重要的是，A2UI 只负责 Agent 与前端之间的 UI 表达。意图路由、业务 API、任务状态、长期记忆、权限和审计，都不在协议替企业解决的范围内。
所以，真正的落地路线不是“选标准—建 Renderer—全面改造前端”，而是：
从业务闭环开始，用受控组件验证价值，抽象状态和动作，形成 Catalog，再逐步增加声明式组合。
一、先选闭环，不要先选协议
第一个场景决定了团队是在验证业务价值，还是在展示技术能力。
适合 A2UI 起步的任务，通常同时具备五个特征：
- 用户需要看、选、改、确认，纯文字往返效率低；
- 输入或输出有多种形态，固定页面又难覆盖全部情况；
- 任务有明确的完成态，能知道“到底办成没有”；
- 风险可控，失败可以恢复，关键动作可以人工确认；
- 有真实用户和现状基线，能比较上线前后的变化。
例如，“分析一次投放异常并确认处理方式”比“生成一份任意形式的投放工作台”更适合作为起点。
前者可以拆成识别异常、比较可能原因、补充参数、确认动作、等待业务回执。每一步都有输入、状态和结果。后者看起来更有想象力，但需求边界、完成标准和风险都不清楚。
反过来，有些任务根本不需要 A2UI。用户只要一句可验证的结论，任务可以完全后台运行，或者本来就是系统间调用，增加界面只会增加维护成本。
立项时可以先问六个问题：
- 动态界面是否真的减少了理解或操作成本？
- 任务是否有权威完成状态？
- 业务数据和权限接口是否已经明确？
- 失败是否可恢复，高风险动作是否可拦截？
- 组件或交互是否有跨场景复用可能？
- 是否有指标证明它比旧流程更好？
答不清这些问题，先别讨论采用哪个版本的协议。
二、第一阶段只做 Controlled
很多团队担心从固定组件开始“不够 A2UI”。这个担心把动态程度误当成了产品价值。
A2UI 官方允许确定性 Agent 返回预制界面。第一版完全可以固定组件、固定主流程，只让模型处理三类事情：
- 理解用户意图，把任务路由到正确流程；
- 发现缺失信息，决定下一步需要用户补什么；
- 在规则无法覆盖时提供推荐和解释。
字段校验、选项显隐、权限枚举、业务写入，不需要经过模型。比如一个账户下拉框，可见范围应该由后端权限决定；必填和格式可以由客户端即时校验；只有“根据目标推荐哪些账户”才需要模型参与。
这条边界很实用：模型处理不确定性，工程处理确定性，业务系统给出权威结果。
第一阶段真正要验证的，是用户能否更顺畅地完成任务。团队同时应统一几项以后不会轻易改变的基础语义：
- 每个任务、交互面和动作如何标识；
- 用户提交采用什么回传格式；
- 业务动作如何返回成功、失败和处理中；
- 重复提交如何去重；
- 中断后从哪里继续；
- 失败时如何保留已输入内容。
这些不是提前建设“大平台”。它们是在避免第二个场景出现后，每支业务团队都发明一套新的动作和状态。
三、复用出现后，再把组件清单升级为 Catalog
当不同场景开始反复使用同一种选择器、审核卡或进度组件，数据结构也只在字段和动作上略有变化，稳定的共性就出现了。
这时才适合进入 Declarative 阶段。
Catalog 常被简单理解成“Agent 可以使用的组件清单”。对企业来说，这远远不够。一个可治理的 Catalog 至少要说明：
- 组件能表达什么业务语义；
- 接受什么数据，哪些字段必填；
- 可以触发哪些动作；
- 哪些动作在客户端执行，哪些必须调用后端；
- 什么角色、设备和场景可以使用；
- 不支持或版本不匹配时如何降级；
- 哪些用法属于高风险，需要额外确认；
- 如何测试它的正确性和可用性。
也就是说，Catalog 是 Agent 与客户端之间的能力合同，不是 UI 素材库。
组件也需要分层。高频、高风险的任务使用稳定业务组件，例如预算调整、审批、账户选择；中长尾任务可以用 Text、Select、Table 等基础组件组合；低风险、极长尾的探索任务，才考虑进入沙箱 HTML。
动态范围不是一次性技术选型，而是按任务风险分配的产品策略。
进入声明式组合后，还要建立一条明确的质量链路：
生成 → 解析 → Schema 校验 → 修复或重试 → 渲染
前端不能对非法结构“尽量猜”。未知组件要安全降级，旧会话要绑定可兼容的目录版本。否则一项组件升级，就可能让历史任务的整块界面消失。
四、模型、Workflow、API 和 Renderer 各守一条边界
A2UI 项目容易出现一种职责膨胀：因为模型能生成协议，团队就把越来越多判断都交给模型。
稳定的企业方案需要五类责任方：
| 责任方 | 主要职责 |
|---|---|
| 模型 | 意图理解、语义推荐、解释、长尾组合 |
| Skill / Workflow | 步骤、规则、依赖、重试、恢复 |
| 业务 API | 权限、取数、写入、幂等、权威回执 |
| Renderer | 可信渲染、即时反馈、客户端函数 |
| 人 | 主观判断、冲突裁决、高风险确认 |
这个分工可以用一个小动作检验：用户展开下拉框时，系统会不会再次调用大模型？
如果选项是固定枚举，就由客户端提供；如果与权限相关，就由后端返回；如果需要远程搜索，就走 API 的分页和缓存；如果只是字段联动，就用客户端函数。只有语义推荐需要模型。
模型调用得少，并不代表 Agent 能力弱。它意味着系统把模型预算留给了真正需要推理的地方。
反方会认为，这最终只是“带聊天框的工作流”。问题的关键不是流程是否固定，而是固定了什么。权限、业务红线和权威写入必须固定；意图理解、解释和中长尾组合可以动态。把两类问题分开，才有资格继续扩大 Agent 的自主范围。
五、状态、数据和安全要从第一天建设
A2UI Demo 通常只有一份看得见的状态：前端卡片变了。
生产环境至少有四份状态：
- Renderer 的临时状态：输入、选择、展开和焦点；
- Agent 或 Workflow 的运行状态：当前步骤、等待、错误和重试；
- 业务系统的权威状态：数据是否真的读取或写入成功；
- 历史与记忆状态：用户做过什么决定，下次如何恢复。
正确的收敛顺序应该是：
本地即时反馈
→ 提交业务动作
→ 后端返回权威结果
→ 更新任务状态
→ 历史卡片转为完成态摘要
按钮变灰不是成功，模型说“已经完成”也不是成功。只有业务系统的回执可以把任务推进到完成态。
MVP 不需要一次建完复杂状态机，但最少要有 pending / succeeded / failed。多步任务再补 interrupted / resumable，写操作要有幂等键，高风险任务要有审批和审计，跨会话任务要有服务端 checkpoint。
历史也不能只是把旧界面原样保存。旧按钮可能重复执行，权限和业务数据也可能已经变化。用户真正需要的是决策凭证：当时输入了什么、做了什么动作、业务结果是什么、何时完成、后续哪些结果依赖它。
如果允许重新编辑旧步骤，应显式重开，并让后续推导失效。界面回退与业务回滚是两件事；涉及预算、删除或外发时，不能用“返回上一步”假装已经撤销业务结果。
安全同样不能只依赖 Catalog 白名单。声明式协议缩小了代码注入面，却不会自动解决数据越权、错误参数、隐私泄露和错误审批。涉钱、删除、外发、跨权限、合规和批量写等动作，必须由业务规则强制 HITL，不能让模型或 Skill 自行关闭。
六、不要只看渲染成功率
即使每次都能成功渲染，一个 A2UI 项目也可能没有改善业务任务。
企业至少需要五层指标：
| 层级 | 优先观察 |
|---|---|
| 协议 | Schema 通过率、非法组件率、修复重试、fallback |
| 交互 | 首反馈、首个可操作控件、总完成时长、人工轮数 |
| 状态 | 重复提交、状态不一致、恢复成功、旧卡误操作 |
| 安全 | 越权、危险动作拦截、审计完整 |
| 业务 | 任务完成率、节省时间、工作流替代和复用 |
材料没有提供统一的行业阈值，企业也不该生搬一个数字。更可靠的做法是先测旧流程基线，再按任务风险设置升级门槛。
例如，第一阶段先证明固定组件能提高完成率、减少人工轮数，并把状态不一致控制在可接受范围。达标后，才允许 Agent 在更多基础组件中组合。动态范围扩大后，如果协议修复、fallback 或人工纠正明显上升，就应收紧 Catalog，而不是用更多提示词掩盖问题。
A2UI 的自由度应该由指标解锁，而不是由模型能力宣传解锁。
七、已有内部协议，不必为了标准全面重写
智投内部材料已经定义了九类 UI 指令、标准动作回传，以及 freeform、interrupt、resume、revisit 等控制动作；卡片有 active、collapsed、summary 三种生命周期。HITL 设计还明确：业务红线不能被模型和 Skill 关闭。
这些材料证明的是内部方案和协议设计，不能证明九类组件已经全部上线，也不能证明断网恢复、跨设备续做和历史摘要已经端到端打通。
在这个证据边界下，更稳妥的路线分三段。
近期，先核实现有组件、协议和状态链路。统一动作、错误、业务回执和指标，补齐真实链路测试。对外描述保持准确：具备 A2UI 的核心思想，不等同于已经完整采用官方规范。
中期，建立内部 type 与 A2UI Catalog 的语义映射。把客户端函数与后端工具分开，给旧会话绑定版本和 fallback，并在中风险场景扩大基础组件组合。
长期，再根据跨端、跨 Agent 和生态复用的真实价值，评估官方 Renderer、Catalog 协商和少量沙箱 HTML。
先全面采用标准，确实可能减少一部分未来协议债务。但当前 A2UI 仍在 v0.9.1 与 v1.0 Candidate 过渡期，企业还承载大量标准之外的业务语义。全面重写会把标准变化风险和业务回归风险叠在一起。
更合理的选择是：不为标准名词重写，也不让内部协议成为无法映射的孤岛。
八、企业 A2UI 的落地顺序
把全文压缩成一条路线：
选择业务闭环
→ 用固定组件验证价值
→ 统一任务、状态和动作
→ 抽象 Catalog 与 Data Model
→ 建立校验、版本和 fallback
→ 用指标扩大声明式组合
→ 最后开放少量高自由度生成
这条路线看起来没有“让 Agent 一次生成所有页面”那么激进，却更接近企业真正需要的结果：正确、可操作、可恢复、可审计，并且能持续演进。
A2UI 的价值从来不在于界面每次都不一样。它真正改变的是，企业开始把组件、数据、动作、状态和治理整理成一种 Agent 可以理解、客户端可以执行、业务可以负责的产品语言。
上一篇：【A2UI】A2UI是否是最终形态，如果所有界面都实时生成？（08-agent-generated-html）
下一篇：无（本篇为 A2UI 系列第 09 篇）