未来，每个人看到的界面都不一样

最近，看着大模型从回答问题，一步步走向写代码、改页面和调用工具，我开始想：如果它继续变强，软件会变成什么样？

现在使用一款软件，通常是开发者先设计好界面，再让所有人沿着预设的入口使用。即使可以切换主题、调整几个模块，大部分页面和操作路径仍然是事先决定的。

但每个人的审美和习惯都不一样。有人喜欢简洁，有人希望一屏看见所有信息；有人喜欢图表，有人更愿意看清楚列出的文字。同一个页面，对一个人恰到好处，对另一个人却可能显得拥挤。

这让我产生了一个念头：未来，每个人看到的界面，会不会都不一样？

开发者提供数据和软件能力，Agent 根据每个人的审美、习惯和正在做的事情，组织出适合他的界面。继续往前想，如果 Agent 连处理数据的程序也能编写，它或许还能根据一句需求，构造出开发者没有提前设计的功能。个人设备上的软件，就可以随着使用者的需要持续变化。

这个念头可以从一款普通应用的工作方式说起。

一款软件里，前端和后端分别在做什么

假设手机里有一个家庭应用，可以查看相册、控制灯光、记录用电和管理日程。

打开应用时，看到的照片排列、设备列表、按钮和图表，以及点击它们时发生的界面变化，都属于前端。它负责把信息呈现出来，让人能够操作软件。网页、手机 App 和电脑软件，都有这一层面向用户的交互。

点击“关闭客厅灯”之后，还要确定控制的是哪盏灯、当前用户有没有权限、设备是否收到命令，再把结果反馈回来。这些处理属于软件背后的逻辑。在常见的联网应用中，其中许多工作由服务器上的后端完成。

照片的拍摄时间、日程内容、设备信息等，则需要放在某个地方保存。数据库负责有组织地保存和查询这些数据。它可以位于服务器，也可以就在个人设备上。数据库是后端经常使用的基础设施，两者的范围并不相同。

部分	在家庭应用中的工作
前端	显示相册、用电图表和灯光按钮，接收用户操作
后端	处理请求、检查权限、协调设备、返回结果
数据库	保存相册信息、用电记录和日程等数据

前端与后端通常通过 API，也就是程序接口交流。前端请求“读取这个月的用电记录”，后端按照约定返回数据，前端再把它画成图表。同一份记录，既可以显示成折线图，也可以显示成表格。

这个分工给了我一个继续想下去的理由：既然能力和数据可以与呈现方式分开，为什么所有人一定要使用相同的呈现方式？

当 Agent 开始接手前端

这里的 Agent，可以理解为一个能够使用工具、执行步骤的软件代理。大模型帮助它理解“我想做什么”，程序运行环境让它能够读取数据、调用接口，或者修改代码。

如果这样的 Agent 足够可靠，它就能根据用户的要求，把后端提供的能力重新组织起来。

仍然是那个家庭应用。我喜欢安静的首页，只想保留设备状态和当天日程；家人更在意照片，希望打开应用先看到相册；有人在排查用电问题，首页就应该把用电记录和设备状态放在一起。

这里可以分开观察两种变化。只把页面从冷色改成暖色，满足的是审美偏好；把常用入口重新排列，甚至根据任务组合操作步骤，改变的则是软件的使用方式。

下面这个示例允许分别改变审美、首页组织和当前任务。可以先保留一个喜欢的版本，再只改一项，比较它究竟影响了外观，还是影响了能看到的信息和操作。

这是用虚构数据和固定规则搭建的概念演示，没有实时调用大模型。在“日常浏览”里，相册优先与设备优先会产生不同的排序；换成“准备出门”，页面则突出设备与日程，并提供关灯操作。

我设想的变化就发生在这里：过去，用户学习开发者设计好的页面；未来，Agent 也可以根据用户的目标来组织页面。

这种按上下文生成或组合界面的方向，通常称为 Generative UI，生成式用户界面。A2UI已经提供了一条具体路线：Agent 发送结构化的界面描述，客户端使用自己的组件目录渲染。Flutter GenUI SDK也在探索把 Agent 与现有组件连接起来，官方目前仍将其标注为实验性。

这些技术让“Agent 组装界面”有了实现基础。至于一个人长期使用的整套界面，怎样逐渐贴近他的习惯，仍然需要继续探索。

在这样的分工下，前端开发也会发生变化。开发者需要把更多精力放在可靠的组件、交互规则和生成后的检查上；具体页面如何组合，则可以留出更大的空间，让 Agent 根据人和任务决定。

只知道接口，还不足以理解软件

最初想这个问题时，我觉得：既然 Agent 会写前端，把后端接口给它，似乎就够了。

但回到关灯这个例子，很快就会遇到一个问题。一个“设置设备电源”的接口，可能面对的是客厅灯，也可能面对冰箱。接口能够接收一个设备编号和开关状态，并不意味着所有设备都适合被关闭，也不意味着任何用户都有权这么做。

Agent 除了知道“怎么调用”，还需要知道这项能力的含义、使用条件，以及怎样确认结果。OpenAPI可以描述接口的操作、输入、响应和安全要求；具体业务规则还需要完整说明，并由执行系统落实。

试着在下面选择“访客”，或者把目标换成“冰箱”。界面仍然能表达关闭设备的请求，但它会在哪一步被拒绝？再把目标改回客厅灯，选择离线，看看“有权操作”和“操作成功”之间还有什么差别。

这个实验只在浏览器里模拟检查。真实系统中，权限和公共业务规则需要由可信的执行环境落实，不能依赖 Agent 自己承诺遵守。

对使用者而言，界面怎么变化都可以讨论，但点下去之后发生了什么，必须说清楚。设备没有回应，就应该显示尚未完成；没有权限，就应该解释为什么被拒绝。生成一句流畅的“已经关灯”，不能代替设备的真实回执。

再往前想：会不会连后端也不需要了

如果 Agent 可以根据接口生成前端，我还会继续想：有些后端做的事情，是不是也能交给它？

以一个只供自己使用的记账工具为例。数据库保存日期、金额和分类，程序负责录入、查询、按月份汇总，再把结果画出来。如果 Agent 能可靠地编写和维护这些程序，这些处理就有机会放在我的电脑或手机上完成，而不必专门部署一套应用后端。

我说“按旅行整理今年的支出”，它便为这些数据增加一种查看方式；过了一段时间，我想把记账与出行计划放在一起，它又可以修改本地程序，把相关数据组织到同一处。

在这种个人应用里，也许可以不再单独开发和部署传统的应用后端，只保留数据库，由终端上的 Agent 编写所需的处理逻辑和界面。

这种结构并非要求所有基础设施都凭空消失。SQLite就是一个现成例子：程序可以在自身进程内使用数据库，直接读写本地数据库文件，无需另起一个数据库服务器进程。这说明“本地程序加数据库”本身已经是一种可行结构；由 Agent 长期生成和维护这个程序，则是这里进一步提出的设想。

此时，汇总、校验和处理数据的逻辑仍然要存在，只是它们可以迁到个人设备，交给 Agent 生成的程序运行。稳定的结果也不必每次都让模型重新计算：Agent 可以先编写汇总程序，之后由程序重复执行，直到需求变化时再修改。

个人笔记、相册整理、阅读记录，也可以沿着这个方向思考。数据长久保存，围绕数据的工具则根据使用者的需要不断调整。用户不必等待某个产品排期，才有机会增加一种只对自己有用的视图或处理步骤。

数据、规则与 Agent，各自负责什么

“只留下数据库”适合描述一部分个人工具。换成一家人共享的日程，或者多人同时使用的订票系统，就需要把后端的职责拆开看。

查询记录、组合接口、生成报表、安排个人流程，这些工作可以给 Agent 留出较大的自由。谁有权修改数据、一张车票是否还有库存、一笔操作是否满足共同约定，则需要一个参与者不能自行改写的判断依据。为了说明这种区别，我把前一类称为业务执行与编排，把后一类称为业务裁决。实际系统里，这两类工作可能交织在同一次请求中。

即使 Agent 能写出完全正确的程序，也不能因此由它决定自己拥有多少权限。用户能够修改自己终端上的代码，就意味着共享服务不能只依赖终端的判断。两台手机都显示“提交成功”，也不能把一张车票变成两张。

一部分裁决可以放进数据库。例如，PostgreSQL 的行级安全策略可以限制普通角色能够读取和修改哪些数据行。更完整的身份验证、业务约束和外部服务协调，也必须有明确的承担者。

因此，更一般的架构可以概括为 Data + Rules + Agent：数据、规则与个人代理共同构成软件。 界面则是它们面向使用者的呈现。

部分	主要职责	可以怎样变化
数据层	保存数据、关系与版本	数据持续积累，访问范围受授权限制
规则与能力层	提供合法操作，执行权限、业务约束与事务规则	平台维护公共规则，开放可组合的能力
个人 Agent 运行环境	理解需求，生成查询、程序与工作流	根据个人目标组合能力，保存可复用的结果
动态界面	显示数据、接收操作、呈现真实结果	按审美、习惯和任务组织交互

这套分工不要求平台提前写出每一种业务工作台。可以设想一个商品数据平台，开放商家有权读取的商品、订单和库存数据，并明确每个字段的含义。商家 A 想看销量趋势，商家 B 则提出：“找出近七天卖得不好、但是库存很多的商品。”

对第二个需求，Agent 需要先把“卖得不好”和“库存很多”变成可检查的条件。例如，让商家指定销量阈值和库存阈值，再生成查询、列出符合条件的商品，并显示所用时间范围和筛选依据。同一份数据，也可以按库存金额或历史销售情况重新比较。

“滞销分析”这个完整模块，未必需要平台提前开发。平台提供可靠的数据定义与访问能力，Agent 根据需求组织查询、计算和界面。它构造的新功能来自已有能力的组合；如果没有成本数据，就不能声称算出了真实利润，没有合适的预测方法和检验，也不能把一条延长的趋势线当作可靠预测。

如果商家进一步要求自动打折或下架商品，Agent 就需要调用相应的可信操作，由平台重新检查权限与业务条件。读取数据做分析，与真正改变共享业务状态，在同一个工作台里仍然有不同的边界。

今天常见的路径是开发者先设计功能，用户再选择使用；这里设想的另一条路径，是用户先提出需求，Agent 再在已有数据、规则和能力内构造功能。

个人知识整理、数据分析和家庭设备编排，都提供了值得尝试的空间。随着任务从个人数据处理走向多人协作与交易，统一的共享状态与裁决也会变得更重要。

个人终端上的软件，由 Agent 自己改写

沿着这个设想，电脑、手机和平板上的软件，可能会出现一种新的生长方式。

最初，我只需要一个能够保存笔记的小工具。后来，我想把读书摘录和日程关联起来；再后来，我希望写文章时能直接找到相关照片和旧笔记。今天，这些要求往往意味着寻找另一款软件、安装插件，或者等待更新。

如果终端上有一个长期工作的个人 Agent，它可以读取我允许使用的数据，理解现有程序，再为这些新需求生成一个修改版本。界面、查询方式和本地处理流程，都可以跟着需求变化。

到这一步，“每个人看到的界面不同”还只是最容易看见的部分。每个人的软件可能连功能组合和操作流程都不一样：两个人从相同的基础工具出发，用上一段时间后，各自留下了不同的模块、快捷操作和数据视图。

这里的“终端上的 Agent”，指它能够在个人设备的授权环境中工作，并不要求大模型一定在本机运行。模型可以在本地，也可以通过远程服务调用；代码在哪里执行、哪些数据能够离开设备，需要分别决定。

我也不希望这样的 Agent 每天把熟悉的软件改得面目全非。它应该保留现有可用版本，先生成候选修改，在独立环境中检查，再展示改动。采用新版本之后，原来的数据和工作进度能够继续使用，出现问题时也能恢复。

下面的流程演示把这个过程缩小为一次界面更新。选择正常方案、虚构能力或设备离线，可以分别观察：候选方案什么时候应该被拒绝，界面什么时候才被采用，以及采用界面之后，为什么还要等待真实操作结果。

它演示的是有限的界面更新流程，没有真的改写本机软件。若进一步允许 Agent 修改程序，检查还必须覆盖新旧版本对数据的读写是否兼容、原有功能是否仍可使用，以及恢复旧代码时如何处理已经改变的数据。一次涉及数据迁移的更新，不能只靠把代码切回去就当作完成恢复。

从打开一个 App，到直接提出需求

如果界面和功能都可以按需构造，使用软件的起点也可能变化。

今天想查看家庭耗电情况，我可能先去找一款合适的 App，研究它支持什么设备，再学习怎么生成报表。在刚才设想的环境里，我可以直接说：“帮我看看这个月家里的电都用在哪里。”

Agent 找到我已经授权的电表记录和设备数据，检查哪些时间段的数据完整，再编写查询与汇总程序，生成一个可以继续调整的用电看板。如果数据只有全屋总量，它就只能展示总量变化；要分析到每一台设备，还需要相应的分设备计量数据。按需构造功能，也要从实际拥有的数据和能力出发。

这个看板可以只为一次排查服务。觉得有用，我再说：“把它保留下来，以后每周整理一次。”Agent 便把一次性的分析保存成长期工具，记录数据来源、计算口径、运行时间和结果位置。数据源失效或权限到期时，也需要显示中断原因。

临时生成的功能，就这样变成了可以重复执行的工作流。

用户的需求可以先于一个具体的 App 出现，软件围绕需求临时组成，再由用户决定哪些部分值得长期留下。

这种使用方式，可以称为从“以应用为中心”走向“以意图为中心”。家庭旅行就是另一个例子：个人 Agent 可以把日程、路线、预算和待办组织成一个工作台，用户从安排旅行这个目标出发，不必先按软件边界拆开任务。

已有 App 仍然可以提供专业交互和稳定流程。生成一次功能需要的时间、计算成本、权限衔接，以及熟悉界面的价值，都会影响用户是否愿意改用这种方式。按需生成可能先成为某些任务的入口，再逐渐扩展；它能否广泛替代 App，还不能仅凭这个设想确定。

支撑这种软件的，可能是一个个人 Agent 运行时

走到这里，我开始觉得，值得做成产品的还有支撑这些变化的运行环境。

“运行时”可以理解为让程序实际工作起来、管理它能做什么的软件环境。这里设想的个人 Agent 运行时，可以运行在现有电脑和手机系统之上：模型提出代码、查询和界面方案，运行时负责把它们放进明确的权限与执行边界中。

它需要让 Agent 找到可用的数据和能力，也让用户看见自己授权了什么。生成的新程序先在受限环境里检查，只能访问获准的文件、网络和服务；采用后，程序的版本、依赖、运行状态和操作记录能够保存。重复执行的计算交给版本明确的程序完成，更新与重试也沿着可检查的规则进行。

当操作涉及多个步骤时，运行时还要跟踪每一步的真实结果。一个数据库事务可以协调该数据库内的一组修改，但不能自动撤销所有外部操作。例如日程写入成功、预订却失败，就必须分别记录，并决定是否重试或采取补救措施。

因此，做出一个会写代码的 Agent，和做出一个可以长期托管个人软件的环境，中间还有数据持久化、权限管理、版本兼容和失败恢复等工作。这些能力可能成为独立的产品机会；是否成立，要看它能否让用户持续保留和使用生成的工具，是否降低维护负担，以及能否与现有服务合作。

开发者预先编写的某些查询、报表和接口组合代码，可能因此减少；用户提出更多新需求，也可能让生成的代码数量增加。在这套架构里，维护工作的重心会转向数据语义、能力约定和可信执行机制。

我想象中的分工是：软件提供商负责数据的真实性和公共操作的合法执行，个人 Agent 根据我的目标，决定怎样组合这些数据和能力。

打开电脑时，数据还在，熟悉的工具也还在。当我提出新的需求，Agent 可以生成一份新的功能和界面，经过检查后留在我的环境里。另一个人连接同样的数据平台，却可以因为不同的目标，拥有另一套工具。

未来，每个人看到的界面都不一样，也许只是这个变化最先显露出来的部分。再往后，每个人的软件功能、工作流程，以及软件随需求更新的方式，都可能逐渐不同。

参考资料

以下资料用于说明已有技术基础。Data + Rules + Agent 的分工、按需构造功能，以及个人 Agent 运行时，是本文据此推演的设计设想。

• A2UI：What is A2UI?，声明式界面描述与客户端组件渲染。
• Flutter：GenUI SDK for Flutter，连接 Agent 与现有组件目录的实验性 SDK。
• OpenAPI Initiative：OpenAPI Specification v3.2.1，HTTP API 的描述规范。
• SQLite：SQLite Is Serverless，无需独立数据库服务器进程的运行方式。
• PostgreSQL：Row Security Policies，数据库中按角色限制数据行访问的机制。