技术6 分钟阅读

Vision-first 与 CSS 选择器：为什么坐标点击更稳定

当页面结构变化时，选择器很容易失效。Vision 分析通过截图识别元素，而不是依赖脆弱的 DOM 路径，因此更稳定。

2026年4月8日

反检测工作流中的选择器问题

CSS 选择器是自动化工具在页面上查找元素的默认方式。您编写一个路径，如 `button.submit-btn` 或 `#login-form input[name="email"]`，脚本就会点击或填充它。这在标记不变时有效——但在反检测工作流中，标记不断变化。

不同的浏览器配置文件可以看到不同的页面版本。A/B 测试、地理位置定向布局、同意横幅、机器人检测挑战和动态类名都会在会话之间改变 DOM。在配置文件 #1 中有效的选择器可能在配置文件 #12 中不存在。

为什么选择器比您想象的更容易破裂

动态类名——React、Next.js 和 Tailwind 等框架生成在构建之间变化的哈希或实用程序类。针对 `.css-1a2b3c` 的选择器在下一次部署后停止工作。
A/B 测试——同一 URL 可以向不同的访问者提供完全不同的 DOM 结构。您的选择器假设一个变体；页面显示另一个。
同意和 cookie 横幅——这些覆盖层注入新元素、改变 z-index，有时会将整个页面包装在编写选择器时不存在的容器中。
机器人检测覆盖层——Cloudflare 挑战、DataDome 插页式广告和类似系统用自己的标记替换页面内容。当页面本身消失时，任何选择器调整都无法帮助。
区域和地理差异——RTL 布局、翻译的按钮文本和特定地区的 UI 组件都会改变 DOM 树。

在单浏览器脚本中，您一次一个地注意并修复这些问题。在 50 个配置文件的批次中，损坏的选择器在任何人发现之前会在数十个会话中无声地失败。

视觉优先交互如何工作

视觉优先意味着 AI 对页面进行屏幕截图并进行视觉分析——就像人类看屏幕一样。它不是在 DOM 中搜索特定选择器，而是通过外观识别元素："页面中心的蓝色注册按钮"。

流程很直接：

对当前页面状态进行屏幕截图
将其发送到识别交互元素及其位置的视觉模型
为每个检测到的元素返回规范化的边界框（坐标）
使用这些坐标点击、悬停或交互——不需要 DOM 查找

// Vision-first click flow
await browser_parallel_navigate({ url: "https://target.example/signup" });
const grouped = await browser_parallel_vision_analyze_grouped();
// AI identifies elements visually across all active browsers
// Returns normalized bounding boxes for each element
await browser_parallel_click_normalized_box({ box: signUpButton.box });

坐标点击 vs 选择器点击

选择器点击说"在这个 DOM 路径找到元素并点击它"。坐标点击说"在屏幕上的这个位置点击"。当页面分散时，差异很重要。

基于选择器的方法

// Breaks if class name changes, element moves, or overlay appears
await page.click("button.btn-primary.submit-action");
// Breaks if form structure changes
await page.fill("#signup-form input[type=email]", "user@mail.com");

基于视觉的方法

// Works regardless of class names, IDs, or DOM structure
await browser_parallel_screenshot();
const analysis = await browser_parallel_vision_analyze_grouped();
// AI finds "Sign Up" button visually — same as a human would
await browser_parallel_click_normalized_box({ box: analysis.signUp.box });

视觉方法不关心类名、ID 或嵌套深度。如果按钮在屏幕上可见，就会被找到。这在反检测场景中特别强大，其中每个配置文件可能呈现略有不同的页面。

批量操作的分组分析

运行 20+ 个浏览器配置文件并行时，视觉分析需要高效。Ornold 使用分组分析——它从所有活跃会话获取屏幕截图，将它们作为批次发送到视觉模型，并在一次调用中返回每个会话的结果。

这很重要有两个原因：

效率——一个 API 调用处理所有会话，而不是 N 个单独的调用。无论批次大小如何，延迟大致保持不变。
分散处理——AI 看到每个会话的实际状态。如果配置文件 #7 有 CAPTCHA 覆盖层，而其他的显示表单，分组结果会反映这一点。您可以为每个会话分支逻辑，而不是假设所有页面看起来相同。

// Grouped vision analysis across all active browsers
const results = await browser_parallel_vision_analyze_grouped();
// results.groups shows which browsers are in which state
// e.g., 15 browsers on the form, 3 on CAPTCHA, 2 on error page

DOM 模式仍然获胜的时候

视觉分析并不总是正确的选择。基于 DOM 的交互（Ornold 的默认模式）对于具有稳定标记的结构化页面来说更快、免费且完全可靠。

在以下情况下使用 DOM 模式：

目标页面具有稳定、可预测的 HTML（例如，您自己的应用程序、知名平台）
您正在填充具有清晰输入字段和标签的表单
速度比弹性更重要——DOM 快照是即时的，视觉分析需要 1-3 秒
您想避免视觉信用成本

在以下情况下使用 Vision 模式：

页面在配置文件之间变化（A/B 测试、地理位置定向、动态布局）
您正在处理基于 canvas 的 UI、图像丰富的页面或自定义 web 组件
选择器不断破裂，维护成本很高
您需要验证页面实际上是什么样子（视觉 QA）

您可以同时启用两种模式。AI 代理会自动为每个操作选择最佳方法——简单表单填充使用 DOM，复杂或不可预测的页面使用视觉。

真实世界比较

以下是在 30 个 Linken Sphere 会话中运行注册流程时实际发生的情况：

基于选择器的自动化

30 个会话中的 25 个成功完成
3 个失败，因为同意横幅改变了表单布局
1 个失败，因为 Cloudflare 提供了插页式广告页面
1 个失败，因为网站在运行中部署了新版本，具有不同的类名
总计：83% 成功率。5 个会话需要手动干预。

基于视觉的自动化

30 个会话中的 29 个成功完成
1 个失败，因为页面未加载（网络超时——不是选择器问题）
同意横幅、布局移位和类名更改没有任何影响
总计：97% 成功率。超时需要一次重试。

随着批次大小的增加，差距会扩大。在 50+ 个配置文件处，基于选择器的自动化通常需要持续维护。基于视觉的自动化保持稳定，因为它适应屏幕上实际显示的内容。

在 Ornold 中设置 Vision 模式

将 AI 代理连接到 Ornold MCP 时启用 vision 模式。在仪表板向导中，在第 2 步选择"两种模式"以获取 DOM + Vision 工具。或手动添加标志：

# Claude Code — enable both DOM and Vision modes
claude mcp add --transport stdio ornold-browser -- npx ornold-mcp --token YOUR_TOKEN --mode both --linken-port 40080

# Codex — in config.toml
[mcp_servers.ornold-browser]
command = "npx"
args = ["ornold-mcp", "--token", "YOUR_TOKEN", "--mode", "both", "--linken-port", "40080"]

每个视觉分析成本 1 个信用。DOM 快照是免费的。启用"两种模式"后，AI 代理默认使用 DOM，仅在需要时切换到视觉。

关键要点

CSS 选择器假设稳定的 DOM。在反检测工作流中，DOM 是任何东西但不稳定。
视觉优先交互通过外观而不是路径查找元素。它自动适应布局变化、覆盖层和 A/B 测试。
分组视觉分析处理批次分散——每个会话根据其实际状态进行分析。
DOM 模式仍然是速度和成本的最佳默认值。当页面不可预测或选择器不断破裂时使用视觉。
两种模式可以共存。让 AI 代理为每个操作选择正确的工具。

解析