Linear、PostHog、Attio 这几家以设计见长的 SaaS 产品，都曾把首页悄悄换成聊天框。OpenUI 作者指出这一现象后，相关帖子获得超过一百万次浏览，也招来了强烈反对，几家公司的 CEO 甚至不得不公开解释自己的决定。
用户的厌烦是真实的，但文章认为，问题不在 Agent 本身，而在于聊天框这种交付方式。产品真正承认的是：与预先定义好的页面和操作相比，Agentic Loop 能覆盖更开放的需求；只是今天的界面还没有跟上这种能力。
#Agentic Loop 打破预设流程的上限
传统软件后端相对刚性：每个动作对应一个 API，每个视图对应一条写好的查询，每套工作流都由产品团队提前设计。用户需要一种新的数据视图，就要等开发者先把它做出来。
Agentic Loop 可以同时面对数据、API 和上下文，自行组合多个步骤。过去需要五次点击、三个筛选条件和一个保存视图才能完成的任务，现在有机会由 Agent 一次推理完成。用户能做什么，不再完全取决于产品团队提前发布了什么，而更多取决于 Agent 能否理解并执行需求。
这正是聊天框流行的原因：文本输入足够通用，可以暂时承载那些无法被固定按钮和菜单穷举的意图。
#聊天是能力入口，也是体验妥协
纯聊天的代价同样明显。它牺牲了传统界面的视觉密度、空间关系和直接操作。让用户通过一轮轮文字描述来理解复杂状态，就像把 Google Maps 换成一个只在电话里口述转向的人：信息还在，体验却退化了。
因此，反感聊天框并不等于拒绝 Agent。用户拒绝的是把所有软件交互都压缩成“输入文字、等待回复”的单一模式。Agent 的推理能力值得保留，但需要一种比 Chatbar 更合适的界面。
#Agent 界面的四个阶段
文章把 Agentic Interface 的演进划分为四个阶段。
第一阶段是纯文本。Agent 最多返回 Markdown，用户得到的往往是一整面文字。这仍是多数 Agent 产品今天所处的位置。
第二阶段是聊天中的 Generative UI。对话仍是主容器，但 Agent 的回复已经变成表单、图表、表格或其他可交互组件。信息不再只靠段落表达，用户也可以直接操作结果。
内联 Generative UI 在聊天中生成带图片和控件的结构化卡片
第三阶段是把聊天变成构建器。用户提出“创建一个第三季度销售管线看板”，Agent 生成的不是一次性回答，而是一个可以持续使用的视图。产物离开当前对话后仍然存在。
第四阶段则把 Agentic SDK 直接嵌入产品。Agent 根据每个用户的角色、数据和工作方式组合界面，软件开始围绕用户自动塑形。此时聊天退居为逃生通道：现有界面不能满足需求时才回到文字，日常操作则直接发生在生成的 UI 上。
#空白输入框重新制造了冷启动
不过，这四个阶段都有一个共同陷阱：用户打开产品，首先面对的仍可能是一只空白输入框。没有上下文、没有引导，只有闪烁的光标，等待用户自己知道该问什么。
这比传统 SaaS 的冷启动问题更严重。传统产品至少还有默认仪表盘、引导流程和模板；全聊天界面往往把这些成熟的产品经验全部扔掉，再把理解产品能力的责任交还给用户。
Generative UI 可以反过来解决这个问题。Agent 已经掌握用户的角色、数据和使用规律，就不该等到 Prompt 出现后才行动。它可以主动呈现需要处理的通知、相似角色常用的视图、上下文提示，以及根据使用行为持续调整的仪表盘。第一天看到的不是空白，而是一个已经有用的起点。
#从生成文本到生成 UI 操作
要让这种体验成为真正的软件，而不是偶尔惊艳的演示，需要满足三个条件：可复现、一致和低延迟。相同意图应产生足够可预测的界面；生成结果要遵守产品自己的设计系统；整个过程还必须快到像原生应用，而不是等待模型临时画页面。
这也要求 LLM 的输出抽象超越文本。模型需要生成结构化的 UI 操作，让前端能够稳定地解释、渲染和更新，而不是每次都接收一段任意格式的内容。
Chatbar 让产品先接入了开放式意图，但它只是 Agentic Software 的入口。真正的方向，是把 Agent 的推理能力重新放回可视、可操作、可持续的界面中，让软件既拥有开放性，也保留传统 UI 最擅长的清晰与控制感。