今天很多所谓的“浏览器 skill”或者“网页自动化工具”，本质上都还是在回答同一个老问题：我该如何打开页面、点击控件、抓一点内容、然后继续下一步。它们关注的是“工具箱够不够大”，而不是“在什么场景下浏览器本身才是证据来源”。

use-my-browser 的价值，恰恰在于它重新定义了这个问题。它并不把浏览器视为一个默认入口，更不把一切网页任务都往浏览器里塞。它关心的是另外一件事：当 Chrome DevTools MCP 允许智能体附着到用户当前正在使用的浏览器会话之后，智能体究竟应该如何有纪律地接管、验证、操作、恢复，并从一次运行中沉淀经验。

所以，这份 skill 真正交付的，不是“多几个浏览器命令”，而是一套浏览器会话操作协议。

一、为什么 use-my-browser 值得单独分析

1.1 浏览器从“工具”变成“证据源”

use-my-browser 的第一性原理非常明确：只有当浏览器本身就是证据来源时，才应该走浏览器路径。这里的“证据”不是抽象概念，而是非常具体的几类东西：

  • 已登录会话里的真实页面状态
  • 用户当前页面上可见的渲染结果
  • 懒加载、悬停、展开、拖拽、上传之后才会出现的 UI 变化
  • DevTools 中已经选中的元素或网络请求
  • localhost 应用在浏览器内表现出的真实交互状态

这意味着它和传统“网页抓取”类能力的重心完全不同。后者往往默认先考虑 search、fetch、curl，浏览器只是最后的补救手段；而 use-my-browser 认为，在某些任务里，浏览器不是补救方案，而是唯一可信的观察面。

1.2 Chrome DevTools MCP 改变了问题定义

这份 skill 的设计背景，直接来自 Chrome DevTools MCP 所推动的新工作流。过去，智能体要么做静态抓取，要么自己开一个新的自动化浏览器会话；两条路径彼此割裂，用户在 DevTools 里手动定位出来的线索，很难自然交给智能体继续。

而在 Chrome DevTools MCP 模型下，三个前提被改变了：

  • 智能体可以复用用户当前已经登录、已经打开、已经定位到问题现场的浏览器会话。
  • 智能体可以承接一个已经存在的调试上下文，例如 Elements 中选中的节点，或者 Network 中选中的请求。
  • 手动调试与 AI 辅助调试不再是两套平行流程，而可以在同一页面、同一上下文中衔接。

问题因此不再只是“怎么控制一个标签页”，而是“什么时候该接管当前会话、接管之后如何避免破坏现场、什么时候必须停下并报告能力缺失”。

1.3 它刻意不做“所有网页任务的默认入口”

这份 skill 最成熟的一点，恰恰是它的克制。它在入口文件里明确写了两条任务分类：

  • static-capable
  • browser-required

这两个词把边界划得很清楚。一个任务如果只需要稳定 URL、少量字段抽取、公开文本或元数据，那么它就应该留在静态路径，不需要为了“显得高级”而强行进入浏览器。

反过来，一旦一个任务被判断为 browser-required，它就不能再悄悄降级成 curl、普通页面读取或其他非浏览器路径。缺能力时应该标记为 blocked，而不是拿低保真证据去冒充完成。

这其实是一条非常重要的工程伦理：路由必须服从证据质量，而不是服从工具偏好。

二、核心方法论：先定义证据，再选择路径

2.1 目标优先，而不是工具优先

use-my-browser 在 task-routing.md 里反复强调一句话：先问“什么结果算完成”，再问“什么证据可以证明完成”，最后才是“该用哪条路径”。

这看似简单，其实把很多浏览器自动化常见的坏习惯都挡掉了。例如：

  • “帮我确认设置页保存后开关是否真的还在”是浏览器任务，因为可见状态本身就是证据。
  • “帮我提取公开页面的 canonical URL 和标题”是静态任务，因为浏览器不会提供更高质量的证据。
  • “先试静态路径，若媒体源并未直接暴露，再升级到页面内媒体检查”则是一条有条件升级的证据路径。

也就是说，它不是先选工具再找理由，而是先定义完成标准，再倒推出最便宜且足够可信的路径。

2.2 static-capable 与 browser-required 的分野

这份 skill 的任务路由可以概括成一个非常实用的判断框架：

  1. 如果稳定 URL 加直接检索已经能产出答案，就留在静态路径。
  2. 如果任务依赖登录态、可见渲染、浏览器内交互、localhost 行为、懒加载或 DevTools 上下文，就升级为 browser-required。
  3. 一旦升级为 browser-required，就不允许再用非浏览器方案偷偷“补一个差不多的答案”。

这种划分的重要性，在于它不只是减少误用浏览器，更是在保护任务语义。比如“页面上用户真正看到什么”“某个上传按钮点击后是否真的触发流程”“这个保存操作有没有真实落库”，这些问题一旦离开浏览器，就往往会被错误地简化成“抓点 HTML 看看”。

use-my-browser 对这种简化持明确反对态度。

2.3 先证明能力，再开始操作

很多自动化方案会先假设环境可用，再在失败后临时兜底。use-my-browser 则把“浏览器能力证明”做成了一个正式步骤。

在它的 browser-capability-matrix.md 中，能力不是通过猜测命令、检查进程名或者搜配置文件来证明，而是通过真实的浏览器工具调用来证明，例如：

  • 能否列出当前页面库存
  • 能否创建任务自有页面
  • 能否选中该页面
  • 能否读取快照式可见状态
  • 在需要时，能否做 DOM 级读取
  • 在需要上传时，能否调用原生上传能力

尤其是在 localhost 或 127.0.0.1 场景里，它明确反对把“能打开一个页面”误当成“拥有深度交互能力”。这说明它真正关心的不是“浏览器看起来在”，而是“本次任务所需的能力链条是否完整”。

三、实现形态：它其实是一套分层协议，而不是一堆技巧

3.1 一个入口文件加一组单用途 references

从实现形态上看，use-my-browser 并没有写一个“巨大的万能文档”，而是采用了非常清晰的分层结构：

  • SKILL.md 负责范围、分类、硬规则和 reference 加载指引
  • 每个 reference 文件只负责一个单一问题域
  • 所有 reference 都保持“一层深度”，避免互相再发散成第二层路由中心

这是一种很聪明的协议化写法。因为浏览器任务本来就容易混乱：路由、页面操作、上传、恢复、DevTools 接力、媒体检查、反自动化诊断、并行协作，这些问题如果堆在一起，智能体很快就会在过程里失去约束。

而 use-my-browser 的做法，是先由入口文件决定当前任务属于哪一类，再只加载当前问题真正需要的那一两份 reference。这样既保留了覆盖面，又避免了“每次都读完整本浏览器圣经”的低效。

3.2 默认浏览器循环：页面账本、快照、原生动作

在 browser-playbook.md 里，这份 skill 给出了一条非常值得借鉴的默认循环：

  1. list_pages，建立页面账本
  2. 必要时 new_page 创建任务自有页面
  3. select_page 明确当前操作对象
  4. take_snapshot 读取页面状态
  5. 优先使用 MCP 原生动作
  6. 每次可能改变 UI 的操作之后重新理解页面
  7. 只有在快照不够时，才升级到 evaluate_script

这里最值得注意的是两个细节。

第一，它要求维护一个轻量页面账本，至少记住 pageId、URL 或标题、页面归属、是否由自己创建、是否应在结束时关闭。也就是说，它不把“当前页面”视为理所当然的全局状态，而是把页面当作一种需要被追踪的资源。

第二，它把 take_snapshot 而不是截图，设为默认理解页面的方式。截图只有在视觉渲染本身才是证据时才优先，例如布局缺陷、视频帧、图表、canvas 或确实需要像素级证明的场景。

这种设计很务实：它优先追求结构化、可操作、低开销的理解方式，而不是动不动就上大图和大脚本。

3.3 selector bridge 如何把选择器知识接回 MCP 原生交互

这是整份 skill 里我认为最有意思的工程技巧之一。

现实里的网页经常出现这样一种尴尬局面：你已经知道某个可靠的 CSS selector，也能用 DOM 找到目标，但 MCP 的可操作对象来自 a11y tree 中的 uid，两者不是同一个寻址体系。结果就是，智能体“知道目标是谁”，却拿不到一个适合 click 或 upload_file 的原生操作句柄。

selector-bridge.md 给出的方案，是一个六步桥接流程：

  1. 用 evaluate_script 根据现有选择器知识找到目标元素
  2. 为它临时注入一个唯一、可回收的 aria-label 或其他桥接标记
  3. 重新 take_snapshot
  4. 在快照里找到对应 uid
  5. 对这个 uid 使用 MCP 原生 click 或 upload_file
  6. 操作完成后清掉临时标记

这件事看起来像小技巧，实际上很重要。因为它保住了两件事：

  • 仍然沿用 MCP 原生交互，而不是回退到粗暴的 el.click()
  • 仍然让页面理解和页面操作留在同一套快照驱动协议里

尤其是上传控件，这类场景往往最适合第一时间桥接，而不是盲点几轮再说。

四、最有价值的部分：它真正理解“接管用户当前会话”这件事

4.1 DevTools 上下文接力，而不是盲目重放

如果说大多数浏览器自动化方案最大的浪费是“重复做用户已经做过的事”，那么 debug-handoff.md 就是在正面解决这个问题。

它要求智能体在用户已经给出调试现场时，优先复用当前上下文，而不是从头复现整条路径。比如：

  • 用户已经在 Elements 里点到了出问题的元素
  • 用户已经在 Network 里选中了失败的请求
  • 用户已经把页面停在一个很难重现的现场状态上

在这种情况下，默认顺序应该是：

  1. 先复用当前浏览器会话
  2. 能复用当前调试上下文就复用
  3. 如果宿主不直接暴露选中项，就从当前页面状态最小幅度重新锚定
  4. 只有在上下文已经过期、失真或不够用时，才做最小化复现

这背后体现的不是“少做一步”这么简单，而是对调试现场价值的尊重。用户已经帮你走到关键点时，智能体继续装作一切从零开始，只会同时浪费时间和破坏证据。

4.2 控制面工作流里的“可见确认 + 结构性证据”

control-plane-workflows.md 是这份 skill 另一个非常成熟的部分。它把后台、CMS、编辑器、设置页、发布页这些高风险界面统称为“控制面”，并要求智能体把它们和普通浏览区分开来。

在这些界面里，真正危险的误判不是“按钮没点上”，而是“按钮点了，但状态到底有没有真实变化”。因此它对状态变更任务提出了一条硬规则：

  • 至少一个可见确认信号
  • 再加一个结构性证据

前者可能是 toast、banner、状态徽标、按钮文案从 Saving 变成 Saved；后者可能是：

  • URL 或路由变化
  • 新的时间戳或状态标记
  • 列表中新出现的行、卡片或资源
  • 在可见信号模糊时，一条能解释结果的网络请求

这条规则表面上只是“更谨慎”，实则是在防止智能体把“点击成功”误报成“业务成功”。对发布、删除、外显更新这类高风险动作来说，这种区分是必须的。

4.3 面对反自动化阻力时的止损模型

很多自动化系统一旦碰到异常页面，就会开始“更快地试更多次”。anti-automation-friction.md 反其道而行之：它要求智能体在页面开始表现出防御性迹象时，降速、取证、分类、只做一次有根据的替代尝试。

它把问题分成三类：

  • 路由或参数错误
  • 缺少认证或会话
  • 反自动化阻力

这三类问题的处理方式完全不同。例如：

  • 如果站点生成的 href 能工作，而手写 URL 软 404，就应信 DOM 给出的路径。
  • 如果页面明确跳去登录页或受限控件被登录墙替代，就应具体说明被阻塞的是哪项能力。
  • 如果页面开始出现 no-op 点击、速率限制、内容忽隐忽现，就不应该再增加点击频率或多开标签页。

这套止损逻辑非常重要，因为它在保护两样东西：站点压力，以及证据质量。

五、深入页面内部：从懒加载到失效 uid 的恢复纪律

5.1 iframe、Shadow DOM 与折叠内容的最小触发原则

deep-dom.md 明确规定，面对 iframe、Shadow DOM、折叠内容和懒加载区域时，不能一上来就“展开、滚到底、把 DOM 整棵树抓出来”。它要求的是最小触发原则。

这意味着：

  • 对 same-origin iframe，先看可见证据是否已经足够，不够时再读 contentDocument
  • 对 Shadow DOM，先确认宿主元素在可见层已经说明了什么，再决定是否进入 shadowRoot
  • 对折叠内容，先尝试结构读取，只有结构读取不够时才展开
  • 对懒加载内容，先记录初始状态，再只做一次有意识的触发，并记录额外重试次数

这种方法的好处，在于它把浏览器操作从“尽量多做点”变成“刚好做到能证明结论为止”。这既减少动作污染，也减少误把临时 UI 变化当成证据的风险。

5.2 媒体检查不是截图优先，而是证据梯度优先

media-inspection.md 也体现出同样的克制。它并不鼓励“遇到图片视频就截图”，而是给出了一条证据梯度：

  1. 先看页面级媒体元素和周边元数据
  2. 再看 <source>、currentSrc、播放器状态等直接资源线索
  3. 只有在底层资源本身更能回答问题时，才进入媒体资源层

对视频尤其如此。它建议先检查 <video> 元素的 DOM 状态，例如 currentSrc、duration、currentTime、paused，必要时通过受控 seek 到指定帧，再对目标区域做截图。

这是一条非常专业的判断：很多“视频页面分析”真正需要的，不是整页像素，而是播放器状态、源地址、时间点和那一帧所对应的局部画面。

5.3 恢复循环：重新选页、重取快照、只做一次有根据的升级

浏览器任务最常见的失败，并不是彻底报错，而是进入模糊地带：uid 失效了、页面悄悄跳走了、上传控件重渲染了、DOM 提取结果被样式文本或扩展噪声污染了。

browser-recovery.md 针对这些情况给出了一条明确恢复循环：

  1. 重新选中目标页面
  2. 重新获取快照
  3. 判断旧 uid、页面假设或提取结果是否已经过期
  4. 只做一次最匹配当前假设的升级
  5. 一旦下一步决策已经清楚，就停止恢复

这里最关键的是“只做一次有根据的升级”。如果问题看起来像控制台脚本错误，就先看 console；如果像提交后没发出请求，就先看 network；如果只是按钮重渲染导致旧目标无效，就先重新拿新 uid。它不允许把“重试、开新页、看 console、读 network、重写 DOM 逻辑”全部一次性堆上去。

这正是成熟协议与临场 improvisation 的区别。

六、为什么它比普通浏览器 Skill 更成熟

6.1 它把站点经验做成“可验证记忆”，而不是玄学

use-my-browser 在 references/site-patterns/ 里设计了一套站点记忆系统，但最关键的是，它对这种记忆施加了非常强的纪律。

它要求只记录经过验证、会改变未来操作方式的事实，例如：

  • 某域名在 isolatedContext 下会丢登录态
  • 某详情页必须从 DOM 里给出的 href 进入，手写 URL 会软 404
  • 某站点的上传控件需要特定桥接方式

而像“这个站看起来像 React”“感觉这里有点不稳定”这种模糊判断，则不允许进入站点记忆。

更进一步，站点 note 还要求维护 updated、confidence 和 evidence，并在每次浏览器任务结束前做一次复盘：这次运行究竟验证了新事实、推翻了旧事实，还是根本没产生可复用知识。

这使得所谓“经验”不再是智能体的直觉缓存，而是一种可维护、可降级、可删除的协议资产。

6.2 它把并行协作建立在“一页一主”的页面归属之上

parallel-browser-ownership.md 处理的是另一个常被忽略的问题：一旦有多个页面、多位 agent 或子任务并行使用浏览器，页面可见性并不等于页面所有权。

它给出的核心纪律极其简单，但非常有效：

  • 一页一主
  • 只能操作自己创建或明确拥有的页面
  • 不能因为 list_pages 看得见，就默认自己可以选中、修改或关闭它

这条规则解决的，其实是并行浏览器自动化里最难收拾的几类事故：

  • 两个 agent 在同一 SPA 标签页里互相重渲染
  • 一方拿着另一方已经失效的 uid
  • 任务结束时不知道哪些页面能安全关闭

相比“共享一个浏览器大家一起上”，这种显式归属模型显然更适合 MCP 时代的多 agent 协作。

6.3 它与 web-access 的关系，是专门化而不是替代

use-my-browser 在 README 里明确承认自己受到了 web-access 的启发，尤其是“按证据路由”“将浏览器工作视为严肃模式”“保留站点知识”这些思想。

但两者的分工并不相同。

web-access 更像广义 Web 工具箱，讨论的是如何在搜索、抓取、浏览器、站点特例之间做策略组合；use-my-browser 则明显收窄了问题域，只关心一件事：当任务真正依赖用户当前浏览器会话时，智能体应该如何安全、高保真地接管它。

也正因为这种收窄，它才有空间把如下问题讲透：

  • 什么时候浏览器是真正必需的
  • 如何证明当前会话能力真的可用
  • 如何承接 DevTools 已有上下文
  • 如何在控制面里确认变更已真实生效
  • 如何从失效目标和模糊页面状态中恢复
  • 如何把站点经验沉淀成可维护记忆

这不是“少做了点事”，而是一次很有方向感的专门化重构。

结语

use-my-browser 最值得肯定的地方，不是它把“浏览器自动化”包装得更复杂，而是它把这件事重新压回到了几个真正重要的问题上：

  • 先定义证据，再选路径
  • 先证明能力，再开始变更
  • 优先复用用户当前会话与调试上下文
  • 用 MCP 原生交互维持高保真页面操作
  • 在高风险控制面里要求更强确认
  • 用明确恢复循环处理失效目标与歧义状态
  • 用可验证的站点记忆替代模糊经验

如果说早期的浏览器 skill 更像“给智能体一把能点网页的遥控器”，那么 use-my-browser 更像是给了智能体一套浏览器现场操作守则。它不追求覆盖所有 Web 任务，而是专注于一个更难、也更现实的问题：当浏览器会话本身已经成为事实来源时，如何让智能体既高效接管，又不过度打扰，还能在任务完成后留下可复用的经验。

从这个角度看，它不是一个“多了几份文档的浏览器 skill”，而是 Chrome DevTools MCP 时代浏览器协作范式的一次非常成熟的策略层实现。