当GUI遇见Agent协作，用户体验设计正在经历一场革命性变革。从精确定义的按钮操作到自然语言的模糊意图表达，从静态界面模板到动态生成的场景化组件，这场范式转移正在重塑产品设计的底层逻辑。本文通过订票场景的深度对比，揭示AI时代下输入输出机制的根本性变化，以及设计师如何从页面制作者转型为意图响应规则的设计师。

从GUI到Agent协作，用户体验设计正经历一场范式转移。本系列分享将从八个核心维度，系统对比传统纯GUI交互与“自然语言+Agent协作”模式的差异，并探讨AI时代产品设计的新原则、新工具与新心智模型。

纯GUI时代与Agent协作时代，信息在两个方向上流动方式的根本差异：一端是用户向系统下达的“指令”，另一端是系统向用户呈现的“反馈”。

这种差异，本质上是从“精确指令↔预定义反馈”的刚性信道，升级为“模糊意图↔动态生成反馈”的柔性对话。

输入/输出性质的根本不同

输入：从“操作翻译官”到“意图表达者”

在纯GUI模式下，用户是操作的翻译官。你需要把一个完整的意图（“我想看明天下午的《给阿嬷的情书》”）拆解成一系列离散操作：

点击“电影”tab → 找到《给阿嬷的情书》的入口 → 点击进入 → 点击“选座购票”按钮 → 选择“明天” → 筛选“下午” → 滑动列表找到目标场次 → 点击“选座”…… 每一步都必须精准，否则系统就会“懵”在原地。

这种输入的典型特征：

• 只能使用系统定义好的语言：按钮、菜单、手势，每个都有固定语义。
• 无法携带额外上下文：你无法在点击“支付”时，告诉系统“如果优惠券明天过期，就先用这张”。
• 容错率极低：按错了按钮，系统立刻执行，理解不了你的“本意”。

而在Agent协作模式下，输入变成了意图的直接投射。你只需说：“帮我订两张明天下午的《给阿嬷的情书》，要中间靠后的座位，如果IMAX有连座就优先IMAX，否则普通厅也行。” 这句话同时包含了：

• 核心指令（订票）
• 参数（影片、时间、人数）
• 偏好（中间靠后）
• 条件分支（IMAX连座优先，否则普通厅）

Agent接收的不是一个“操作”，而是一个带约束的任务目标。它先理解，再规划，遇到不明确的点会主动提问：“明天下午有两个IMAX场次，14:30和16:10，您更倾向哪个？”

这种粗粒度、模糊但语义丰富的输入方式，让用户从“如何让系统明白我”的认知负担中解放出来，回归到“我自己想要什么”的纯粹表达。

输出：从“预定义的公告板”到“动态生成的任务看板”

纯GUI的输出，是一个设计师穷举出的“模版”。为了覆盖各种用户、各种状态，设计师会创建大量页面和状态，然后把它们打包成一个固定的App。

• 功能导向的：所有功能按钮都摆在界面上，不论你当前是否需要。用户在海量信息中自行寻找下一步该点哪里。
• 静态的：即使数据变了，界面结构不变。你刷新一次页面，看到的还是那些菜单、那些按钮，只是列表里的商品换了。
• 没有“语境智慧”：你在订单支付页面停留了5分钟，系统不会主动弹出一个客服对话框问“需要帮助吗？”，除非你点击“帮助”按钮。

而Agent协作的输出，是一个动态生成的“任务看板”。它只展示与当前任务直接相关的内容，并且Agent会根据对话的进展，实时拼装不同的界面组件。

这正是之前研究的A2UI所支持的“生成式UI”：Agent不是返回一个完整的“页面”，而是流式地发出一个或多个组件指令。比如在你确认场次后，Agent可能只返回一个SeatMap组件和一个简短的提示Text组件，其他无关的导航栏、推广位、底部Tab栏在这个视图中都消失了——因为当前任务不需要它们。

这种动态输出有三个关键优势，直接对应我之前提到的“可省略”逻辑：

1. 信息层级随任务深度自然浮现：初期提供概览（场次卡片列表），决策点提供沉浸式工具（座位图），最终提供明确的操作出口（支付确认卡片）。信息从不超载。
2. 操作入口与信息合一：传统的“订单详情”和“取消订单”按钮可能在不同的地方。而Agent可以将订单详情卡片和一个“取消本次预订”的按钮放在一起，同时用文字说明“取消后座位将立即释放”。信息和行动一体化呈现。
3. 错误处理从“告知”变为“引导”：如果你选的两个座位中间被人抢先了一步，传统界面可能只弹出一个“座位已被选”的警告框，用户需要自己重新找。Agent会说：“抱歉，刚才您选的K8、K9中间有一个座位已被占。我为您找到了另一个中间靠后的连续座位L7、L8，要换成这个吗？” 输出不再只是一个结果通知，而是一个后续行动的邀请。

输入与输出的融合：一个“订票”的例子

举例一个完整流程来串联输入输出性质的变化。

用户输入：“帮我订明天下午的《给阿嬷的情书》，两张，位置好一点。”

这句话是模糊意图。Agent收到后，内部发生了一系列推理和数据查询，然后它生成了第一个动态输出——一个场次选择界面，包含三个卡片，每个卡片上明确标注了“14:30 IMAX厅 | 票价69.9 | 余座47”，并附有按钮“选择此场”。

这个输出不是预定义的，Agent在生成它时做了以下事情：

• 它自动过滤了上午和晚上的场次（因为用户说了“下午”）。
• 它识别出IMAX厅可能更符合“位置好一点”的隐含诉求，但依然提供了其他选项。
• 它没有展示复杂的影院信息、影片介绍，因为当前任务窗口是“选场次”。

用户点击第二个卡片（14:30 IMAX厅），这是一个精确操作，但在这个协作上下文中，它的语义是“确认Agent的提议”。

Agent收到这个精确操作事件后，生成第二个动态输出：一个被高亮推荐区域的SeatMap组件，以及一个实时更新的订单摘要栏。它通过数据绑定把已售座位、价格梯度这些后台信息注入座位图，让用户一目了然。

用户拖动地图查看不同区域，这是非结构化操作，建议保留。然后用户点击K8、K9，客户端将seats_changed事件发回Agent。Agent实时更新摘要栏：“已选K8、K9 | 合计139.8元”，并发现在支付前需要最终确认，于是追加了一个Button组件，variant: “primary”,action: { name: “confirm_payment”, requiresConfirmation: true }。

点击“确认支付”后，客户端弹出二次确认弹窗。用户点击“确定”，整个流程结束，Agent生成最后一个输出：包含取票码和二维码的Card组件，并附带一句富有人情味的Text：“祝您观影愉快！”

对设计师的启示：从“制作静态页面”到“设计动态意图响应”

输入输出性质的改变，意味着设计产物的形态也变了。以前你的核心产出物是一个个具体的界面。而现在，你需要设计的是一套“输入理解规则”和“输出生成逻辑”：

• 定义Agent能理解的意图集合：你的产品支持哪些高频任务？（订票、改签、咨询），每个任务的必要参数和可选偏好是什么？这决定了Agent的输入解析能力。
• 设计“输出组件序列”的剧本：当用户说“我想退票”时，Agent应该按怎样的顺序输出哪些组件？先输出订单列表供选择，再输出退款原因选择器，最后输出退款金额确认卡片。这就是一个输出剧本。
• 为每个决策节点设计最佳的“生成式UI”：在哪些环节用卡片列表，哪些用地图，哪些用表单？这与我们之前讨论的“交互过滤清单”直接衔接，是输入输出性质在你组件库设计中的具体落点。

最终，输入/输出性质的进化，让产品从一个“被浏览、被操作的静态工具”，变成了一个“能倾听、能思考、能根据对话实时组装的动态服务体”。而你对这一切的掌控，不再是对像素的精确摆放，而是对意图流转和界面拼装的规则设计。