多模态 Agent 的门槛，不是看见图片，而是读懂界面

多模态能力这两年进展很快，模型已经能描述图片、理解图表、识别页面布局。
但只要任务从“看懂一张图”变成“在一个界面里持续完成操作”，难度会立刻上升一个层级。

所以我现在看多模态 Agent，最关心的不是它能不能识别截图，而是它能不能真正理解一个界面正在发生什么。

从图像理解到界面理解，差的不是一点点

普通图像理解偏向静态语义：
这里有什么、画面是什么、主体可能在做什么。

GUI Agent 面对的是另一类问题：

• 哪个按钮现在可点击
• 这个输入框是空的还是已经填过
• 这个弹窗是新出现的还是一直存在
• 页面跳转之后，之前的目标是否还成立

这意味着多模态 Agent 不只是“看”，它还要完成从视觉信号到操作语义的映射。

我更愿意把 GUI Agent 拆成三层

1. 感知层

这一层负责读屏幕，提取可用信号，比如：

• 文字内容
• 布局关系
• 颜色和状态变化
• 图标、按钮、输入框等控件类型

看起来最基础，但很多真实错误都发生在这里。
尤其当界面字号小、主题复杂、元素相似时，感知层一旦拿错，后面全会跟着偏。

2. 语义定位层

这层解决的是“我知道它长什么样，但我还得知道它在当前任务里意味着什么”。

例如页面上可能有两个“继续”按钮：

• 一个属于当前流程
• 一个属于推荐弹窗

如果没有任务语义和历史上下文，单靠像素很难判断该点哪一个。

3. 动作验证层

执行动作以后，Agent 还要知道自己是不是成功了。
这是很多 demo 容易忽略的部分。

点了按钮不代表流程推进了，输入了内容也不代表提交成功了。
真正可用的多模态 Agent，必须能在动作之后观察界面反馈，再确认状态是否变化。

为什么界面时序是核心难点

我越来越觉得，GUI Agent 的关键不是单帧理解，而是短时序理解。
因为真实操作几乎总是连续的：

• 页面加载会带来延迟
• 动画会制造暂时状态
• 弹窗会打断原流程
• 某些区域要滚动后才出现

这就要求 Agent 不只是“识别当前这张图”，而是维护一个很短但很关键的视觉状态流。

如果没有这层时序意识，系统就会频繁出现这些问题：

• 明明成功了，却误判为失败
• 明明页面没动，却以为已经跳转
• 把加载中画面当成最终结果

我更看好的几个研究方向

把视觉和结构化树结合起来

单纯看截图很直观，但可访问性树、DOM 结构、窗口控件树这些信号能补足很多像素层不稳定的问题。
未来更强的 GUI Agent，大概率不是只看图，而是图像与结构信号融合。

为局部区域建立短期记忆

界面操作经常只和几个区域有关。
如果系统每一步都“从整张图重新理解一遍”，成本高，误差也大。

相反，如果它能记住：

• 上一步点过哪里
• 哪个区域刚刚发生变化
• 哪些控件是当前任务重点

整个操作链会稳定很多。

把失败恢复设计成默认能力

多模态 Agent 在真实环境里不可能不失手。
真正有价值的不是“永远不点错”，而是点错以后能：

• 识别偏离
• 回到最近安全状态
• 换一个路径继续完成任务

结尾

如果只看展示，多模态 Agent 最吸引人的部分是“它终于能看到屏幕了”。
但真正决定它能不能用的，是它是否理解界面、理解状态变化、理解动作和结果之间的关系。

也正因为如此，我认为 GUI Agent 的研究重点，应该从“看见什么”逐渐转向“看见之后，如何稳定地行动”。