AI工具

browser-harness 的 domain skills 机制：让 AI Agent 不再重复踩网页自动化的坑

解析 browser-harness 的 domain skills 机制，说明它如何把 Amazon、GitHub、ArXiv、LinkedIn、Shopify 等站点的操作经验沉淀成可复用技能，以及对 AI Agent 浏览器自动化的启发。

browser-use/browser-harness 最有意思的地方，不只是让 AI Agent 能控制真实 Chrome，而是它把网页操作中的经验变成了可以复用的 domain skills。

这件事很关键。浏览器自动化真正困难的地方，往往不是“能不能点击按钮”，而是每个网站都有自己的细节：

  • 哪些页面必须登录。
  • 哪些数据可以直接走 API。
  • 哪些按钮用普通 DOM 点击无效。
  • 哪些 iframe、shadow DOM、弹窗会挡住流程。
  • 哪些选择器稳定，哪些只是临时 class。
  • 哪些操作涉及账号、支付或不可逆变更，必须让人确认。

如果这些经验只留在一次任务日志里，Agent 下次还会重新踩坑。domain skills 的作用，就是把这些经验沉淀下来，让 Agent 不必每次都像第一次打开网站。

domain skills 是什么

可以把 domain skills 理解成“给 Agent 看的站点操作手册”。

它不是普通的用户文档，也不是一次性脚本。它更像一组经过实测的站点级知识：

  • 这个站点适不适合用浏览器。
  • 如果有 API，应该优先用哪个 API。
  • 如果必须操作网页，应该从哪个 URL 进入。
  • 哪些 DOM 结构、aria-label、按钮行为经过验证。
  • 哪些常见写法会失败。
  • 哪些场景要停止并请求人类介入。

这类内容既能被人类审查，也能被 Agent 在任务中读取。它把“临场摸索”变成“可维护经验”。

它不是让 Agent 盲目点击

一个好的浏览器 Agent，不应该把所有问题都变成打开网页、看截图、点按钮。

domain skills 里很重要的一类经验，恰恰是在告诉 Agent：什么时候不要用浏览器。

比如 ArXiv 这类站点，论文搜索、元数据和摘要可以通过 Atom API 或 HTML meta 标签直接拿到。用 HTTP 请求通常比打开浏览器更快、更稳，也更容易解析。

GitHub 也是类似思路。仓库、用户、release 数据优先用 REST API；文件内容优先读 raw.githubusercontent.com；只有 GitHub Trending 这类没有等价 API 的页面，才需要进入浏览器。

这说明 browser-harness 的思路不是“浏览器万能”，而是把浏览器放在正确位置：当 API、HTTP、静态页面无法解决问题时，再让 Agent 操作真实页面。

它记录的是站点级知识

传统自动化脚本通常围绕一次任务写，比如：

1

打开页面 -> 输入关键词 -> 点击按钮 -> 下载文件

这种脚本可以完成任务，但经验很容易散落在代码里。站点一改版，脚本失效；换一个任务，很多经验也没法复用。

domain skills 的粒度更接近站点级知识库。它关心的是：

  • Amazon 搜索结果里哪个容器选择器稳定。
  • GitHub 哪些数据应该走 REST API。
  • LinkedIn 邀请管理页的按钮 aria-label 有什么差异。
  • Shopify Admin 里哪些页面是嵌入式 app。
  • Shopify Polaris 输入框为什么不能只用普通 JS 设置 value。
  • Browser Use Cloud 的浏览器实例如何创建、列出和清理。

这些经验不是一次任务的步骤，而是以后很多任务都会用到的判断依据。

例子：Amazon 商品搜索

Amazon 商品搜索的经验，重点不只是“怎么搜索商品”，而是哪些路径更稳定。

比较可靠的做法是直接使用搜索 URL，而不是每次都打开首页再模拟输入。搜索结果可以从 [data-component-type="s-search-result"] 这样的容器中提取。字段提取也有细节：标题、价格、评分、评论数、是否赞助，都有各自更稳的 DOM 来源。

这种经验对 Agent 很有价值。没有它时，Agent 可能会从截图里猜按钮、反复尝试选择器；有了它之后，Agent 可以直接进入更稳定的数据提取路径。

更重要的是，这类 skill 还会记录陷阱。例如某些看似可用的选择器，在赞助结果或交叉推荐区域里会误读。这种坑只有实测过才知道。

例子：LinkedIn 邀请管理

LinkedIn 这类站点更接近真实账号工作流，风险也更高。

在邀请管理页里，Accept 和 Ignore 按钮的 aria-label 格式不同，不能简单地从一个推导另一个。有些邀请卡片里的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 点击不一定能触发接受动作。

这种细节说明，真实网页自动化不是“定位到元素就结束”。按钮标签、事件绑定、软导航、组件实现方式，都会影响操作是否真的生效。

对 Agent 来说，这类经验还有一个安全含义：涉及社交账号、邀请、消息、发帖的操作，不应该完全托管。skill 可以记录路径和陷阱，但批量接受邀请、对外发送内容、修改账号资料这类动作，最好保留人工确认。

例子：Shopify Admin

Shopify Admin 的经验说明了另一个问题：后台系统往往不是一个页面，而是一堆嵌入式应用和复杂组件的组合。

很多 Shopify app 会运行在 iframe 里。Polaris React 输入框、Web Components、嵌入式 app 的交互方式也不同。某些输入框不能只用 element.value = ...，需要使用更接近真实键盘输入的 CDP keystrokes。

这类 skill 的价值在于，它让 Agent 先判断当前页面属于哪类 UI，再选择合适的操作方式。

同时，Shopify 的经验也强调“能不用浏览器就不用浏览器”：

  • 只读商品和库存数据，优先用 Storefront API。
  • 有 Admin API token 时，优先用 Admin API。
  • 编辑主题代码时，优先用 Shopify CLI。
  • 只有没有 API、一次性设置、探索后台时，才适合让浏览器介入。

这才是成熟的 Agent 工具选择逻辑。

例子：Browser Use Cloud

domain skills 不只服务网页点击，也可以记录围绕浏览器运行时的 API 经验。

Browser Use Cloud 的经验里，会记录如何通过 REST API 创建 cloud browser、列出正在运行的浏览器、清理 zombie browser、获取 liveUrl 和 cdpUrl 等信息。

这说明 skill 的边界并不局限于“某个网页按钮怎么点”。只要某类任务会反复出现，而且有稳定做法，就可以沉淀成 skill：

  • API 调用方式。
  • 鉴权头格式。
  • 请求和响应结构。
  • 已验证状态码。
  • 常见失败模式。
  • 清理和回收资源的方法。

对 Agent 来说，这些都是可复用能力。

为什么这比临场推理更可靠

很多人期待大模型每次都能“自己看懂网页”。但真实任务里，只靠临场推理并不稳定。

原因很简单：

  • 网页 UI 经常变化。
  • 同一按钮可能有多种实现。
  • 看得见不代表点得动。
  • 能点击不代表操作真的生效。
  • 有些任务本来就应该用 API，而不是浏览器。
  • 有些操作需要人类确认，不能让模型自己决定。

domain skills 把这些经验写成文件后，有几个好处：

  • 人类可以 review。
  • 错误经验可以修正。
  • 同一站点的经验可以持续积累。
  • 新 Agent 可以直接继承旧经验。
  • 临时任务发现可以变成长期知识。

这比把一切都塞进 prompt 或聊天上下文更稳。

团队可以怎么用

如果把 browser-harness 用在团队里，domain skills 可以变成一种轻量自动化知识库。

比较适合沉淀的内容包括：

  • 内部后台的登录后路径。
  • 报表导出流程。
  • 常见弹窗处理方式。
  • 哪些按钮需要人工确认。
  • 哪些页面有 API 替代方案。
  • 哪些选择器经过实测可靠。
  • 哪些任务不允许 Agent 自动执行。

这类知识不必一开始就很完整。更实际的做法是从低风险、高频、可回滚的流程开始：先让 Agent 做只读、下载、整理、检查类任务。等流程稳定后，再把经验整理成 skill。

对团队管理者来说，skill 文件还有一个好处：它让自动化边界变得可见。你可以审查 Agent 知道什么、能做什么、应该停在哪里。

需要注意的边界

domain skills 能提高 Agent 成功率，但它不应该让高风险操作完全自动化。

几个边界要守住：

  • 不记录密码、Cookie、token、客户数据和内部敏感 URL。
  • 支付、删除、批量提交、账号变更、对外发布内容，要保留人工确认。
  • skill 要写明验证日期和适用范围。
  • 站点改版后，要允许 skill 失效并重新验证。
  • 不要把绕过风控、规避平台限制当成目标。

换句话说，domain skill 是让 Agent 更稳，不是让 Agent 无限制地做事。

简单结论

browser-harness 的 domain skills 机制说明了一件事：AI Agent 的浏览器自动化，不能只靠模型临场发挥。

一个可用的浏览器 Agent，至少需要三层能力：

  • 底层控制能力：截图、点击、输入、下载、CDP、HTTP。
  • 站点级知识：API 优先级、稳定选择器、组件陷阱、登录边界。
  • 人类安全规则：凭据不交给模型，高风险操作要确认，敏感信息不写进 skill。

domain skills 补的是第二层。它让 Agent 带着验证过的经验进入网页任务，而不是每次都重新摸索。

参考资料：

© 2022 - 2026 KnightLi的博客
记录并分享
使用 Hugo 构建
主题 Stack 由 Jimmy 设计