今天打开任何一款软件，我们几乎不会对它的形态产生疑问。

按钮应该可以点，数据应该放在表格里，复杂功能藏在菜单下面，参数需要填进输入框，重要信息最好做成 Dashboard。过去几十年，软件行业已经把这一整套东西打磨得如此成熟，以至于我们很容易产生一种错觉：软件本来就应该长成这样。

但如果把界面拿掉，软件内部其实并不存在“按钮”这种东西。一个经营系统真正拥有的，是查询订单、读取商品数据、修改库存、创建活动这样的能力；一个音乐软件真正拥有的，是搜索、播放、收藏、建立歌单；一个企业系统背后，则是大量数据、规则、权限和函数。

之所以后来出现按钮、菜单、窗口和表格，是因为这些机器能力最终需要被人使用。

人不应该为了查询销售额学习数据库语言，也不应该为了修改库存写一个函数调用。于是开发者花了几十年时间，建立起一层越来越复杂、也越来越成熟的翻译系统：把程序能力翻译成人能理解的信息，把参数变成表单，把函数变成按钮，再把所有东西组织进一个叫作“应用程序”的空间。

换句话说，我们今天熟悉的软件形态，并不完全是由计算机本身决定的，它很大程度上是由人的认知方式和操作方式决定的。

也正因为如此，AI Agent 的出现才值得重新思考。它带来的真正变化，也许并不是聊天框变聪明了，不只是软件多了一个 AI 按钮，甚至不只是“AI 可以帮人使用软件”。

更值得注意的是：软件的操作者，开始不再只能是人。

---

软件一直在服务人，但机器其实早就在操作软件

这里首先需要避免一个容易说过头的判断。

机器操作软件并不是最近才发生的事情。脚本、自动化程序、API、RPA、定时任务、CI/CD，都已经存在很多年。互联网上绝大多数后台系统每天都在被其他程序调用。从这个意义上说，“过去软件由人操作，现在开始由机器操作”显然不准确。

真正发生变化的，是机器参与任务的方式。传统自动化通常要求人在开始之前把路径想清楚。几点执行、调用哪个接口、先做什么再做什么、遇到某种返回值该进入哪个分支，这些步骤需要事先写进程序。机器的执行能力很强，但它执行的是一个提前定义好的过程。

Agent 不太一样。用户告诉它的可以只是一个目标，比如：“帮我看看这周哪些商品的表现异常。”“把下周去东京的行程安排一下。”“检查一下最近的合同，有没有需要我注意的风险。”

接下来用什么数据、调用什么工具、先查什么再查什么，甚至中途发现信息不够以后是否继续寻找其他来源，这些步骤开始可以在任务进行过程中动态决定。

OpenAI 在 2025 年推出 Responses API 时，就把 Agent 描述为能够“代表用户独立完成任务”的系统，并同时提供 Web Search、File Search、Computer Use 等工具。到了 2026 年，Responses API 又增加了 Shell 和托管计算机环境，让 Agent 可以处理文件、运行程序、向 API 请求数据，再把执行结果带回后续步骤。

这之间的区别看似只是自动化程度不同，实际上却改变了软件里的角色关系。

以前往往是：

人决定目标
→ 人规划流程
→ 程序按照流程执行

现在开始出现另一种可能：

人决定目标
→ Agent 理解目标并规划
→ Agent 调用软件能力
→ 根据执行结果继续调整

机器过去也会执行任务，但现在，它开始有机会成为一个能够理解目标、选择能力、组织步骤的通用操作层。

这是这轮 AI 对软件真正值得关注的地方。

---

Computer Use 是一个很奇怪、也很重要的过渡阶段

问题在于，我们今天拥有的绝大多数软件并不是为 Agent 建造的。

它们诞生的时候，设计者考虑的是坐在电脑前的人：人能看见什么，人容易理解什么，鼠标应该点在哪里，哪个按钮需要突出显示，复杂功能怎样藏进菜单才不会让用户迷失。

所以当 Agent 第一次进入这个世界时，最现实的办法并不是要求全世界的软件重新开发，而是先学会使用人的界面。

2025 年，OpenAI 发布 Computer-Using Agent 时，描述的正是这样一种工作方式：模型读取屏幕截图，理解按钮、菜单、文字和当前状态，再通过虚拟鼠标和键盘执行点击、输入、滚动等操作；完成一步之后重新观察屏幕，再决定下一步。

从工程角度看，这条路线有一种近乎笨拙的合理性。假设一家公司的内部系统已经运行十年，没有完善 API，开发团队也不可能为了 AI 把几十套系统全部重做。只要 Agent 能够看懂屏幕、使用鼠标键盘，它就有机会直接进入这些旧系统工作。

软件底层本来拥有一个明确的能力，比如：

get_product_metrics(period="7d")

为了让人使用，开发者先把它包装成页面：

进入数据中心
→ 打开商品分析
→ 选择日期
→ 选择指标
→ 点击查询

现在 Agent 又看着这个页面，重新猜测“这个日期选项是什么意思”“那个按钮是不是查询”“我下一步应该点哪里”，最后才触发最底层的那个能力。

机器的能力先被翻译成人的界面，又被另一台机器理解回来。

这当然不意味着 GUI 没有价值，也不意味着 Computer Use 是一条错误路线。恰恰相反，它提供了一座极其重要的桥，让 Agent 可以先进入已经存在几十年的软件世界。

只是，当软件本身开始知道“以后调用我的不只有人”时，它大概不会永远要求 Agent 通过找按钮来使用自己。

---

如果越来越多操作由 Agent 完成，软件应该把什么暴露给它？

继续沿着刚才的例子往下想。如果一个人要查询最近七天的经营数据，页面、筛选器、日期选择器和图表都很有价值，因为它们帮助人理解系统有什么数据、当前选中了什么、还能做什么。

但对 Agent 来说，它真正需要的可能完全是另一套东西：

这个系统有哪些能力？
每个能力需要什么参数？
它会修改什么状态？
这个操作是否可逆？
调用需要什么权限？
结果可信到什么程度？
哪些数据允许访问？
失败以后该怎样恢复？

这已经不是传统意义上的 UI 设计了。

API 和 Tool Calling 解决了其中一部分：不再告诉 Agent“右上角有一个导出按钮”，而是告诉它“这里存在一个 export_report 能力”。但如果 Agent 真正成为软件生态中的参与者，仅仅存在一个 API 仍然不够。能力还需要能够被发现、理解、选择和验证。

这一点已经开始从推演进入现实。2026 年 6 月，Google 发布 Agentic Resource Discovery（ARD）规范，试图解决三个很基础的问题：Agent 到哪里找到需要的能力、应该选择哪个能力，以及怎样确认自己连接的是可信对象。

这件事看起来距离普通用户很远，却可能是软件变化中很关键的一层。过去开发软件，开发者首先想的是“怎样让人知道我有什么功能”；如果 Agent 以后真的承担越来越多操作，软件还会多出一个问题：

怎样让机器准确地知道我能做什么。

这和“增加几个 AI API”不是一回事。它意味着软件可能开始同时拥有两种表达方式：一种面向人，一种面向机器。前者关心图形、结构、反馈和可理解性；后者关心能力、语义、权限、状态和约束。

底层还是同一个软件，只是面对了两种完全不同的操作者。

---

这时候，“软件是给人用还是给 AI 用”这个问题就变得微妙了

如果 Agent 成为软件越来越重要的操作者，很容易冒出一个看起来很直接的问题：未来的软件究竟应该服务人，还是服务 AI？

但我觉得这可能不是一个正确的问题。因为 AI 并没有变成软件最终要服务的对象。

我让 Agent 安排行程，真正要旅行的是我；我让它分析公司经营数据，最后决定是否调整业务的人仍然是我；我让它操作 CRM、处理文档、调用财务系统，Agent 并没有因此获得自己的目的。

真正发生变化的，是过去我们习惯放在“用户”这个词里的很多角色，开始被拆开。

以前，一个人在软件里通常同时完成几件事：我提出目标，我判断应该使用哪个功能，我完成操作，我理解结果，我决定下一步，而且最终权限也掌握在我手上。

Agent 出现以后，它可能变成这样：

           人
负责目标、偏好、权限、最终判断
            ↓
          Agent
负责规划、寻找能力、执行、协调
            ↓
         Software
提供数据、状态、规则和 Capability

于是一个过去并不明显的区别开始变得重要：

软件的使用者，和软件的操作者，并不是同一个概念。

软件最终仍然服务人的目的，但最频繁直接调用它的对象，未来可能越来越多地变成 Agent。

这个变化要比“AI 会不会让 GUI 消失”重要得多。

因为一旦这两个角色开始分离，过去大量围绕“用户就是操作者”建立的软件设计假设都会跟着松动。

---

可是任务最后还是要回到人

Agent 可以绕过 GUI 调用 Tool，可以读数据库，可以连续操作多个系统，但任务做完以后，最终结果仍然要交给人。

而这里又会出现一个很现实的问题：所有结果都适合塞回聊天框吗？

显然不是。

如果我问“昨天收入多少”，一行文字就够了；如果我要比较 50 个商品，表格明显比几十段描述好读；如果我要看半年趋势，没有必要让 AI 用几百字告诉我每个月涨了多少，一张图就能看明白；如果 Agent 已经找出一个异常商品，我需要的可能是一张把销量变化、退款率、库存和下一步操作放在一起的卡片。

这时候，一个叫Generative UI 的概念开始自然而然地出现。

它并不是因为行业突然觉得“AI 应该生成网页”，而是因为 Agent 带来了一个很朴素的问题：当任务不是按照传统页面路径完成的，结果还应该被强行塞进哪个预先设计好的页面？

Google Cloud 对 Generative UI 的当前定义，就是让模型根据用户意图、会话上下文和数据，在运行时决定布局、组件和数据可视化，而不是要求开发者提前写死所有界面状态。过去的软件通常先有页面，再把用户带进页面完成任务；现在开始出现另一种可能：先有任务，然后根据这个任务决定此刻最适合出现什么界面。

比如一个经营系统不必永远有一个固定的“商品分析页”。

当你问“最近整体怎么样”，它可以给你趋势和核心指标；当你追问“问题出在哪”，同一批数据可以变成异常商品列表；当你决定处理某个商品，界面再出现库存、价格和确认操作。

界面不再一定是任务开始之前就存在的容器，它也可以是任务进行过程中产生的结果。

再进一步，UI 甚至不只是展示结果。一次旅行规划里，Agent 给出三个航班方案，人选一个；它继续查酒店，人调整预算；到了付款前，系统再出现一个明确的确认界面。这个过程中，界面实际上成了人和 Agent 共同完成任务的控制面。

Google 在 2025 年公开 A2UI、并在 2026 年继续推进它时，做的正是其中一种工程尝试：Agent 不直接向客户端发送任意 HTML、CSS、JavaScript，而是发送声明式 UI 描述，由客户端自己的组件和设计系统完成最终渲染。

这些技术现在都还很早，未来也未必最终采用今天的名字和协议。但它们至少说明，同一个问题已经开始从产品实验走向基础设施：

Agent 做完事情以后，人究竟应该通过什么来理解、确认和继续操作？

---

比界面更深的变化，可能发生在 Application 本身

如果只讨论到这里，这仍然像是一场 UI 变革。但再往前一步，事情会开始碰到软件更底层的结构。

我们今天使用软件有一种很强的“App 思维”。想修图，就打开某个设计软件；想查销售，就进入经营后台；想订酒店，就打开旅行 App。我们真正想获得的是某项能力，但第一反应通常是“哪个 Application 拥有这个能力”。

这是过去几十年非常自然的软件组织方式。

Application 往往同时把几样东西包在一起：Capability、数据、业务逻辑、账号和权限体系，以及 Interface。想用里面的能力，通常先要进入这个 App。

Agent 的出现却提供了一种不同的组织方式。

假设我说：“安排下个月去北京出差，避开已经有会议的日期，预算控制在一万元以内。”

完成这件事可能需要读取日历、查航班、查酒店、比较交通位置、计算预算，最后也许还需要创建新的日历事项。

这些能力来自不同的软件。

过去我自己会在几个 App 之间跳转，把信息从一个地方搬到另一个地方；如果 Agent 承担了这些操作，我面对的可能只是一整个“北京出差”任务。背后用了几个 Application，反而没有过去那么重要。

于是可能出现一种很有意思的分离：

航班能力 ─┐
酒店能力 ─┤
地图能力 ─┼→ Agent → 当前任务
日历能力 ─┤
支付能力 ─┘

这并不意味着 App 会消失。专业软件依然需要稳定的工作空间，企业系统依然需要完整的权限和数据体系，品牌、长期状态、复杂工作流也不可能因为 Agent 出现就凭空消失。

真正可能变化的是：Application 不再是调用软件能力的唯一入口。

过去，Capability 和 Experience 往往被封装在同一个 App 中；未来的一些任务里，能力仍然来自不同 Application，但最终交付给用户的 Experience 却可能由 Agent 在任务层重新组织。

这件事如果真的规模化，影响就远远超过 UI。软件的入口、分发方式、品牌关系，甚至“谁拥有用户关系”都可能重新发生变化。

如果一家公司的服务越来越多是由 Agent 调用，而用户很少真正进入它的界面，那么它应该怎样设计产品？应该把资源投入在更好的 App，还是投入在更清晰、更稳定、更容易被 Agent 理解的 Capability 上？

---

未来的软件，可能需要同时面对两种对象

所以回到最开始的问题：AI 会对软件带来怎样的变革？

现在还很难给出一个宏大的确定答案。今天的 Agent 仍然会犯错，Computer Use 仍然需要大量安全限制，高风险操作依然需要人的确认；很多高度专业、需要连续空间操作的工作，也根本不适合被一个动态界面完全替代。OpenAI 在 Computer Use 的官方资料中同样强调了人工监督、敏感操作确认和模型可靠性的限制。

因此，未来大概不会简单地从 GUI 走向“没有 GUI”，更不会从“软件服务人”变成“软件服务 AI”。比较可能发生的变化反而没有那么戏剧化，却更深。

过去的软件主要只有一个设计对象：使用它的人。以后，它可能同时面对两类对象。

面对人，软件仍然需要回答熟悉的问题：怎样让信息容易理解，怎样建立可靠的交互，怎样让用户知道发生了什么，怎样让关键操作始终掌握在人手里。

面对 Agent，问题会变成：我有哪些能力，怎样调用，权限在哪里，状态是什么，副作用是什么，结果能否验证。

而夹在中间的界面，则开始承担一个新的任务：让人能够看懂 Agent 做了什么，告诉它下一步要做什么，在关键节点进行确认，并在必要时重新接管控制。

这些东西今天分别被叫作 API、Tools、Computer Use、Agent Interface、Generative UI、A2UI、MCP，明天可能又会出现新的名字。

名字其实没有那么重要。

真正值得注意的是，它们背后都在响应同一个变化：

人正在把一部分“操作软件”的工作交出去。

---

结语

过去几十年，我们讨论软件体验时，几乎总是在研究“人怎样更好地操作计算机”。

GUI、鼠标、触摸屏、移动 App，这些变化虽然形式不同，但背后的中心始终没有变：软件需要不断适应人。

AI Agent 第一次让这个问题多出了一层。

软件当然仍然需要适应人，因为目标来自人，结果最终也要由人判断，权限和责任更不应该凭空转移给机器。但在目标和结果之间，那个过去必须由人亲自完成的过程——寻找功能、输入参数、跨软件搬运信息、不断判断下一步该点哪里——开始有一部分可以被 Agent 接走。

所以真正值得思考的，并不是“AI 会不会消灭软件界面”。

而是另外一个问题：

如果提出目标的是人，直接操作软件的是 Agent，那么未来的软件究竟应该怎样同时服务这两者？

也许以后评价一款软件，不仅要看它对人是否易用，还要看它的能力是否足够清晰，能否被 Agent 准确发现、理解和调用；而人真正接触到的界面，也不一定永远属于某一个固定 Application，它可能围绕眼前的任务临时组织起来。

这并不是一个已经发生完的未来。今天我们看到的 Computer Use、Tools、Agent 协议和动态界面，都还只是非常早期的形态。但有一件事情已经和过去不太一样了：

软件的最终用户仍然是人，可软件的直接操作者，可能正在第一次大规模地由人类向AI转变。

一旦这个变化持续下去，软件发生真正的变革，或许已经不远了。