首页 / 文章 / Cursor + BrowserAct 如何处理动态页面而不依赖脆弱选择器

← 返回

AI技术

Cursor + BrowserAct 如何处理动态页面而不依赖脆弱选择器

✍️ zhirenhun 📅 2026/8/2 👁 289 阅读 ⏱ 18 分钟

太长不看

现代 Web 应用不断变化。组件会被重新渲染，生成的属性在不同构建版本之间可能有所不同。即使界面看起来完全相同，浏览器自动化测试也可能失败，因为它仍然依赖于页面变化之前捕获的假设。

在本文中，我使用 Cursor 结合 BrowserAct CLI 来测试一个动态项目筛选器。与其依赖不可靠的选择器，Cursor 使用 BrowserAct 检查当前页面状态，并在不依赖脆弱选择器的情况下完成任务。

目标不是要消除 DOM 或取代 Playwright。目标是为 AI 代理提供一个可靠的 inspect → act → reassess 循环，使其能够在现代动态网站上正常工作。

好了，让我们开始吧！🏎️

🖥️ 问题：动态 DOM 更新会破坏旧选择器

一个浏览器测试可能连续数周运行成功，却在一次无害的前端更新之后突然失败。

按钮依然可见，功能也仍然有效。然而测试仍然失败，因为它所预期的元素已不再存在。

<!-- Initial page -->
<div class="toolbar">
  <button id="date-filter-btn">Filter by Date</button>
</div>

水合后：

<div class="toolbar toolbar--v2">
  <div class="toolbar__indent"></div>
  <button id="status-filter-btn" class="btn btn--active">
    <span>⚙️</span>
    <span>Filter by Date</span>
  </button>
</div>

await page.click("#date-filter-btn")

👀 为什么硬编码选择器会失败

当应用程序结构已知时，现代浏览器自动化效果最佳。工程师可以编写可靠的 Playwright 测试，因为他们事先了解页面结构，并在应用演进过程中维护这些测试。

对 AI 代理来说，挑战是不同的。当 Cursor 操作一个陌生的网站时，它无法假设存在哪些元素，也无法预知界面的结构。每一次有意义的交互之后，页面都可能发生变化，引入新的控件或替换已有的控件。代理不能依赖之前捕获的选择器，而需要检查当前页面的状态，根据当前实际可用的元素选择下一步操作，并在 UI 更新后重新评估。这正是 BrowserAct 旨在弥补的差距。

⚙️ BrowserAct 为 Cursor 带来的改变

BrowserAct 不再要求 Cursor 记住之前捕获的选择器，而是让代理在决定下一步操作之前，反复检查当前浏览器的状态。

它向 Cursor 提供当前页面状态的紧凑表示，让代理能够检查页面，根据当前可用的内容采取行动，并在每次有意义的 UI 变化后重新评估。Cursor 不再依赖于之前 DOM 快照中的假设，而是持续处理当前实际存在的页面，从而对动态界面具有更强的适应能力。

💻 真实动态页面测试

让我们从理论转向行动。为了展示一个可用的工作流程，我使用了一个可搜索的项目列表。

安装

我展示的是以下版本。你的版本可能更新，但核心要旨不变：

生成第一个测试

请注意，Cursor在生成时可能会请求你授权执行命令。界面显示如下：

点击运行按钮后，稍等片刻，第一个命令应会执行并打开浏览器。如果你第一次使用自动化工具，浏览器可能会要求你确认操作。只需点击“允许”，然后网站就会打开：

在运行测试时，你可能会看到自动浏览器操作。别担心，这是 BrowserAct 在工作。根据我们的指令，它可以点击按钮、滚动页面，并执行其他操作来获取当前页面状态。BrowserAct 不依赖之前捕获的选择器，而是为页面上当前可用的交互元素生成一个紧凑的表示。

我们没有指定任何选择器。Cursor 在 BrowserAct 的帮助下，自动找到了所需的输入框，搜索了页面并进行了扫描。我们只是生成了一个简单的提示，完全没有查看 DOM。

让我们扩展测试

现在让我们尝试一个更复杂的搜索选项。我将列出以下命令，并简要介绍工作流程：

browser-act --session embedcatalog click <CURRENT_INDEX>
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog state
browser-act --session embedcatalog fill <CURRENT_INDEX> "BrowserAct"
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog state
browser-act --session embedcatalog click <CURRENT_INDEX>
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog get markdown

在此工作流程中，Cursor 首先打开搜索界面并等待页面稳定。然后它刷新页面状态，在搜索字段中输入“BrowserAct”，等待结果加载，并在选择正确结果之前再次读取更新后的状态。最后，它以 Markdown 格式检索页面内容，以验证预期的项目页面是否成功打开。

通过在 Cursor 中输入相同的内容并添加我们的命令，过一段时间后我们得到以下结果：

测试成功完成。每次交互后，Cursor 都会先刷新当前页面状态再继续，从而能够适应更新后的界面。

验证确认了正确的项目已打开。项目名称、描述、最后更新日期、星标数、标签和项目 URL 都与搜索结果匹配，因此工作流程以 PASS 结果结束，且未依赖硬编码选择器。

这里有一个更简洁的版本。它保留了核心思想，但读起来明显轻松很多。

👀 BrowserAct 实际解决了什么

BrowserAct 并不会创建一个永不失效的选择器。相反，它通过反复检查当前页面状态，让 AI 代理在决定下一步操作之前更好地从界面变化中恢复。

该代理不再依赖之前捕获的 ID、CSS 选择器或 XPath，而是与当前存在的页面协作。这使工作流从：

🔎 Playwright 仍然适用的场景

这并不是要取代 Playwright。Playwright 仍然是确定性浏览器测试的绝佳选择，尤其是在工程师可以使用稳定的角色定位器、文本定位器或测试 ID 的情况下。

BrowserAct 解决的是另一个问题：它通过根据当前页面状态做出决策，而不是依赖之前捕获的选择器，来帮助 AI 代理操作陌生或不断变化的网站。这两种工具是互补的，而不是竞争关系。

✅ 我仍然明确保留的一项检查

尽管 BrowserAct 处理了动态页面更新，我仍然明确地验证了最终结果。成功的交互并不总是意味着任务正确完成——加载问题、身份验证或应用程序状态仍可能影响结果。

这就是为什么最后一步验证的是页面内容，而不是假设之前的操作已经成功。无论使用哪种浏览器自动化框架，这都能使工作流程更加可靠。

🖋️ 结论

如今，当然，你可以借助 Playwright 编写应用程序测试，但你应该明白这种做法并不理想，尤其是对于应用程序的长期测试。使用新的 id、class 等重写代码需要时间，而使用 BrowserAct 配置浏览器层并从浏览器页面读取交互性则要容易得多。

💬 反馈

你可以在评论区写下你对新功能的想法，期待阅读！如果你想了解更多关于该产品的信息，BrowserAct 有一个 YouTube 频道和一个 Discord 账号，你可以在那里讨论该工具的工作原理。