你给一个 Agent 截了张后台页面，它就能点对按钮、填对表单、跟着页面变化继续做事。

听起来像浏览器自动化的自然升级。但 Runway 这次发布 Solaris 时，讲的是更激进的一件事。它试图实时逐帧生成可交互的应用和网站界面，交互层不是 DOM，不是组件树，也不是某种隐藏的结构化描述，而是一连串会对输入作出反应的图像。

我看到这个设定时，第一反应不是「UI 生成又进化了」。我想到的是另一件更麻烦的事。过去十几年，软件工程拼命把界面的样子和界面的语义分开。前者给人看，后者给程序读。Solaris 这类 Interface World Model 倒过来了，它把样子重新推到舞台中央。

这会把 Agent 带去哪里？

先别把它当成更会画图的模型

从公开介绍看，Solaris 被 Runway 放在 Interface World Models 这个新系列里。它的特点有三件事，实时生成，按帧渲染，可开放交互。用户看到的是一个像应用或网页的画面，输入动作后，下一帧画面继续响应。

这里有个容易混淆的地方。传统的 text-to-UI 系统，是让模型生成 React、HTML 或设计稿。产物落在代码、组件属性、布局规则上。即便生成结果不理想，工程师还能够进 DevTools 看 DOM，找到状态，改一个 class 或 API。

Solaris 的路线更像是，模型在持续模拟「一个界面处于什么状态时，下一帧应该长什么样」。它不一定需要先产出一个你熟悉的组件树，再让浏览器渲染。

这听着很像视频生成，可它又不是普通视频。普通视频只需要前后画面看着顺。界面则有更苛刻的约束，按钮要还在原来的逻辑位置，表单填过的内容不能凭空变，打开的菜单应该接得住下一次点击，错误提示得和动作相关。

好看的连续画面还不够。

它得记住你刚才干了什么。

这也是我觉得这类产品值得盯住的原因。它挑战的不是 Figma 或前端框架里的哪一个功能，而是一个老问题，交互界面能不能被当成可预测的世界来建模。

真正的变化，是 Agent 不再只读结构化页面

现在让 Agent 操作网页，大多有两条路。

一条路走结构化信息。浏览器给可访问性树，工具给 DOM、元素坐标、表单字段或 API。模型读到的不是完整屏幕，而是一个经过整理的行动菜单。它快，也便宜，在网页没改版时很稳。

另一条路走视觉。给模型截图，让它自己判断哪里能点。这条路更接近人类用电脑，也更能跨过 Canvas、远程桌面、复杂桌面客户端这些没有好 DOM 的地方。代价同样明显，慢、贵，而且非常容易被一个弹窗、一块广告或一次布局抖动带偏。

Solaris 所指向的，是第三种处境。Agent 面对的不只是一个真实网站，还可能面对一个由模型临时生成的、纯视觉的交互环境。这个环境没有可靠的标签给它读，也不承诺固定的内部实现，但它看起来足够像真实软件。

你如果在做 LangGraph 工作流，会立刻感觉到状态管理的味道。一个 Agent 的状态不再只是 messages、tool calls 和业务字段。页面本身也成了状态，而且是难以直接读取的状态。每一步都得靠观察上一帧、预测可行动作、执行、再观察来闭环。

这和调用一个干净的 REST API 相比，别扭得多。

可现实世界常常就是别扭的。企业里有历史系统，有权限隔离的桌面软件，有套在 VPN 里的报表工具，有弹窗比业务逻辑还多的采购平台。把这些系统全部改造成 API，成本高到没人愿意签字。让 Agent 看懂屏幕并操作，反而可能是最短路径。

所以我并不觉得视觉交互会替代结构化集成。它更像一个兜底层。API 和 MCP 能走通时，永远优先走它们。它们更容易审计、测试、回滚和授权。只有当系统真的没有门时，Agent 才该像人一样去摸门把手。

这个优先级很重要。

界面世界模型最适合先做训练场，而不是生产入口

Runway 在介绍里提到，Solaris 可用于训练智能体适应变化中的界面，而不是局限在固定训练环境。这里其实藏着比「生成应用」更实际的方向。

今天训练 GUI Agent，最头疼的不是缺一个 benchmark，而是 benchmark 太整齐。任务页面固定，按钮位置固定，初始数据固定，评测脚本固定。模型很容易学会一条近路。它未必学会了订票、报销或排查告警，它可能只是记住了这个网站第几个元素长得像提交按钮。

这类过拟合很隐蔽。离开评测环境，换一个地区、一个分辨率、一次 A/B 实验，成功率就掉下去。做过 RPA 的人对此不会陌生。一个字段改名，自动化脚本就开始装死。

如果界面世界模型能以合理成本生成大量相似但不相同的任务环境，它可以做三类很有价值的事。

第一类是布局扰动。把同一个业务任务放进不同信息密度、不同菜单层级、不同窗口尺寸的界面里。Agent 必须识别意图，不该依赖某个像素坐标。

第二类是状态扰动。同样是「提交报销」，有的账号缺预算，有的发票重复，有的审批人不在线。训练重点从点到按钮，变成识别当前状态、找出阻塞条件、决定要不要继续。

第三类是反事实任务。故意让一个看着很像保存的按钮触发删除，让一个看着正常的提示里藏入与任务无关的文本。这样测到的不是模型会不会按流程走，而是它有没有在行动前核验后果。

后面这类尤其关键。真实网页里，注入攻击不只存在于一段文本里。它可以躲在工单标题、客户留言、文件名、知识库页面，甚至是一张带字的图片里。视觉 Agent 把屏幕作为输入后，攻击面只会变大。

训练场可以故意恶毒一点。

生产环境不能靠运气。

这里有一个很硬的技术问题，画面连续不等于状态正确

做视频的人会关心 temporal consistency。做界面的人关心的却是 state consistency。两个词只差一点，工程难度差得很远。

假设你在一个动态生成的财务界面输入了金额 1000，点下一步，界面看起来流畅地切到确认页。视觉上没毛病。但真实系统里，你希望至少有几件事成立。

  • 金额真的被写进当前会话，而不是只渲染在画面上
  • 返回上一步时，输入仍在
  • 多次点击不会重复扣款
  • 网络失败和权限不足有不同的反馈
  • 用户 A 的修改不会泄漏到用户 B 的界面

一旦界面只是像软件那样演下去，这些保证就不存在。它可以生成一个极其逼真的成功提示，却没有任何可追溯的业务副作用。对于游戏、原型、教学演示，这甚至是优点。对于银行、医疗、企业审批，它会让人很不安。

这里需要把两种目标分开。

一种是 simulation。模型负责模拟界面和任务世界，目标是训练、演示、探索。画面可信、规则自洽、反馈丰富，比接入真实后端更重要。

另一种是 execution。界面只是业务系统的一个外壳，真正的状态在数据库和服务端。此时模型生成的层必须服从可验证的 action contract。Agent 点击了什么、服务端接受了什么、发生了什么副作用，都得有独立于画面的日志。

我自己的判断是，前一种会先跑出来，后一种不会很快成熟。不是模型能力不够，而是后者要求整个产品架构承认一个不太性感的事实，视觉层不能是唯一真相。

对 Java 和 Spring 团队来说，这个判断很好理解。你不会把一次扣款的成败交给前端 toast 决定。你会要幂等键、审计日志、事务边界、状态机和可重放事件。换成 Agent 也是同一套常识，只是输入从 HTTP 请求变成了屏幕观察和鼠标动作。

别急着让 Agent 直接点击，先给它一份行动收据

如果未来团队真的要把 GUI Agent 接进业务系统，我会建议别从「让它能点」开始，而是从「每次点完能留下什么」开始。

一个能落地的最小架构，大概有四层。

观察层 负责截图、OCR、可访问性树和业务上下文。不要迷信单一信号。视觉告诉 Agent 页面长什么样，可访问性树告诉它控件可能是什么，业务上下文告诉它这一步是否该做。

规划层 负责把任务拆成带前置条件的动作，例如「当订单状态为待审核且预算余额足够时，才提交审批」。它不应该只输出坐标，而应输出意图、目标对象、预期变化和风险等级。

执行层 把高层动作映射成 UI 点击或 API 调用。能调用受权限保护的 API 就别点击。必须点击时，也应该让执行器在动作前后捕获证据，比如元素截图、页面摘要、请求结果。

审计层 保存 action id、操作者、目标资源、前置状态、执行结果和回滚线索。高风险动作要引入人工确认，或者至少二次观察。Agent 说「我已经提交」没有任何价值，系统记录「订单 20260901-17 从待审核变为已提交，幂等键为某值」才有价值。

你可能会觉得这套东西把一个很酷的界面世界模型又拉回了老派企业软件。

是的。

可真正进入业务的技术，最后都要回答同一个问题，出了事谁能复盘。

它还会改变产品原型的速度，但别把假交互卖成真产品

Solaris 这类能力在产品探索上可能非常好用。一个 PM 想测试新的工作台，不必等前端搭完十个页面。他可以给出任务流，快速得到一个能点、会反馈的交互原型。用户研究也能更早开始，团队可以观察用户在哪里犹豫、哪些步骤看不懂。

这种速度很诱人。我也见过太多团队把两周讨论压缩成半天原型后，才发现原先争论的是一个不存在的问题。

但它有个很容易踩的坑。会动的原型比静态稿更像产品，于是团队更容易高估完成度。用户点击顺畅，不代表权限、数据同步、异常恢复、移动端适配和长期维护已经有答案。

一个简单的做法是，把原型明确标成两层。体验层告诉大家用户会看到什么，系统层同时列出哪些交互还没有连接真实规则。每个关键动作后面挂一张小清单，真实数据源是什么，失败时怎么处理，权限在哪里校验，谁负责审计。

这不浪漫，但能避免演示当天很惊艳，开发第一个迭代就卡死。

我更在意的是，它逼我们重新定义「会用电脑」

过去人们说 Agent 会用电脑，通常默认它学会了鼠标和键盘。现在看，这只是最低层的能力。真正会用电脑的 Agent，应该能理解自己处在一个什么系统里，哪些东西可以试，哪些动作不可逆，页面变化是否真的代表任务完成。

Solaris 给出的想象力，在于它让界面不再是固定资产，而像一个可生成、可变形、可训练的环境。它很可能会让 GUI Agent 的训练数据不再那么稀缺，也会让产品原型的边际成本继续下降。

但我不愿意把它包装成「代码将消失」那种故事。DOM、设计系统、后端状态机、可访问性和 API 不会因为界面能实时生成就失去意义。恰恰相反，当画面越来越像真的，我们越需要这些不那么显眼的结构，来证明它真的能被信任。

从这个角度看，Solaris 最有意思的地方不是它能生成多少界面。

而是它把一个一直被藏在 UI 后面的矛盾推到了台前。软件想要自由生成，业务却要求每一步都可验证。未来的 Agent 产品，得同时满足这两件事。

难，但值得做。

给正在做 Agent 的团队三个小建议

  • 把视觉操作当作最后一公里，不要当作默认集成方式。先建设 MCP、API 和清晰的权限模型
  • 用可变的模拟界面训练 Agent，用真实且可审计的接口承载生产动作。训练与执行不要混在同一个黑盒里
  • 给每一次有副作用的动作设计行动收据。截图只能证明它看见了什么，审计事件才能证明它做了什么

这篇文章讨论的是 Runway 对 Solaris 的公开定位，以及它对 GUI Agent 和企业软件架构可能带来的影响。模型能力、可用范围和具体实现仍可能快速变化，实际使用前还得回到官方文档和产品条款逐项核验。

参考资料