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 交互设计。 这一层的代表协议是 A2A（Agent2Agent）。

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+ 新结构	对应什么
前端	对话窗口 + 动态生成的界面	用户的入口和操作台
后端	Agent（LLM 原生 + 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 什么时候用的，评论区告诉我，我按大家最关心的顺序写。

 

 

【个人观点，仅供参考~】