传统 UI 自动化最难的从来不是”点哪里”，而是”这个元素在下一版会不会换 class name”。Playwright、Puppeteer、WebDriver 把这层痛喂给工程师十年，现在有人换了个思路：既然模型能看图，为什么还要维护选择器？
Midscene 是字节 web-infra 团队开源的 GUI Agent 框架，2026 年上半年从 GitHub 趋势榜第二一路涨到 14k star。表面上看它是”把截图丢给多模态模型、返回点击坐标”的又一个自动化工具；但如果只这么看，就会错过它更值钱的部分——在 1.0 版本里，它把”提取 DOM 做兜底”这条 fallback 明确砍掉了。
这不是一个小决定。这意味着团队公开赌一件事：VLM（视觉语言模型）的 Visual Grounding 能力已经稳到可以撑起生产级 UI 自动化，不再需要 DOM 做保险。
这篇文章想做两件事：一是用决策地图格式，把 Midscene 六个能观测到的关键设计选择拆开，每个选择配上约束、反事实、收敛度；二是回答一个更根本的问题——“看图点按钮”这件事，为什么直到 2025-2026 年才真正成立？
先给一句可证伪的核心判断：
Midscene 之所以敢在 1.0 砍掉 DOM 备胎，是因为一旦 VLM 能稳定输出像素级坐标，DOM 标注就从”补充信息”退化成”技术债”——它多消耗 token（一个电商首页动辄多传 5000+ tokens），限制可覆盖场景（Canvas、跨域 iframe、桌面原生 UI 全部拿不到 DOM），却不再给决策提供 VLM 之外的独立信号。
如果这句判断错，能怎么证伪？很简单：如果 VLM 的坐标输出误差还在 20-40px 量级（2024 上半年之前的 GPT-4o、Claude 3.5 就是这个水平），那 Midscene 就必须留着 DOM 做兜底、否则复杂控件根本点不准。这个约束一旦松开，DOM 才变技术债。
名词速查
这篇涉及几个不太日常的词，先摊开一张表，避免阅读中断：
| 名词 | 一句话解释 |
|---|---|
| Playwright / Puppeteer | 微软 / Google 出的浏览器自动化框架，用 DOM 选择器（CSS/XPath）定位元素后调用 .click() / .fill() |
| DOM 选择器 | #login-btn、div.card > a:nth-child(2) 这种基于 HTML 结构的元素定位串 |
| VLM (Vision-Language Model) | 多模态大模型，既能看图又能读文字，如 GPT-4o、Qwen2.5-VL、豆包 Seed |
| Visual Grounding | VLM 的一项子能力：输入”图 + 一句自然语言”，输出目标物体在图上的坐标（bbox 或点）。这是 Midscene 一切设计的地基 |
| UI-TARS | 字节 2025 年开源的、专门为 GUI 操作训练的 VLM，Visual Grounding 能力对齐了 GPT-4o 级别但开源可自托管 |
| Deep Think | Midscene 提供的可选定位策略：先粗定位到一个区域，再在裁剪后的小图上二次定位，用两次调用换更准的坐标 |
| Instant Actions | Midscene 的 aiTap / aiInput / aiScroll 一族接口，跳过 LLM 规划、直接把”我要点哪个”交给 VLM 定坐标 |
一、决策地图：Midscene 的六个岔路口
Midscene 从 0.x 走到 1.x，能观测到六个明确的设计岔路。每个岔路我用一样的三段结构：约束 → 传导 → 收敛度。收敛度指”业内普遍走这条路吗”——收敛度高说明这是共识，低说明是 Midscene 押的独门。
决策 1：怎么定位元素——选择器 vs 视觉？
约束：Playwright / Puppeteer 十年的经验告诉我们，脆弱的不是 DOM 本身，而是”人写的选择器”：一个 #login-btn 在改版后变成 #authBtn，几百个 e2e 用例集体炸掉。业界不是没试过修，从 XPath 到 Accessibility Locator、从 Testing Library 的 getByRole 到 Playwright 的 getByText——每一次都是把”人给元素起个稳定名字”的负担挪个位置，没能消掉。
传导：Midscene 的选择是彻底跳过这一步。用户描述”登录按钮”，模型看图直接给坐标。这条路能成立的前提是：模型看到”登录按钮”四个字后，能可靠地在截图上找到那颗按钮，并输出准确的 (x, y)。这个能力叫 Visual Grounding，2024 年 Qwen2-VL 发布之后才真正跨过”生产可用”的门槛，2025 年 UI-TARS、Qwen2.5-VL、豆包 Seed 又把它推到 90%+ 的 UI 定位准确率。
收敛度：高。同期还有 Browser Use、Anthropic Computer Use、Skyvern，全部走视觉路线。这是行业共识，不是 Midscene 的独门。真正独门的是接下来那步。
决策 2：为什么 1.0 砍掉 DOM 兼容？
这是我认为 Midscene 最值得盯的一个决策。
约束：0.x 版本的 Midscene 用的是混合方案：JavaScript 先从页面 DOM 里提取元素 + 坐标 + 类型，把这些”候选元素”标注到截图上（画方框 + 编号），然后把标注图 + DOM 摘要一起丢给通用 LLM（比如 GPT-4o），让模型输出”我要点第几号”。这是当时通用 LLM 数值输出不准（不敢直接让它输出像素坐标）时的自然选择——让 LLM 做选择题，别让它做填空题。
这个方案的问题在官方博客里说得很直白：
- 1280×800 分辨率下，eBay 首页要传 6000 tokens 输入，搜索结果页 9000 tokens——这些额外 token 全部是 DOM 树，不是截图。
- 遇到
<canvas>、跨域 iframe、原生 App 时，DOM 直接消失，方案降级。 - 图像分辨率超过约 2000×768 就不好处理。
我们可以手算一下这条约束的量级。假设一个现代 SPA 首页大概 300-500 个可交互元素，每个元素的角色 + 层级 + 文本平均 15-20 tokens，光 DOM 侧就要 4500-10000 tokens。而一张 1280×800 的截图，在 GPT-4o 的 tile 编码规则下大概是 1105 tokens——DOM 端的 token 消耗，普遍是截图端的 5-10 倍。
传导：一旦 VLM 具备可靠的 Visual Grounding（决策 1 的前提），DOM 端的这几千 tokens 就从”补充信号”变成”纯浪费”——模型看图就能点，DOM 只是让上下文更贵、让延迟更长、让 Canvas/原生 App 场景强制降级。
Midscene 1.0 的选择是只保留纯视觉路线，DOM 只在数据提取场景按需附带。这一刀砍下去，等于对外承诺：“如果你选了我推荐的 VLM，我保证不用 DOM 也能定位。”
收敛度：低。这是押注。同期 Playwright MCP、Steel Browser 这类 agent-friendly browser stack 依然保留 accessibility tree 做主定位、视觉做备胎；Anthropic Computer Use 也是”截图 + 坐标 + 键鼠”混合。Midscene 是我见过最激进的”只留一条路”派——赌 VLM 能力已经稳到不需要备胎。
反事实：如果 2026 年 VLM 的坐标误差回退到 30px 以上，Midscene 会被迫加回 DOM fallback；反过来说，Midscene 敢砍 fallback，本身就是对当前 VLM 能力的一份公开信号。
决策 3：模型分工——单模型 vs 三角色（Base / Planning / Insight）？
约束：GUI 任务其实是三件不同的活拼在一起：
- 规划（Planning）：把”注册一个 GitHub 账号”拆成”打开注册页 → 填用户名 → 填邮箱 → 点提交”这样的步骤序列。这是文本推理任务。
- 定位（Locate）：截图上”提交按钮”在
(x=612, y=384)。这是纯视觉任务。 - 理解 / 断言（Insight）：从截图里提取”用户余额 = 128 元”，或判断”这个页面是不是登录成功的样子”。这是视觉+推理混合。
这三件事对模型能力的要求根本不一样。一个纯 Visual Grounding 模型可能坐标定得极准，但让它规划一个 20 步的注册流程就会崩；一个通用推理强模型可能规划得漂亮但坐标经常偏 50 像素。
传导：Midscene 提供两档配置：
- 默认单模型：一个多模态模型（豆包 Seed / Qwen3.x / GLM-V / Gemini 3.x 都行）从头包到尾。开箱即用，多数场景够用。
- 多模型协作：允许你把 Planning 和 Insight 单独指到能力更强但更贵的模型上，让 Base 只做便宜的元素定位。
官方的原话很克制：
“从默认模型开始，仅在遇到明确的能力瓶颈时引入专用模型。”
收敛度：中。这是标准的”简单默认 + 可选高级”分层设计。真正有意思的是把 Locate 和 Planning 在接口层分开——这就引出下一条。
决策 4：agent.ai() 全流程 vs Instant Actions？
约束：如果我已经明确知道下一步就是”点登录按钮”，为什么还要跑一遍规划？
我自己在写 ego-browser skill 相关内容的时候踩过这个坑。让 LLM 一步”规划 + 执行”最简单的点击，会得到一段长达几百 token 的思考链：“我看到页面上有一个搜索框、一个登录按钮、一个横幅广告……用户的意图应该是点击登录按钮，因为……”——规划 token 消耗是定位 token 消耗的 5-10 倍，而且延迟高一到两秒。 而其实我早就知道要点哪个按钮，我只是不知道它在第几个像素上。
Midscene 明确把这两件事拆成两组 API：
| 场景 | 接口 | 内部流程 |
|---|---|---|
| 我知道要做什么，只需要它点准 | aiTap("登录按钮") / aiInput("你好", "搜索框") / aiScroll(...) | VLM 只做 Locate，跳过 Planning |
| 我给一个模糊目标，让它自己想怎么做 | agent.ai("注册一个新账号并验证邮箱") | 完整 Planning → Locate → Act → 验证循环 |
对应的 v0.14 官方例子把差别说得很清楚：
// 传统 planning：一次调用触发完整"想 + 干"链
await agent.ai('在搜索框中输入 "Headphones"，按下回车键');
// Instant Actions：跳过 planning，只让 VLM 定坐标
await agent.aiInput('Headphones', '搜索框');
await agent.aiKeyboardPress('Enter');传导：这是把决策 3 里的”能力分工”落到了 API 层——用户按”这次到底需不需要规划”选接口，而不是让框架帮你猜。 已知操作用 Instant Actions（快、省、稳），探索性任务用 agent.ai()（灵活但贵慢）。
收敛度：中偏低。Playwright MCP / Browser Use 也在往这个方向靠，但 Midscene 是把它做成一等公民 API 的少数之一。传统认知里”AI 自动化”约等于”给个自然语言意图就自动完成”，Midscene 反过来告诉你：很多时候你其实已经想清楚了，缺的只是那颗按钮的坐标，别让 LLM 陪你重新想一遍。
决策 5：一次定位 vs Deep Think 二次聚焦？
约束：VLM 再好，也有一个共同弱点——目标越小、越挤、越同质，坐标越容易漂。 想象 Coze 工作流编辑器侧边栏那种十几个近似的小图标挤在一起，或者一个复杂 iOS 设置页里连续三个开关。让模型在整张 1280×800 图上一次性给出精确坐标，误差经常 20-40 像素——刚好错到隔壁那个按钮上。
传导：Midscene 加了个可选参数 deepThink: true：
- 第一次调用：VLM 在完整截图上大致定位到”目标应该在这块区域”，输出一个粗 bbox。
- 第二次调用：把这个 bbox 裁出来放大成新图，再让 VLM 精定位。
- 把第二次的坐标反变换回原图。
这本质上是空间维度的 Chain-of-Thought——用两次前向换一次更准的输出。代价是延迟翻倍、token 翻倍；收益是复杂 UI 的定位准确率显著提升。
有个隐藏约束值得注意：deepThink 只对原生视觉定位模型（Qwen2.5-VL、UI-TARS 类）生效，对 GPT-4o 这种”看图但不做 Visual Grounding”的通用多模态模型没意义。因为这类模型看更大的图或更小的图，坐标误差量级差不多——放大裁剪救不了它。
收敛度：低。业界很少有框架把”二次定位”做成一等参数暴露给用户；更多的是内部隐式做或者不做。Midscene 把这个策略选择权交给用户，是承认”没有一个模型能同时兼顾快和准”——要准就多付一次调用。
决策 6：跨平台胶水 vs 统一截图接口？
约束：Playwright 只管浏览器；Appium 只管移动端；WinAppDriver 只管 Windows；macOS 桌面要用 AppleScript / Accessibility API。一套自动化脚本想同时覆盖 Web + Android + iOS + 桌面，工程师要学四套 API、四种元素模型、四种等待机制。
传导：Midscene 的观察是——如果所有平台都能截图、都能接受”在 (x, y) 处点击”这两条原语，那 VLM 之上完全可以只有一套 API。 每个平台只要写一个薄薄的 adapter：把截图捞出来 + 把坐标翻译成对应平台的点击事件。
于是 aiTap、aiInput 在 Chrome 上就是 CDP 事件，在 Android 上就是 adb shell input tap，在 iOS 上就是 WDA 的坐标点击，在 macOS 上就是 CGEvent。上层用户完全看不到这个差异。
benchmark 层面这条策略是有数据支撑的：AndroidWorld 93.1% / MobileWorld 78.6% / AppControlBench 96.7% Pass@1，说明”截图 + VLM”这条路在原生 App 上（那里根本没 DOM）反而比 Web 表现更好。这不是意外——原生 App 的控件更规整、干扰更少，正是 Visual Grounding 的舒适区。
收敛度：中。Anthropic Computer Use、UI-TARS、Simular AI 都在这条路上；差别是 Midscene 把 API 表面做得更薄、更贴近开发者习惯（aiTap('登录') 比”用鼠标点击第 3 号窗口的 (612, 384) 像素”直接得多）。
二、一次亲身对比：为什么”Instant Actions”是 Midscene 最值钱的一步
我在维护 ego-browser 相关 skill 的时候，反复被同一件事咬到：让 LLM 自己规划”下一步做什么”，在简单场景下是纯粹的浪费。
举个具体的：让 agent”打开 GitHub 通知页面标记全部为已读”。这是一个五步的直线任务：
- 打开
/notifications - 找到 “Mark all as read” 按钮
- 点击它
- 处理确认弹窗
- 验证列表清空
如果全交给 agent.ai() 完整规划：
- 每一步都要重新截图 + 重新描述当前页面 + 重新推理”接下来该干什么”
- 因为模型不知道”我上一步刚点了 Mark all”，它可能会再规划一次点击（除非上下文里明确告诉它状态）
- 每步 300-800 token 规划输出 + 一次坐标输出
如果拆成 Instant Actions：
await page.goto('/notifications');
await agent.aiTap('Mark all as read 按钮');
await agent.aiTap('确认对话框上的 Confirm 按钮');
await agent.aiAssert('通知列表已清空');每一步都是”我人类知道要干嘛，你只负责认按钮和点它”。 Token 消耗直降到只剩定位那一次调用的量级，速度快 3-5 倍。
这就是 Midscene 决策 4 那把刀最锋利的地方：它承认 LLM 的规划能力不是每次都必要，反而定位能力是每次都必要。前者可以外包给写代码的人（用 if / for / try），后者才是必须让模型做的。这是把”AI 应该做什么、人应该做什么”的分工，从口号落到了 API 层面。
这个洞察不是 Midscene 独家的——2026 年上半年整个 agent 领域都在往”planning cheap / locate expensive”这个共识收敛（可以参考我 8 月那篇 Agent 如何控制浏览器：从 HTTP、DOM、CDP 到视觉与混合自动化，那里我从另一个角度也拆过类似的六阶段闭环）。但 Midscene 是我见过把它做进 API 命名的最干脆的一家。
三、反事实断点：如果没有 Visual Grounding，这套设计会崩在哪一步？
想彻底理解 Midscene 的形状，把它的地基抽掉试试。
假设：把它切换到 2024 年初的 VLM（GPT-4V early、Claude 3 Opus early），Visual Grounding 误差 30-50 像素。会发生什么？
断点 1：决策 5 的 deepThink 从”可选参数”变成”默认必开”，甚至要开三层。每次交互 3-5 次前向调用，延迟到 5-10 秒。工程上勉强能用，产品上不能用。
断点 2：决策 2 的”砍掉 DOM 兼容”根本走不通。工程师会强烈要求 fallback，一旦坐标点偏就需要 DOM 补救，否则脚本靠人工重跑。1.0 里保留 DOM 提取通道会成为唯一现实选项。
断点 3：决策 6 的跨平台统一 API 会失效。因为 Web 端至少还有 DOM 兜底，而原生 App 场景根本没退路，VLM 坐标一漂就直接死。跨平台的胶水层会分裂成”Web（视觉+DOM）“和”原生（视觉+人工修）“两套。
也就是说，决策 2、5、6 的形状全部由 Visual Grounding 的精度决定——这条能力线一旦回退，Midscene 的产品形态会自动倒退到 0.x 那种”标注 + 选择题”的混合方案。
反过来看：Midscene 敢在 1.0 押上这三条，是对 VLM 现状的一份公开信任状。它选谁做默认模型（豆包 Seed / Qwen3.x / GLM-V / Gemini 3.x），就是它相信谁在 Visual Grounding 上过了生产门槛。
四、共同祖先：这其实是老 Agent 循环的一次 GUI 再实例化
如果把 Midscene 放回 Agent 老架构：
感知 (Sense) → 决策 (Plan) → 执行 (Act) → 验证 (Verify) → 循环它做的其实是把每一格换了个新的 primitive：
| 阶段 | 传统 Web 自动化 | Midscene 视觉 Agent |
|---|---|---|
| 感知 | DOM 树 + Accessibility 树 | 屏幕截图（+ 可选 DOM，仅提取时） |
| 决策 | 人写的脚本（Playwright locator + .click()） | LLM 规划（可选）或人写 Instant Actions |
| 执行 | Playwright API → CDP / WebDriver | VLM 输出坐标 → 平台原生点击 API |
| 验证 | Assertion on DOM | VLM 断言 on 截图（aiAssert） |
从这个视角看，Midscene 不是”发明了一种新自动化”，而是把感知层从”字符树”换成了”像素图”，把定位从”字符串匹配”换成了”视觉 grounding”。这条主线在 CV 领域从 SAM（Segment Anything）到 GroundingDINO、再到 UI-TARS，已经走了三年——Midscene 是把这条主线的下游成果封装成开发者友好的 API 的一家。
理解了这一点，就会明白为什么它 API 命名叫 aiTap 而不是 visualClick：它想强调的不是”用视觉”，而是”这次点击是被 AI 定位的”。定位方式（视觉 or DOM）是实现细节；决策权（AI 还是人）才是抽象边界。
小结
一句话压缩：Midscene 1.0 的形状 = Visual Grounding 现在够稳（→ 砍 DOM 备胎、砍跨平台胶水） × Planning 太贵 Locate 便宜（→ 拆出 Instant Actions） × 少数场景仍需二次聚焦（→ Deep Think 作可选）。
反事实断点：把 VLM 换回 2024 上半年的水平，决策 2、5、6 会自动倒退，产品会变回一个”DOM+标注+LLM 选择题”的混合方案。
给读者的 takeaway：看一个 AI 产品的设计选择，看它砍了什么比看它加了什么更值得盯——加的东西可能只是功能，砍的东西一定是团队对某项模型能力的公开信任。
想动手 5 分钟看看差异？
如果你现在手边正好有一个自动化痛点（哪怕只是”每周登录 XX 后台点几个按钮导数据”），最便宜的验证路径：
- 装 Midscene 的 Chrome 扩展（浏览器插件，不需要写代码）。
- 用它的 Playground 在自己的目标页面上分别试两句：
- “点击登录按钮”（这走 planning + locate）
- 然后打开开发者模式看 aiTap 直接调用（这走 pure locate）
- 观察两者的响应时间和 token 消耗。差异会告诉你——你的自动化任务，到底需不需要花钱让 LLM 规划。
成本大概是几毛钱 API 调用 + 一杯咖啡的时间。比读完这篇再决定”要不要引入 Midscene”划算得多。
参考资料