1. 对话窗口不是终点是过渡态你上一次在软件里「点按钮」是什么时候我猜你回想的是某个老系统——或者某个还没被 AI 改写的角落。现在打开任何一款 AI 产品第一眼几乎都是一个对话窗口一个输入框等你打字或者语音输入z。但我要说这个窗口不是终点它是过渡态。对话窗口是从「图形界面」走向「Agent 界面」路上的中转站。它先把入口从按钮换成了语言软件真正的重组还在后面——等 Agent 进场界面才会从「静态的框」变成「模型的运行时输出」。这篇我按一条主线讲软件交互范式从 C/S、B/S 走到 DUI每一次跃迁改写的不是界面好不好看而是软件怎么被组织。C/S 时代软件装在本机B/S 时代软件搬进浏览器加服务端DUI 时代软件变成「Agent 能力 知识 协作」。范式变了产品组织方式必须跟着变——这就是「Agent 为王」的含义。我把 Agent 拆成两条线先讲单个 Agent 的能力怎么一层层建起来LLM 原生 → RAG → MCP → Skills再讲多个 Agent 之间怎么协作A2A 协议。末了用一张订机票的单子把整条链路走通。读完你能拿走三样东西一张看交互范式的地图、一条组织 Agent 产品的能力栈、一次真实交互的全过程。不算多够你回去把手上产品的架构对着捋一遍。2. 范式演进三次跃迁三次软件重组先给结论C/S → B/S → DUI每次跃迁都不是换了个更漂亮的界面是软件的组织方式被重写了。界面只是最表层的那点变化深层的动作是「软件住到哪、由谁来更新、逻辑放哪一层」全变了。C/S 时代软件是装在本机上的程序。界面、逻辑、数据全在一台机器里更新软件要重新装一遍部署一个客户端要跑到每台电脑前。交互对象是鼠标键盘软件的组织单位是「程序文件」。B/S 时代软件搬进了浏览器加服务端。前端只管展示、后端管逻辑、数据库管数据三层一分一次开发处处访问更新只需改服务器。交互对象变成浏览器软件的组织单位变成「网页 服务」。这是第一次把「软件从安装变成访问」的跃迁——那代 Web 工程师其实是在重构软件的存放方式。DUI 时代交互对象变成对话窗口软件的组织单位再变一次从「界面 逻辑 数据」变成「Agent 能力 知识 协作」。用户不再一层层点进菜单而是用一句话表达意图执行权交给 Agent由它决定调哪个工具、查哪份知识、要不要喊别的 Agent 帮忙。三次跃迁有个共同方向用户离「操作」越来越远离「意图」越来越近。C/S 时代你要记住软件把功能藏在哪B/S 时代你要学会在页面层级里找功能DUI 时代你只需要说出要什么。这不是「界面更好用了」是「软件的自主性在上升」——每一次机器都多承担了一层「怎么把活干完」。3. DUI 的边界对话擅长什么不擅长什么这里得说句可能有人不同意的话DUI 不是把 GUI 全换成对话框。把整个产品塞进一个聊天框是这两年最常见的误读也是很多 AI 产品难用的原因。对话窗口擅长的是意图表达。一句话直达目标不用理解软件的分类体系——查「明天北京到上海的航班」不用先搞清机票入口在哪层菜单。这是 CUI 的强项信息获取效率高工具适应人而不是人适应工具。对话窗口不擅长的是精细操作和复杂信息展示。订机票要选日期、比舱位、填乘客、看退改规则靠一句句话逼问出来体验是灾难级的填表单要地址、发票抬头、身份证号纯对话能把人磨疯。还有榜单、报表、多列对比这类信息——对话一维线性输出展现效率极低。这个差别的本质是信息组织维度GUI 用二维空间页面、层级、并排组织信息展现效率高、获取效率低——功能藏得越深越难找CUI 用一维时间对话流组织信息获取效率高、展现效率低——说到就到但摆不开。落到生活里很好感知支付宝关免密支付大概要十几次点击改成对话两句就够反过来福布斯富豪榜前十名用眼睛扫一眼比让语音念一遍快得多。所以 DUI 和 GUI 不是替代关系是互补关系。真正好用的对话式产品都在聊天线程里混排卡片、按钮、图表——输入用对话选择用界面。一句话对话管意图界面管操作。对话窗口是入口动态生成的界面是操作台两者合起来才是一个完整的产品。4. 产品怎么组织Agent 为王 Agent这一章是整篇的核心先把立场亮出来Agent 为王不是口号。这句可能有人觉得是营销话术——毕竟每个时代都有人喊「XX 为王」。我的依据是结构性的DUI 时代软件的主语变了。GUI 时代主语是界面用户面对的是按钮和页面DUI 时代主语是 Agent用户面对的是一个能理解意图、能调工具、能自己跑完一整条任务的实体。界面上那个对话窗口只是它的脸。Agent 凭什么当产品内核因为它有三个 GUI 时代的软件没有的属性有状态记得上下文不用每次从头交代、有记忆跨会话记住偏好和习惯、能调用工具不只输出文字还能真去干活。这三个属性凑齐Agent 就不再是「套了一层对话的搜索框」而是产品里真正干活的单元。那产品怎么组织我拆成两条线单 Agent 能力体系构建再到多 Agent 交互设计。单 Agent 能力体系LLM 原生 → RAG → MCP → Skills单 Agent 的能力是一层层加出来的这条线我压成一句话LLM 原生 → RAG → MCP → Skills。底子是 LLM 原生能力——对话、推理、生成只有这个的时候它是聊天机器人什么活都干不利索。加 RAG把外部知识拉进上下文它才能回答「我们公司的报销政策是什么」。加 MCP把工具接进来它才能真去查库存、订机票、调接口——MCP 解决的是「Agent 调用工具」这一层一个标准一套协议模型和应用不用各写各的适配。加 Skills把多步流程和领域知识封装成可复用的动作它才能稳定执行「新员工入职」这种一串步骤的活。多 Agent 交互A2A 协议单 Agent 再强也有边界。能力越大越需要分工——你不可能让一个 Agent 既懂财务又懂物流还懂客服于是有了第二条线多 Agent 交互设计。这一层的代表协议是 A2AAgent2Agent。A2A 是 Google 在 2025 年 4 月发布的开放标准同年 6 月 23 日捐给了 Linux Foundation。它解决的是「Agent 和 Agent 怎么协作」。机制上靠 Agent Card 和 task 生命周期两件套撑着Agent Card 让 Agent 像网页一样在/.well-known/agent-card.json上公开自己的能力清单别的 Agent 先读卡片、再发起任务任务走有状态的生命周期——submitted → working → completed/failed/canceled中途需要人确认时进input-required状态。这套机制把 Agent 间协作里最难的「动态编排」标准化了。MCP 和 A2A 的边界我一句话给你划清MCP 管内部Agent 调工具A2A 管外部Agent 找 Agent。一个 Agent 对内用 MCP 完成自己的工作对外用 A2A 把干不了的活交给别的 Agent。两者不是竞争是一内一外把「能力」和「协作」接起来。把这套结构放回你熟悉的分层里对比更直观传统软件分层Agent 新结构对应什么前端对话窗口 动态生成的界面用户的入口和操作台后端AgentLLM 原生 Skills 封装产品内核意图的拆解与执行数据库RAG 知识库事实与记忆的来源第三方系统MCP 工具接入能力的外部扩展微服务调用A2A Agent 协作系统间的分工与委托这套结构不是我发明的我手上就有现成的样本——你天天用的 coding agent CLI 就是 Agent 的雏形。Claude Code 里MCP 接外部工具、Skills 封装多步流程、subagents 做上下文隔离和并行扇出。我早先在写 coding agent CLI 系列时讲过prompt → loop → harness → graph 的演进里人从操作者变成管控者——和这里 DUI 的演进是同一个方向人往后退机器往前顶。今天这套结构只是从开发工具扩散到了所有软件。先卖个关子Agent 为王的软件一次真实交互到底怎么跑起来下一章我用一张「订明早去上海的机票」的单子给你从头走通一遍。5. 一次交互走通 Agent订明早去上海的机票还是那句话对话管意图界面管操作。我们用一次真实交互把它走通。假设你是常出差的销售明天一早要去上海见客户你对着产品说了一句「订明早去上海的机票越早越好顺便帮我看看那边天气。」第一跳在入口。这句话落进对话窗口主 Agent 先做意图拆解目的地上海、日期明天早上、偏好越早越好、附带查天气。它没有急着调航班接口而是先把「这单活需要什么」列清楚——这步就是拆意图和我之前在 spec 系列里说的「先规格后实现」是同一件事只不过这次规格拆在运行时。第二跳是 MCP 接工具。主 Agent 发现「查航班」和「支付」要调外部系统于是经 MCP 协议调用航司接口。航班列表回来了但它没直接甩给你一张文字清单——它知道「选日期、比舱位、填乘客」这种精细操作靠对话逼问是灾难于是动态生成了一张选航班界面明天早上的航班按时间排好舱位和价格并排摆着你点两下就选中。第三跳是 A2A 协作。查天气不在主 Agent 的能力范围内——它读了天气 Agent 的 Agent Card确认对方能干这活发了一个 task 过去。天气 Agent 干活、回传结果主 Agent 把它并进展示。这里你没有参与Agent 之间自己完成了分工。这是多 Agent 协作里最关键的一跳主 Agent 不是万能的但它知道谁能干知道怎么把活派出去。第四跳是确认与支付。你在动态界面上确认了航班和乘客支付经 MCP 走支付通道锁价、扣款、出票。整单走完主 Agent 生成一张确认页票号、行程、登机口变更提醒、上海明天的天气一并列好。你从头到尾只说了两句话、点了几个按钮剩下全是 Agent 和它手下的工具、伙伴在跑。这单活最值得注意的不是「AI 会说话了」而是产品被组织成了什么一个主 Agent内核、一堆 MCP 接进来的能力航司、支付、一个 A2A 叫来的伙伴天气、一个按需生成的界面选航班。没有传统的「机票页面」「支付页面」功能全部变成了 Agent 随手能调用的能力。这就是 Agent 的产品形态。6. 对产品设计者的含义设计重心从交互设计转向意图设计前面都是架构这一章讲人。产品要这么组织设计者的活也跟着变。先放判断设计重心从交互设计转向意图设计。这句可能有人不同意——「界面都还在怎么就不做交互设计了」我的回答是交互设计还在但它从主角变成了配角。GUI 时代设计的主战场是交互按钮放哪、菜单分几层、跳转怎么走、表单怎么填。用户靠界面理解软件界面就是软件本身。DUI 时代用户靠语言理解软件主战场变成了意图。意图设计要回答的是一组新问题用户能表达什么意图、意图怎么被拆解、拆到哪一步要停下来问人、边界在哪。这是比「画按钮」更难的设计问题——画按钮定义的是用户能看见的路意图设计定义的是用户能说出口的愿望而后者没有穷尽。设计意图最核心的是管住「Agent 自作主张」。自主性越高越需要设计可见性、控制权和信任这三样东西。Agent 在后台 7×24 地跑时用户凭什么安心我的答案就一条让用户随时知道「Agent 正在干什么、为什么这么干、能不能叫停」。拆解步骤要不要显示、调了哪个工具要不要提示、关键动作尤其是花钱、发消息这类不可逆操作要不要确认——这些是 DUI 时代的设计决策比 GUI 时代的「弹窗要不要加」重得多。Google I/O 2026 把这种交互范式叫 delegate-and-execute用户是委托人Agent 是执行者设计要做的就是把「委托-执行」这条链路的透明度校准好。再往深一层界面本身也在变界面正在成为模型的运行时输出。GUI 时代的界面是写死的页面DUI 时代界面可以是 Agent 现场生成的——你刚看到的选航班表单、确认页都是运行时渲染出来的。2026 年这一批协议正在把这件事标准化A2UI 和 AG-UI 管「Agent 怎么把界面递给前端」一个管内容格式、一个管传输通道MCP 生态里的 MCP-UI、以及 MUP 这类方案管「怎么把交互组件嵌进对话流」。软件正在变成「一次性」的——每个用户、每个场景界面都可能不一样。这对团队结构有实打实的影响。前端从「设计系统 → 组件 → 页面」变成「设计系统 → 可被 Agent 调用的组件 → 运行时动态渲染」新增的角色像 Agent UI 架构师、意图设计师是原来没有的。我判断未来三到五年产品团队里最稀缺的不是「画页面的人」而是「想清楚 Agent 能替用户干什么、该替用户干什么」的人。7. 结论范式已变产品组织要跟着变回到开头那句话对话窗口不是终点是过渡态。终点是 Agent 成为产品内核界面退化为它的运行时输出产品从「界面 逻辑 数据」重组为「Agent 能力 知识 协作」。这个重组和二十多年前 C/S 到 B/S 那次一样彻底——只不过那次改的是软件住哪这次改的是软件由谁主导。「Agent 为王」不是口号是 DUI 时代软件组织方式的必然形态。你的产品现在是什么形态不重要重要的是它能不能拆成 Agent 结构内核用单 Agent 能力体系一层层喂大能力用 MCP 接进来边界用 A2A 交给别的 Agent界面留给运行时生成。范式已经变了产品组织要跟着变——这个判断本身值得你认同一次。Agent的应用范式一个方向是嵌入的已有的流程按需调用和集成但这只是一个过渡一个方向是Agent主导的统一入口组织数据、界面等多种表现形式现有的软件都将变成Agent的资源这是一个趋势。如果你手上正好有一个被「要不要改成对话入口」卡住的产品我想问问你你现在的产品交互入口是 GUI 还是已经换成对话窗口了换到哪一步了卡在哪了评论区聊聊说不定你踩的坑就是下一篇文章。我后面还会接着聊 Agent 的实操选型把手上的产品拆成 Agent 结构时MCP 和 A2A 到底怎么选、什么时候该上多 Agent、RAG 和 Skills 的边界怎么划。想知道 DUI 模式下 MCP 怎么接、A2A 什么时候用的评论区告诉我我按大家最关心的顺序写。【个人观点仅供参考~】