用户对 Agent 说：“帮我新建一个投放任务。”
几秒后，页面出现账户和计划下拉框。账户加载出来了，计划还在转圈；用户切换账户，旧计划列表晚一步返回；他选中一个计划并点击提交，按钮马上变灰。任务到底创建成功了吗？
如果过十分钟刷新页面，或者明天从另一台电脑打开，这张卡片应该继续可操作、显示失败，还是只保留一条完成记录？
这才是 A2UI 进入真实业务后的难题。卡片能出现，只能证明界面协议被 Renderer 接住了。一次任务真正完成，还要让 UI、Agent、业务系统和历史记录收敛到同一个结果。
一、渲染成功，只完成了四分之一
A2UI 负责描述 Surface、组件、数据和动作。它能让 Agent 不写任意前端代码，也能通过流式更新逐步把控件呈现出来。
但在一个真实任务里，至少同时存在四份状态：
| 状态 | 记录什么 | 谁负责 |
|---|---|---|
| UI 临时状态 | 输入、选中、展开、焦点 | Renderer |
| Agent 运行状态 | 当前步骤、等待、失败、继续 | Agent / Skill |
| 业务权威状态 | 账户、计划、预算、提交结果 | 业务服务 / 数据库 |
| 历史与记忆状态 | 决策留痕、任务恢复、长期偏好 | 会话 / Memory |
按钮变灰，只代表前端接到了点击。Agent 说“已完成”，也不代表业务数据库真的写入。数据库写入成功后，如果历史卡片还保留原来的“提交”按钮，用户仍可能重复执行。
所以生产环境的核心对象不应只是“消息”或“组件”，而是 Task + Surface + State + Action Ledger：这是什么任务、界面处于什么阶段、谁做了什么动作、最终以哪个业务结果为准。
二、加载速度不是一个数字
很多团队只记录接口总耗时。但对动态 UI 来说，用户经历的是四段等待：
- 系统是否已经理解并受理意图；
- 第一个可操作控件何时出现；
- 控件所需的业务数据何时就绪；
- 提交后，权威业务结果何时返回。
这四段不能互相替代。
骨架屏出现得快，不代表用户已经能操作；表单能输入，也不代表账户和计划已经可选；进度条走到 100%，更不代表业务系统已经确认成功。
A2UI 的渐进渲染适合先给出稳定结构，再补充数据和局部结果。前提是每次变化都对应真实状态。长任务应该告诉用户“正在读取账户权限”“正在创建任务”“等待业务回执”，而不是用循环动画制造进展。
产品上更有效的做法，是减少必须经过模型的环节。模型处理意图识别、语义推荐和不确定性；固定校验由客户端完成；确定的业务取数和写入直接走 API。模型参与越多，不等于产品越智能；确定流程绕开模型，通常更快也更容易排错。
反方观点是，模型和推理速度还会继续提升，今天的等待问题可能只是阶段性的。这个判断有一半成立：生成会变快，但权限查询、远程数据、业务写入、跨系统确认仍有自己的延迟。模型提速不会自动消除整条链路的等待。
三、一个下拉框，暴露了整个系统的职责边界
下拉框看起来只是一个 Select，交付时却要先回答：选项由谁算？
| 选项类型 | 合适的执行方 | 典型场景 |
|---|---|---|
| 静态枚举 | 客户端 | 固定状态、合作类型 |
| 权限相关数据 | 后端 API | 当前用户可见账户、项目 |
| 大量远程搜索 | 后端 API | 品牌、计划、笔记 |
| 本地校验与显隐 | Client Function | 必填、格式、字段联动 |
| 语义推荐 | Agent / 模型 | 推荐竞品、标签 |
最应避免的设计，是用户每展开一次下拉都调用大模型。模型不该承担权限过滤，也不适合处理固定枚举。它应该只进入真正需要语义判断的环节。
执行方分清后，问题还没结束。
用户快速输入关键词时，较早发出的请求可能更晚返回。用户切换账户后，旧账户的计划列表可能覆盖新结果。上游字段变化后，下游已选值可能已经失效。远程搜索还会遇到分页、空结果、权限变化、缓存过期和部分失败。
因此，一份可交付的下拉需求不能只写“支持搜索和多选”，还要定义：
- 选项来源和权限责任方；
- 何时加载、何时缓存、何时失效；
- 并发请求如何取消或丢弃旧结果；
- 上游变化后，下游值是清空、复核还是保留但标记过期；
- 空态、错误态和无权限是否使用不同反馈；
- 已选项翻页后如何保留，提交前是否再次校验。
下拉框之所以典型，是因为它把 客户端即时性、后端权威性和 Agent 语义能力挤在了一个小控件里。
四、一次点击，要经过六个完成态
用户点击“提交”后，一个可靠的链路至少包含：
本地即时反馈
→ 请求被受理
→ 业务动作执行
→ 后端返回权威结果
→ Agent / Skill 推进下一步
→ 历史卡片归档
本地可以先进入 pending，避免用户重复点击；但 succeeded 必须来自业务权威结果。失败时要保留输入，让用户能重试或修改，而不是清空整张表单。
重复提交还需要幂等保护。连点、网络重试、页面刷新和 Agent 自动重试，都可能让同一个动作被发送多次。幂等的含义不是“按钮禁用”，而是业务系统能识别同一次提交，只执行一次。
还要处理一个不那么显眼的分叉：业务写入已经成功，但 Agent 没收到响应，仍停留在处理中。此时不能盲目重做业务动作，而要先用任务标识查询权威结果，再让 Agent 和界面追上真实状态。
产品经理在评审“完成态”时，应追问三个问题：
- 谁宣布完成？
- 这个结果能否用业务记录复核？
- 如果 UI、Agent 和业务结果不一致，系统按什么顺序对账？
五、历史应该留下凭证，不是活按钮
聊天产品很容易把所有卡片原样塞进时间流。刚完成时看起来很完整，过一段时间却会变成风险。
旧按钮可能重复执行；账户权限可能变化；原选项已经下线；后续步骤也可能基于当时的参数产生了新结果。用户回看历史时，真正需要的不是一张永远可操作的旧表单，而是“当时做了什么、结果是什么、还能不能修改”。
智投内部方案把卡片分成三态：
active：当前可操作；collapsed：被中断，保留进度，可以续做；summary：已经完成，显示结果摘要。
这个方向的价值不在折叠样式，而在生命周期语义。完成后的 summary 至少应记录：
- 输入或选择摘要；
- 用户动作；
- 权威业务结果；
- 完成时间；
- 本次产生的记忆写入；
- 后续结果依赖了哪些输入；
- 是否允许重新编辑。
历史是决策凭证，不是旧界面仓库。如果允许修改，应显式触发 revisit，创建新的任务分支，并把依赖旧参数的后续推导标为失效。直接把旧 DOM 重新变成可编辑，会掩盖业务动作是否已经发生。
反方观点是，只读摘要会损失交互上下文，用户需要展开原表单才能理解当时如何决策。可以保留字段明细和变更记录，但默认应是只读凭证；“查看当时输入”和“再次执行动作”必须是两种不同权限。
六、恢复不是把页面重新画一遍
刷新、断网、中断和跨设备续做，本质上都在问同一个问题：哪一份状态可以作为恢复起点？
答案不应是浏览器缓存。缓存只能还原用户当时看见的页面，不能证明后台任务后来成功、失败，或已经被其他人处理。
可靠恢复需要服务端 checkpoint，至少记录任务标识、当前步骤、已完成子步骤、待用户动作、最近业务回执和依赖关系。重新打开时，客户端先读取权威任务状态，再决定显示：
- 待操作；
- 处理中；
- 可续做；
- 已完成；
- 失败待重试；
- 已失效或不可逆。
智投方案中的 interrupt、resume 和 revisit 分别对应三种不同动作：暂停并保留进度、从断点继续、回到旧步骤重新计算。它们不能混成一个“返回上一步”。
尤其要区分 UI 回退和业务回滚。筛选条件、分析结果可以重新计算；已经写入预算、外发内容或跨系统数据的动作，必须先判断业务是否可逆。界面退回上一张卡片，不会自动撤销已经发生的业务事实。
这也是 Agent UI 比普通表单更难的地方。普通页面通常由一个应用控制；Agent UI 还可能同时收到流式更新、模型重试、用户自然语言旁路输入，甚至多个 Agent 的写入。成熟状态管理库能提供工具，但不会替产品定义这些恢复语义。
七、记忆让交互变短，也可能让错误活得更久
记忆最直观的价值是预填和少问。
项目中已经有品牌名，表单可以直接带出；用户长期偏好某种报告格式，系统可以提供默认值；同一任务被中断，功能进度可以帮助续做。
但这些信息不能混成一个“记忆池”。智投方案区分了不同作用域：
- L2 保存项目共享事实；
- L3 保存“项目 × 功能模块”的配置、偏好和进度；
- L4 保存用户全局偏好，以及项目内覆盖。
如果把一次表单选择直接写成全局偏好，下一次任务可能在错误项目里自动套用。错误记忆比没有记忆更麻烦，因为它会持续预填、智能跳过，并把偏差带进后续推导。
因此，记忆进入 UI 至少要有四道约束：
- 显示来源：用户填写、历史记录、AI 推断还是 HITL 确认；
- 区分作用域：本次任务、当前项目、当前功能还是全局；
- 处理冲突：让用户选择仅当前项目覆盖、修改全局或保持原值；
- 支持纠错与撤回：AI 推断不能静默写入长期记忆。
有人会认为，这套状态机、依赖图和记忆审计对 MVP 太重。确实，不是第一版就要实现跨设备恢复和完整版本图。但最小版本仍不能省略三件事：pending / succeeded / failed、业务权威回执、重复提交保护。多步任务再增加 checkpoint，高风险写操作再增加审批和审计，跨会话使用时补上 summary 与依赖失效。
可以分阶段建设，不能把关键语义留空。
结尾：评审 A2UI，先问状态，再看界面
下一次评审动态 UI，不妨先放下组件稿，检查下面这些问题：
- 性能：是否分别记录首反馈、首控件、数据就绪和业务完成？
- 数据：每个选项由谁提供，如何处理权限、分页、竞态和失效？
- 提交：谁给出权威完成态，重复请求如何幂等？
- 历史：完成后留下什么凭证，旧按钮是否仍可执行？
- 恢复：刷新、中断、跨设备从哪个 checkpoint 继续？
- 修改：旧步骤变化后，哪些后续结果失效？
- 记忆：预填值来自哪里，写入哪个作用域，能否纠错和撤回？
- 版本：旧会话遇到已下线组件时如何安全降级？
A2UI 把“生成一块界面”变得更标准，但不会替产品定义完成、失败、恢复和记住的含义。
真正的交付分界线，不是卡片何时出现，而是 四份状态何时变成同一个可信结果。
证据边界：本文基于 A2UI 官方资料汇总与智投内部方案材料。智投相关内容只证明设计存在，不代表九类组件、断点续做、跨设备恢复或 L1–L4 写入已经全部上线。真实耗时、恢复率、重复提交率和状态不一致率仍待补充。
系列导航
- 上一篇：05 【A2UI】实践：模型负责理解，工程负责完成（
05-zhitou-a2ui-engineering） - 下一篇：07 【A2UI】Agent 组页面，低代码管资产（
07-a2ui-low-code） - 系列：A2UI