美国交互设计

GUI Agent类模型是指Computer Use这类的功能，在手机端的话包括目前流行的豆包手机上搭载的模型，以及智谱刚开源的AutoGLM-Phone-9B。

其实GUI Agent类模型的训练关键是否应该算在RL post-train里是个模糊的问题，现在不少老一点的模型在不少新场景下连单步操作都做不好，这并非一定需要RL的问题。不过本文的视角跟本系列（1）文是一脉相承的，以及GUI Agent最终还是需要对于新应用能够完成多步操作是完成任务的，所以也可以大致算到RL系列中。

同样地，本文是（1）文在GUI Agent场景的一个特化讨论，还没有看过（1）文的请先看完前文。

1、目前的困难

跟AI Coding不同，GUI Agent的数据收集困难，多样性的仿真环境构建困难是个众所周知的问题。

而且GUI Agent模型的跨应用泛化能力较差的问题更加凸显，实际上海外的模型对于国内应用来说几乎不可用，因为这些模型没有针对于国内的网站和应用进行训练。国内的网站和应用的交互范式也与海外有差异。

从仿真环境的准备来说还有很多工程性的问题，不过这并非本文想讨论的。本文还是继续（1）文中的视角，讨论训练过程和数据本身的问题。

1.1、多样性的匮乏

【1】GUI界面的多样性匮乏

对于GUI Agent模型来说，需要面对的场景就比较匮乏了。在浏览器网页端还好一点，但在PC应用端和手机端这个问题就变得更加明显，主要要使用的应用/App就那些。

但对于模型训练尴尬的是，虽然主流应用数量不多，手机端App是频繁在更新的。在时间维度上看，App GUI的多样性其实很多，但在训练过程的这个时间窗口之中，当前最新版本App的GUI多样性又很匮乏。

对于PC应用端来说，这个GUI更新的问题相对少一些，但受到用户PC环境的影响更大一些。

【2】用户任务的多样性匮乏

不光GUI本身多样性匮乏，用户在GUI上进行的任务也相对匮乏，除了少数很复杂的网站和PC专业应用之外，大部分用户在大部分软件上只是在完成少数任务。虽然输入的信息是个性化的，但任务流程很固定，也并不多样。

当然在国内各种臃肿的App上，我们可以探索它们的各种功能，产出很多task，但这些task对于用户主要场景上的成功率和泛化性很难说有多大提升。

除了task多样性匮乏外，每个task的操作过程也往往都非常的单一，进一步加剧了这种问题。

1.2、总结

这些多样性的匮乏都导致了GUI Agent 更像是在形成对特定界面与流程的肌肉记忆。虽然说搞定了一些环境和数据收集之后，可以在一个不太大的模型上把当前应用的肌肉记忆都存下来，但在时间尺度上，这种模型的泛化能力可能有限，需要不断反复更新版本来保持对最新GUI界面的适配。

在规模较大的组织里，很难长期、持续地应对这种只有在长时间尺度上才显现的多样性。所以我们经常能在一年一度的低频假期/事件中看到这点。

2、另一种途径2.1、思路

我们是否有某种新的范式来解决这个问题？做一个10倍好的方案？

是可以的，但这个方案的基础设施构建成本较高，所以本节的方案并不算是一个务实的建议，只是给大家一个参考。

我们希望模型能力能泛化，但我们面对的问题是数据和训练窗口期内训练目标的多样性严重匮乏。解决思路就两种：（1）是给模型增加足够多的先验bias，能让模型从不多样的数据和环境中学习出能泛化的知识。但这条路目前并不是大家所偏好的，而且目前也不知道应该怎么加这个先验。（2）通过Data Augmentation或者Task Augmentation的方式，把一些并不能很好泛化但容易产生肌肉记忆的特征破坏掉，迫使模型学习更高层面的信息，去理解这个任务和GUI本身。

可能有读者会认为让Agent在环境中反复探索就能自动产生这个泛化性。但这是不行的，因为一个固定的或者并不多样化的环境，并没有给Agent“哪些设置会变”的信息，它只是面对了当前的环境，并没有对于其他情况被训练，所以只要训练得足够多，它就会产生对这个环境的肌肉记忆，而产生肌肉记忆以后，由于reward信号不能再进一步指导，它泛化能力的训练也就陷入停滞。

所以在当前大家能接受的范围中，更好的解法就只有：构建一个足够多样性的环境，让Agent在其中训练，或用于合成数据。

2.2、要破坏哪些相关性、保留哪些相关性

虽然我们认为GUI界面可以很多样，但其中是否有什么共性的东西，并且是能够泛化的？

我认为是有的，我称之为产品交互设计模式。我目前没有一个很精确的定义，我尽量试图描述这个概念。

同一个时代中，App的GUI设计和操作方式都有着某种共性，因为 用户熟悉的交互方式 和 App的交互设计 是协同演化的，特别是目前基于A/B的GUI优化大行其道，所以更加强化了这种协同演化。所以其实可以认为目前全体用户习惯的交互设计模式大概只有少数几种主流的，如果一个App的交互方式更接近于用户已经习惯的某种模式，那么用户在无人指导下上手这个App就变得更加容易，也能表现为更高的转化率。

如果你去看一些10年前20年前的App/应用界面设计，你能一眼看出他们并不是现在的产品交互设计模式。这种范式在不同国家（或者说文化圈）之间也是有所不同的，这就表现为中国和美国在网站交互设计和App交互设计上的差异。

所以这种交互设计模式就是一个可以较长时间泛化的，也应该保留的相关性。

除了GUI界面设计范式外，剩下对于典型的任务也是一种世界知识。例如大部分人都知道在购物App上购物的流程在逻辑上大体是如何的，在外卖App上点外卖的逻辑流程是如何的。大部分这类软件的使用逻辑都是基本一致的。

2.3、如何实现

XXX Augmentation的实现方式都是进行某种生成，保持需要的部分，在不需要保持的部分上进行多样性生成。

在这里，我们实际需要一种虚拟的App/PC 应用/网站 GUI生成方案，能够根据选择的GUI设计范式和目标业务逻辑功能来随机生成对应功能的虚拟App。这些共享当前主流设计范式、拥有类似业务流程的虚拟App可以作为一个更多样性的仿真环境。

这确实是一个新需求，由于我并非前端/App端/UX的专家，所以我不确定这是否完全不可行。但考虑到目前LLM模型逐步变强的网页生成能力，这似乎是可行的。

但这确实是一种类型的新需求，大概没有几个前端或者App端专家做过类似的事情。但我仍然觉得这大概是可以在

在这个虚拟GUI生成工具上，我们可以放入大量已有App上常见的设计元素，例如各种类型的广告、弹窗等，随机性的出现，或者在生成时进行锁定，来模拟App中出现的各种情况。当出现新的设计元素时，只需要单独增加该类设计元素的生成逻辑（并解决融合性）即可。

对于内容平台类应用，也需要对应的虚拟内容库的生成。但我觉得内容的分布不必非常贴合原始应用，只要看起来大概类似就可以。因为大部分GUI Agent的目标不是要能完全生成符合目前App上内容分布的内容，而是去操作这些App，这些App的操作逻辑跟上面内容当前热点其实关系不是很大。

结语

本文的提供的方案确实成本高了很多，大概只适用于真的想在这方面长期投入的模型公司或者专门的数据/环境供给公司。

希望这能给大家带来一些灵感。

交流与合作我目前正在看机会，详情请见

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 。

本文于2025.12.12 首发于微信公众号和知乎。