假设你对投放 Agent 说：“帮我找出最近消耗下降的计划，看看要不要调整预算。”
这句话很适合放进聊天框。它包含目标，但没有限定账户、时间范围、判断口径，也没有说明哪些计划可以调整。Agent 可以继续追问，但如果整个任务都靠聊天完成，接下来可能变成：
“看哪个账户？”
“最近是几天？”
“这 8 个计划要比较哪些指标？”
“预算从多少调到多少？”
“确认全部执行吗？”
用户最终仍要处理账户、日期、计划、指标、预算和影响范围。区别只是，本来可以直接看见和操作的对象，被拆成了多轮文字。
我的判断是：Chat 适合表达模糊目标和解释原因，却不适合承担精确录入、选项比较与过程控制，也不适合长期沉淀结果。聊天可以是 Agent 的入口，但不该默认成为整套产品。
为什么 Agent 产品都喜欢从聊天开始
聊天有四个很难替代的优势。
第一，用户可以从目标开始，不必先理解产品导航。面对一个低频任务，“帮我看看为什么消耗下降”通常比先找报表、选账户、配筛选条件更自然。
第二，聊天能容纳不完整的背景。用户可以先说大概目标，再补一句“新品不算”“只看本周”“先别改预算”。这些例外很难在任务刚开始时全部预设成字段。
第三，对话适合协商。Agent 可以追问缺失信息，用户也可以修正系统的理解。双方不必在第一轮就把需求描述完整。
第四，聊天适合解释。系统给出建议后，用户可以继续问“为什么是这几个计划”“如果不调整会怎样”。表单能收集答案，却不擅长解释答案。
所以问题不是“要不要聊天”，而是聊天应该在哪些阶段出现。
聊天的局限，不是模型不够聪明
很多团队把 Chat 的问题归结为模型能力：理解再准一点、记忆再长一点、追问再聪明一点，体验就会变好。
模型进步当然能减少误解，但解决不了消息流本身的结构。
一个复杂任务通常包含四类东西：
- 对象：账户、计划、素材、规则；
- 字段：日期、预算、状态、标签；
- 状态：未开始、处理中、待确认、成功、失败；
- 动作：选择、修改、暂停、重试、提交。
而聊天的基本结构只有一个：按时间不断追加消息。
当任务简单时，两种结构没有冲突。用户问一句，Agent 回一句，事情结束。任务一旦变成多对象、多步骤、可中断的工作流，线性消息就开始吃力。
空白输入框把发现成本交给用户
“你可以问我任何问题”看起来很自由，实际要求用户先知道系统有什么能力、哪些参数有效、怎样表达才不会被误解。
如果可选账户只有 12 个，展示账户列表比让用户回忆名称更省力；如果预算有上下限，直接显示范围和校验，比用户输错后再收到一条报错更有效。
这里的原则是：能展示合法选项时，就直接展示合法选项，不要要求用户凭记忆描述。
精确输入不适合反复确认
日期、金额、百分比、账户范围和多选项都需要精确。聊天可以接收这些内容，却很难同时展示格式、默认值、联动关系和错误位置。
一句“预算改成 5000”还可能继续追问：日预算还是总预算？作用于哪个计划？何时生效？是否超过规则上限？
表单不是比语言更“高级”，只是它能把约束放在输入旁边，让用户一次完成。
比较和筛选需要空间
用户比较 8 个计划时，需要让同类指标对齐，切换排序和筛选，并保留当前选择。把这些信息改写成几段自然语言，信息没有减少，空间关系却消失了。
对话适合解释“为什么推荐 A”，表格、图表和 Diff 更适合回答“A 与 B 到底差在哪”。
长任务需要控制器
一个运行十分钟的任务，如果只在消息流里不断追加“正在处理”，用户很难判断它到了哪一步、能否暂停、哪里失败、重试会不会重复执行。
长任务需要的不是更多消息，而是一块稳定的过程界面：真实进度、当前步骤、局部结果，以及暂停、取消、续做和重试。
聊天历史不是业务工作台
消息按时间排列，业务却按项目、任务、对象和状态组织。
三天后回来看，用户通常想知道“任务完成了吗”“我当时选了什么”“结果写到哪里”，而不是从几十条消息中复盘当时的问答过程。
完成后的交互应该沉淀为结果摘要和决策凭证。仍在进行的任务要有续做入口。需要长期关注的对象，则应进入看板或任务中心。
一个 Agent 任务，需要的不只是一块对话区
更合理的设计，是让不同界面对象分别承担自己擅长的工作。
对话：表达目标和处理不确定性
当用户还说不清目标、需要补充背景、希望理解原因，继续对话。此时产品的任务是帮助用户把问题说清楚，而不是急着展示一堆字段。
表单、选择器和步骤页：完成精确交互
当任务已经明确，系统应把合法选项、必填项、默认值和约束直接摆出来。需要逐步收集时，用步骤页控制认知负担；需要比较时，让相同字段对齐。
控制器：让运行过程可见、可干预
只要任务可能等待、失败或被打断，就需要显示权威状态，并给用户明确的暂停、续做、取消和重试入口。
结果界面：承载比较、确认和沉淀
结果不是聊天中的最后一段话。数据量较大时，它可能是一张表、一组图、一个 Diff，或者一张能展开明细的摘要卡。需要持续观察时，它应该进入 Dashboard；需要追溯时，它应该进入 History。
这也是 A2UI 对产品设计的直接价值：Agent 不只返回文字，而是根据任务阶段描述一块可操作的界面，再由客户端用可信组件渲染。协议细节不是本篇重点，重要的是Agent 选择表达形式，而产品经理决定选择规则。
更合理的路径：对话发起，界面完成
把前面的投放任务重新走一遍：
- 用户在对话中提出“找出消耗下降的计划”。
- Agent 追问真正缺失的判断口径，而不是逐个追问所有字段。
- 系统展示账户、日期和计划筛选器，让用户直接选择。
- 结果界面并排呈现关键指标和异常原因。
- 用户点选要调整的计划，填写预算，查看影响范围。
- 高风险写操作进入明确的确认界面。
- 完成后生成结果摘要，并进入任务历史。
对话没有消失。它仍然负责解释“为什么推荐这些计划”，也允许用户随时补一句“新品先排除”。但精确操作不再被翻译成一连串问答。
这条路径可以概括为：
对话表达目标 → 结构化界面完成操作 → 对话解释与纠偏 → 结果界面保存状态
统一的是任务，不是界面形态。
输入框应该一直存在吗
我的答案是：可以常驻，但它是旁路，不是拥有最高优先级的主流程。
智投的内部方案提供了一个可参考的设计。结构化卡片进行中，底部输入框仍保持可用。用户的新输入通过 freeform 回到 Skill，再区分三种意图：
augment：补充当前任务，例如“把物流投诉也算进去”；override：覆盖当前选择，例如“算了，全部选中”；new：开启新任务，例如“先看看竞品被讨论的情况”。
前两类更新当前卡片。第三类才打断当前流程，并把未完成任务折叠保存。意图不清楚时，系统先询问用户，不擅自打断。
这套方案还把卡片分为三种状态：
active：当前可操作；collapsed：已中断但可以续做；summary：任务完成后的结果摘要。
这些是内部设计资料能够证实的方案，现有材料不足以证明它们已经全部上线或产生了量化收益。但它揭示了混合交互的一个关键：输入框、卡片和任务状态必须指向同一个任务对象。
如果用户在聊天里说“全部选中”，卡片却仍保留旧选择；或者聊天已经开启新任务，旧卡片仍显示进行中，产品就出现了两套互相冲突的状态。此时问题不在界面好不好看，而在用户已经不知道哪个结果算数。
反方观点：一个聊天入口不是更简单吗
这个观点有一半成立。
统一入口确实能减少导航学习。对于低频任务、开放探索，以及只需一句可验证结论的后台任务，Chat 甚至可以从头用到尾。有些任务根本不需要额外界面：Agent 完成后发一条结果通知就够了。
但入口统一不等于过程统一。
用户说出目标之后，如果系统已经知道合法选项、业务约束和当前状态，仍然要求用户继续用文字复述，只是把产品本应承担的组织工作转嫁给用户。
另一种担忧是：表单、控制器和结果页会让 Agent 产品重新变回复杂软件。
这也提醒我们，不要为了展示“动态 UI”而生成界面。判断标准不是有没有卡片，而是这块界面是否减少了理解或操作成本。一句回答能结束的任务，就不要生成五步 Wizard；三个固定选项能解决的问题，也不必让 Agent 现场设计一套页面。
产品经理应该先判断用户缺什么
设计 Agent 任务时，可以先问四个问题：
- 用户缺的是目标表达，还是合法选项？前者用对话，后者用表单或选择器。
- 用户缺的是解释，还是比较？前者用对话，后者用表格、图表或 Diff。
- 任务会不会等待、失败或中断？会，就需要过程状态和控制器。
- 结果要不要持续查看和追溯？要，就需要稳定的结果界面和历史对象。
再补一个退出条件：如果任务可以完全委托，用户只需要一个可验证结果，那就不必为了 A2UI 强行增加界面。
Agent 产品的设计起点不该是“首页放一个多大的聊天框”，而应该是：用户如何表达目标，系统如何收集精确信息，任务如何被控制，结果如何被验证和保存。
聊天框完成了第一步。后面几步，才决定 Agent 能不能真正进入工作。
系列导航
上一篇：【A2UI】Agent 如何“说界面”（02-generative-ui-paths）
下一篇：【A2UI】GUI 负责看清，CLI 负责做快（04-gui-vs-cli）