界面定位

A44
概念 · 智能体 AI 详解

界面定位。

一个点在「保存」按钮左边 40 个像素处的计算机操作智能体,和一个决定删掉文件而不是保存它的计算机操作智能体,都把你的任务搞砸了,而你的链路记录对这两者显示的是同一件事:有一步没成。它们需要的修法恰好相反,而几乎没人把它们分开——这正是为什么会有团队花一个季度改写规划提示词,去修一个坐标问题。定位是那个把「保存那个控件」变成某块特定屏幕上一个点的组件,而它是另一个模型:用另一套基准来量,以另一种方式失败,跟那个「决定去保存」的模型不是同一个。

STEP 1

一个界面步骤里装着的两个决定。

智能体在屏幕上做的每一个动作,都依次解决两个问题。接下来该发生什么——点保存、往下滚去找总计、关掉刚弹出来的对话框——这是一个规划问题,答案来自任务、历史,以及这块屏幕看上去装着什么。而那个动作落在哪里,是一个感知问题,答案来自像素:这张 1,512×982 的截图里,哪一个矩形是保存控件,它的坐标是多少。

在一个由 API 驱动的智能体循环里,第二个问题压根不存在。一次工具调用会点名它的目标——save_document(id)——再由外壳去解析它。而在屏幕上没有标识符,所以必须有某个东西去发明一个出来。那个东西就是定位模型,而在多数栈里,它字面意义上就是一套独立的权重、挂在一个独立的端点上。

「你遇到的是定位问题而不是推理问题」的破绽在于:智能体自己的叙述是对的。它说自己正在点保存,轨迹里记下了一次点击,而文件没被保存。规划失败通常叙述的是错的意图;定位失败叙述的是对的意图,然后打偏了。

STEP 2

像素、树,以及为什么这个选择通常由不得你。

找到一个控件有两种办法,而它们的好坏并不相当——两者都存在的原因是,更好的那种经常用不上。

  • 结构化观察。浏览器里的 DOM,或桌面上的平台无障碍树——Windows 上的 UI Automation、macOS 上的 Accessibility API、Linux 上的 AT-SPI。元素送过来时,角色、名称与包围盒都已经算好了。定位于是变成一次查表而不是一次预测,这让它便宜、快,而且几乎精确。
  • 视觉定位。一张截图进去、坐标出来,由一个为此训练的视觉语言模型给出。对 canvas 渲染的应用、远程桌面与 Citrix 会话、自绘控件、没有实现无障碍接口的原生应用,以及任何藏在屏幕共享后面的东西,它是必需的。它更慢,每一步要花一次视觉前向传播,而它是唯一一种在哪儿都能用的办法。

有结构的地方就优先用结构,没有才退回像素——成熟的外壳做这个取舍是按界面、而不是按项目。这次退让的代价不只是准确率:像素定位把你绑在一个分辨率和一个缩放系数上,于是同一个在你笔记本上能用的智能体,到了 150% 缩放的 4K 显示器上就会打偏;而一张视网膜截图若在推理前被降采样,那个 11 像素的图标就整个丢掉了。

STEP 3

基准是分开的,而这恰是重点。

定位有它自己的评测,而这些评测的存在,正是「它是一个独立组件」最干净的证据。ScreenSpot 一类的基准,递给模型一条指令和一张截图,只要一个坐标——没有规划、没有多步执行、没有环境。而像 OSWorld 这样的任务基准,量的是一整个智能体完成真实工作流,所以从其中一个得到的数字,对另一个几乎什么都说明不了。

两者之间的落差很有启发。在消费级界面上已发表的定位准确率能跑到 90 多,而高分辨率专业软件上的定位要低得多,长程基准上的端到端任务完成率还要更低。这些并不是互相矛盾的结果;它们是三种不同的测量,而这个栈的天花板由「对你的界面而言最差的那一个」定下。如果你的应用是一个密集的 CAD 或交易界面,那个消费级界面的数字与你无关。

在改任何东西之前,先把你自己五十条失败轨迹标成「点错元素」与「走错步骤」两类。它大约花一个小时,而它正是那个会告诉你「该换定位模型、该给那个界面加上结构化观察、还是该重写规划器」的测量——这三种干预之间一行代码都不共享。没有它,你就是在三个各花一个季度的修法之间凭感觉选。

STEP 4

为什么定位失败的危险性格外大。

推理失败通常产出一次拒绝、一次打转,或一个明显错了的计划。而定位失败产出的是一个落在错误对象上的自信动作——那正是能混过复核的那种形状。

  • 错了一行。智能体想的是第三张发票,点到了第四张。下游的一切在内部都自相一致,而指向的是错的实体,并且链路记录里没有任何东西会标出它。
  • 按钮挪了。在截图与点击之间,某个对话框移了 30 个像素——一条晚加载的横幅、一条通知、一段还没安定下来的动画。智能体点在了控件原来所在的位置。见检查时刻与使用时刻;一块屏幕是一次可变的观测,而「看见」与「动手」之间那个窗口是真实存在的。
  • 紧邻即破坏。界面常把「归档」摆在「删除」旁边、把「保存」摆在「放弃」旁边。一个控件宽度的定位误差,就是一次空操作与一次不可逆动作之间的差别——这正是为什么对图形界面智能体谈爆炸半径时,必须假定那一下点在了隔壁。
  • 无声的坐标漂移。一次主题切换、一个浏览器缩放设置,或一次操作系统更新,就把一切挪了几个像素。准确率逐渐退化,没有报错,也没有哪次发布可以怪。

结构性的回应是:别再把「点下去了」当成「动作发生了」的证据。请通过一条智能体没有用来执行动作的通道去核验副作用——重读那条记录、查一下 API、对一下状态差异——并把一个无法核验的步骤当成失败而不是成功,这跟击败失败隐瞒是同一种纪律,尽管理由完全不同。

STEP 5

这会改变你怎么买、怎么造。

把定位当作一个有自己需求的可采购部件来对待,因为它就是。

  • 它是你能固定下来的那一块。开放的定位模型以宽松许可证发布权重,所以在一个计算机操作栈里,这是唯一一层你能把行为冻住、在本地跑、并在自己的界面上微调的——而这对那些通用模型最弱的密集专业软件,恰恰最要紧。
  • 它也是厂商藏起来的那一块。一个托管的计算机操作 API 只给你整个循环的一个分数。它退化时,你分不出是规划动了还是定位动了,而两者你都修不了。
  • 把截图留下来。一次定位失败,有截图加上那个预测坐标就无从辩驳,而没有它们就无从调查。逐步留下这两样,才让 STEP 3 里那一小时的标注成为可能。
  • 把重复的那条路径编译掉。如果同一串序列在一个不变的界面上每天跑几百次,那么每次运行都重新推导一遍坐标,买到的是方差和一张账单。请把它录一次,然后重放一个固定序列,并附上一道副作用检查。

一条具体的默认做法:对任何暴露了 DOM 或无障碍树的界面,就对着树做定位,只用视觉模型去消歧。你会放弃「纯像素单一流水线」那份优雅,换回你大部分失败的步骤——因为生产中的定位错误,多数发生在那些「在一个没人读过的结构里被完整描述过」的控件上。