屏幕截图扔进去，一句中文指令丢进去，模型直接吐出 [x,y] 坐标——这就是蚂蚁 inclusionAI 刚扔上 HuggingFace 的 VISTA-4B 在做的事。它不画 UI、不生成代码、不写自然语言回复，只回答一个问题：用户说的那个按钮在屏幕的哪个像素？对于做桌面自动化、RPA、Agent 落地的团队来说，这个颗粒度的模型反而是刚需——你不需要它"理解"界面，你只需要它"找得到"。
模型骨架：4B 参数，刚刚好够用
为什么是 Qwen3.5-4B，而不是更大的
VISTA-4B 没有自己从头训一个视觉编码器，也没有套用 70B 级别的语言模型当大脑。它直接拿 Qwen3.5-4B 当骨干——这个尺寸卡在一个很微妙的位置：4B 的多模态理解能力已经被前几代 Qwen 验证过足够覆盖 GUI 场景，同时单卡推理成本可控，本地部署门槛低。对做 Agent 的人来说，"能跑在一张消费级显卡上"比"刷榜高 0.5 分"重要得多。inclusionAI 显然想清楚了这件事：与其卷参数量，不如把同样的 4B 榨干到 GUI 这个垂直赛道的极限。
输入输出协议，简单到粗暴
接口设计没有花活。截图加一句自然语言指令，模型吐出归一化到 0-1000 的坐标。这套协议意味着前端传一个分辨率任意的截图，后端不用做任何 padding、resize、归一化预处理，坐标直接拿来乘以屏幕宽高就能用。写 Agent 脚本的人最痛恨的就是输入输出格式不统一——VISTA-4B 这种"塞进去、吐出来"的极简设计，省掉的不是几行代码，是一整个数据预处理管道的维护成本。
训练方法论：两个名字很长但思路很朴素的技巧
视图一致 GRPO：让模型学会"换角度看问题"
GUI 截图的最大麻烦是同一个按钮在不同分辨率、不同 DPR、不同主题下长得完全不一样。inclusionAI 引入了视图一致 GRPO 训练策略，本质是把"同一界面元素在不同视觉条件下被正确指认"作为奖励信号。模型如果只在高分辨率训练集上表现好、在低分辨率截图上指不准，奖励就低。这相当于在强化学习阶段强制模型建立"坐标级视觉不变性"——一个按钮不管缩放到什么比例，落在屏幕的哪个位置，模型都得能戳中。比起传统 SFT 的硬标注，GRPO 的好处是它能容忍标注噪声，模型自己学会"哪些点击是对的、哪些是错的"。
自验证交叉视图锚定：让模型在训练时自己挑错
第二个创新点更狠：自验证交叉视图锚定。训练过程中，模型会被要求对同一界面元素在不同视角（不同分辨率、不同渲染状态）下都给出坐标预测，然后这些预测之间互相校验——如果模型在不同视图下给出的坐标一致，就给正向锚定；不一致就触发自验证回路重新调整。这种"自己给自己出考题"的训练范式，在视觉 grounding 领域并不新鲜，但用在 GUI 这种元素密集、布局高度结构化的场景里，效果放大得很明显。它本质上解决了 GUI grounding 最大的痛点：模型会"幻觉坐标"——明明界面上没有那个按钮，模型偏要指一个位置。自验证机制相当于给幻觉装了一个刹车。
基准表现：小幅刷新，不是碾压
SSPro 与 SSV2：一张一卡的微妙平衡
直接看数字。SSPro 得分 64.2，相比同尺寸的 GRPO-4B 基线提升 2.0；SSV2 得分 93.8，反而微跌 0.4。这组数据说明一个事实：VISTA-4B 在"屏幕截图理解"这条更细粒度的赛道上进步明显，但在"网页截图元素定位"这种已经接近饱和的任务上，优化反而带来了一点 trade-off。93.8 这个分数本身已经在天花板附近，0.4 的波动大概率是测试集分布差异而非真实能力退化。换句话说，inclusionAI 用 SSPro 的进步换了 SSV2 的微弱让步——这个交换在商业落地场景里是划算的，因为 SSPro 更贴近真实桌面软件的复杂度。
OSWorld-G 与 OSWorld-G-R：Agent 落地最看重的两个数字
OSWorld-G 拿到 61.2，提升 1.3；OSWorld-G-R 拿到 69.7，提升 0.5。这两个基准才是真正决定 VISTA-4B 有没有人用的关键。OSWorld-G 系列评测的不是"模型能不能看懂界面"，而是"模型给出的坐标能不能让 Agent 真的完成任务"——它会模拟真实操作系统环境，根据模型的坐标点击来验证操作是否成功。61.2 的绝对分不算高（人类基线在 70+），但 1.3 分的提升对开源 4B 模型来说已经是实打实的工程价值。69.7 的 Refined 版本更进一步，专门测试模型在"多步任务、需要跨界面跳转"场景下的 grounding 稳定性——0.5 的提升看起来小，但这个分数段的边际收益本来就难拿。
落地建议：怎么用、怎么避坑
提示词工程：官方推荐的那套不能省
HuggingFace 仓库里直接给了推荐提示词模板，别自己瞎写。VISTA-4B 对提示词的格式有一定敏感性——指令表述方式、坐标输出格式的约束词，都会影响输出稳定性。官方模板的核心套路是：明确告诉模型"返回一个长度为 2 的列表 [x, y]，值在 0-1000 之间"，并在指令里精确描述目标元素的视觉特征而不是功能特征。"那个红色的关闭按钮"比"用来关闭窗口的按钮"效果更好——因为模型训练时看到的多是视觉特征标注，语义描述反而会让它去"猜"而不是"找"。
坐标后处理：别直接乘屏幕宽高
模型吐出的 0-1000 归一化坐标看似能直接用，实际落地时建议加一层 sanity check：检查坐标是否落在元素实际存在的 ROI 区域内、检查坐标是否对应可点击元素而非纯文本或装饰元素。VISTA-4B 的 61.2 分意味着大约 39% 的情况下，模型给出的坐标是不准确的——这不是模型差，而是 GUI 任务的本质难度决定的。生产环境里最好把 grounding 模型作为"粗定位器"用，后面再接一层基于图像相似度的精校准，或者直接让 Agent 在点击前截图比对一次。
与 Agent 框架的集成方式
目前主流的开源 Agent 框架（OSWorld、CUA、UI-TARS 系列）对 VISTA-4B 的支持还在跟进。如果是自己搭 Agent 流水线，最干净的做法是把 VISTA-4B 封装成一个独立的 grounding 服务，截图和指令通过 HTTP 传入，坐标 JSON 返回。这样做的好处是模型推理和 Agent 决策逻辑解耦——Agent 可以异步批量发起 grounding 请求，也可以根据任务复杂度决定要不要调用 grounding 模型（简单任务用规则引擎就够了）。4B 模型在单卡 A100/A10 上推理延迟可以压到 200ms 以内，这个响应速度对实时交互式 Agent 是够用的。
开源生态里的位置
不是另一个 UI-TARS，而是另一种选择
把 VISTA-4B 放进当前的开源 GUI Agent 生态里看，它的位置很清晰：UI-TARS 系列主打"大一统"——一个模型既做 grounding 又做 planning 又做 action，参数规模大、能力强但部署成本高；VISTA-4B 反过来，只做 grounding 这一件事，参数压到 4B，部署门槛降到消费级显卡。这种"垂直拆分"的思路在工程上更友好——你可以用 VISTA-4B 做 grounding，用一个更强的 70B 模型做 planning，两边各司其职，硬件预算也能分摊。对于不想被某个"全家桶"模型绑定的小团队来说，这种 modularity 反而是真正的自由。
蚂蚁 inclusionAI 的开源节奏透露的信号
从命名规范、技术报告的口径、HuggingFace 仓库的整洁度看，inclusionAI 这一轮的开源动作明显是有节奏的。VISTA-4B 不是孤立发布——它大概率是某个更大 Agent 工具链的一环，未来还会有 planning 模型、action 模型陆续放出。对于关注蚂蚁系开源项目的开发者来说，现在开始跟踪 inclusionAI 的仓库列表是值得的：他们的工程审美和文档质量在国内开源团队里属于第一梯队，README 里的提示词模板、推理脚本、评测脚本写得清清楚楚，省掉了大量二次开发的踩坑时间。
