BrowserSkill
青年最主要的任务是学习。——朱德
BrowserSkill：让 AI 走进真实浏览器，却不打断你的工作
项目地址：https://github.com/Tencent/BrowserSkill
浏览器早已不只是打开网页的工具。
它保存着登录状态，承载着正在进行的工作，留着尚未处理完的页面、表单、消息和资料。对于许多人而言，浏览器几乎就是日常数字工作的桌面。而当 AI 智能体开始尝试参与浏览器自动化时，真正困难的并不只是点击、输入和跳转，更在于如何让它进入真实工作环境，同时不侵占、不扰乱用户正在使用的浏览器。
BrowserSkill 正是在这样的场景中出现。
它是一套连接 AI 智能体与已登录浏览器的本地工具，由 bsk 命令行工具、后台守护进程和浏览器扩展共同组成。Cursor、Claude Code、Codex、OpenClaw、CodeBuddy、WorkBuddy、Pi、Hermes Agent、DeepSeek Harness 等能够调用 Shell 的智能体，都可以通过 BrowserSkill 使用浏览器能力。
它不要求智能体绑定某个模型、某个框架或某一种 Agent Harness。只要智能体能够执行命令，就可以通过 bsk 进入 BrowserSkill 的工作流。
更重要的是，BrowserSkill 并不试图让智能体接管整个浏览器。
它让智能体在独立可见的 Agent Window 中完成浏览器任务；如果智能体确实需要操作用户已经打开的标签页，则必须明确借用该标签页，并在任务结束后归还。用户自己的正常浏览窗口依旧属于用户自己。
这是一种很克制的设计。
AI 可以进入浏览器，但它不会理所当然地占据浏览器。
真实登录状态，让自动化不必从空白开始
许多浏览器自动化场景都会遇到同一个问题：自动化环境没有真实身份。
为了让程序访问目标网站，人们常常需要额外准备测试账号、重新登录、复制 Cookie，或者在新的隔离环境里重复一遍原本已经完成的验证流程。BrowserSkill 的思路则更贴近真实工作环境：智能体可以复用用户已经登录的网站状态。
这意味着，浏览器中原本存在的登录状态可以成为智能体完成任务的一部分。
它不需要为了访问一个已经登录的平台，再额外创建测试账号；也不必把日常使用的浏览器环境完全复制到另一个自动化容器中。用户的浏览器依旧是熟悉的浏览器，智能体则通过 BrowserSkill 获得受控的操作入口。
这种能力尤其适合那些必须建立在真实登录状态之上的浏览器任务。身份验证不再是自动化流程外的一道墙，而成为浏览器环境本身已经拥有的条件。
AI 在独立窗口里工作，用户继续使用自己的浏览器
BrowserSkill 选择把浏览器任务运行在独立、可见的 Agent Window 中。
这意味着，当智能体浏览页面、执行网页操作或处理浏览器任务时，用户依旧可以继续使用自己的浏览器窗口。原本正在阅读的文档、正在填写的表单、尚未关闭的标签页，不需要因为智能体的任务而停摆。
Agent Window 像是浏览器里专门划出的一块工作区。
它承担智能体的自动化过程，保持任务可见，同时将用户日常浏览的空间保留下来。智能体有自己的行动区域，用户也保有自己的工作节奏。
只有在智能体需要处理用户已经打开的标签页时，借用机制才会出现。
借用不是默认行为，而是一个需要明确发起的动作。任务完成后，标签页会被归还，其他浏览器窗口则保持不受影响。
这种分离让浏览器自动化不再像一场突如其来的接管，而更像是一次被安排在旁边工位上的协作。
浏览器自动化也需要人在回路中
网页世界并不总是可以被完全自动化。
验证码、登录确认、确认对话框，以及其他只能由人完成的步骤，都是智能体可能遇到的边界。BrowserSkill 为此提供了人机协作机制：当任务走到必须由用户介入的位置时，智能体可以请求用户接手，等待必要操作完成后继续执行。
这让自动化不会在遇到边界时直接失去方向。
智能体可以完成它能够完成的部分；当网页要求人类确认、身份验证或其他人工操作时，用户可以进入流程；完成后，智能体继续接力。
BrowserSkill 的重点不在于假装所有事情都能无声无息地自动完成，而在于让自动化与人工接管自然衔接。
人不必从头完成整个任务，智能体也不必在无法跨越的步骤前停滞不前。双方各自处理最适合自己的部分。
两个本地运行组件，搭起智能体与浏览器之间的桥
BrowserSkill 的本地运行环境由两部分组成：
bskCLI 与后台守护进程- 浏览器扩展
智能体并不会直接对浏览器发起操作。
它先通过 Shell 调用 bsk 命令行工具；CLI 将请求发送给本地守护进程；守护进程再通过本地 WebSocket 与浏览器扩展通信；最终由扩展在 Agent Window 中执行浏览器自动化。
整个路径可以概括为：
1 | AI Agent |
用户的普通浏览器窗口并不位于智能体默认操作路径上。只有在智能体明确请求借用标签页时，扩展才会触及用户已打开的页面。
这套结构将不同职责清晰拆开：
- AI Agent 负责理解任务与发起命令
bskCLI 负责承接命令行调用- 后台守护进程负责本地通信与请求转发
- 浏览器扩展负责浏览器侧自动化
- Agent Window 负责承载智能体的浏览器操作
- 用户窗口继续服务于用户自己的日常工作
BrowserSkill 的桥梁不是把浏览器交给 AI，而是为 AI 修建一条带有边界的通道。
支持多种操作系统与 Chromium 浏览器
BrowserSkill 支持 macOS、Linux 和 Windows。
在操作系统层面，它覆盖：
- macOS 的 Apple Silicon 与 Intel 设备
- Linux 的 x64 与 ARM64 环境
- Windows x64 环境
在浏览器层面，BrowserSkill 支持 Chrome 与 Microsoft Edge。
其他支持加载未打包 Chromium 扩展的 Chromium 浏览器，也被预期可以运行 BrowserSkill。Firefox 则处于计划支持范围内。
对于多平台、多设备或不同浏览器习惯的开发与自动化环境而言，这样的支持范围让 BrowserSkill 能够进入更广泛的本地工作场景。
从安装 Skill 开始，让智能体学会使用浏览器能力
BrowserSkill 不仅提供浏览器桥接能力，也提供了用于指导智能体使用 bsk 的 Skill。
在完成 CLI 与浏览器扩展安装后，可以通过以下命令安装 Skill：
1 | bsk install-skill |
命令会让用户选择需要安装到的 Agent Harness，再将对应 Skill 放入适合的位置。
如果需要查看可用的内部变体与安装路径，可以使用：
1 | bsk install-skill --list |
对于非交互式安装，可以明确指定目标 Harness：
1 | bsk install-skill --harness cursor --json |
当 Harness 未被自动识别时，也可以通过显式指定的方式完成安装。已有安装默认会被跳过，除非使用 --force。
BrowserSkill 对本地修改也采取了谨慎态度。
如果安装后的 Skill 文件被本地编辑，自动更新会暂停，以避免直接覆盖用户自己的说明。对于内容不同的历史文件、本地改动或未识别来源标记，doctor 会给出警告与恢复选项。警告不会让健康检查失败，但会明确告诉用户当前安装状态需要注意什么。
如果希望将现有指令保留为显式自定义内容，可以使用自定义源文件重新安装：
1 | bsk install-skill --harness cursor --source <existing-SKILL.md> --force |
如果希望恢复内置 Skill 并重新启用自动更新，则可以不带 --source 重新安装：
1 | bsk install-skill --harness cursor --force |
对于一个面向智能体的浏览器工具而言，Skill 并不只是辅助文档。它承担着把浏览器操作习惯、命令调用方式与安全边界传递给 Agent Harness 的职责。
用 doctor 检查连接状态
安装完成后，可以通过以下命令检查 BrowserSkill 的运行状态：
1 | bsk doctor |
doctor 会给出提示，帮助确认 CLI、扩展和连接状态是否正常。
BrowserSkill 期望用户在真正开始浏览器任务前，先确认扩展处于已连接状态，并处理可能出现的警告与失败。即使没有安装 Skill，健康检查也可能通过并显示 Skill 状态为 N/A，因此 Skill 的发现状态仍需要单独确认。
一次简单的首次使用检查，可以让智能体打开页面并总结内容。例如，在支持斜杠命令调用 Skill 的 Harness 中，可以使用：
1 | /browser-skill open example.com and summarize what is on the page. |
成功的首次检查会读取页面内容，并在完成后停止对应的 BrowserSkill 会话。
这种从连接检查到首次任务的路径，让浏览器自动化不必从复杂流程开始。先确认桥已搭好，再让智能体走上去。
自动化设置，决定确认与人工协助如何发生
BrowserSkill 的扩展弹窗中提供两项彼此独立的自动化设置：
- 借用标签页前是否确认
- 是否允许请求人工协助
这两项设置默认开启，并且用户在浏览器配置文件中保存的设置，对每一个会话都具有决定作用。
| 借用标签页前确认 | 允许请求人工协助 | 行为 |
|---|---|---|
| 开启 | 开启 | 借用标签页需要批准，人工协助请求会显示已有界面 |
| 开启 | 关闭 | 借用标签页需要批准，人工协助请求会返回 disabled |
| 关闭 | 开启 | 借用标签页不再等待确认，人工协助请求会显示已有界面 |
| 关闭 | 关闭 | 借用标签页不再等待确认，人工协助请求会返回 disabled |
设置会自动保存到浏览器配置文件，并同时作用于已有会话和新建会话。
当关闭借用确认时，正在等待的借用确认会被释放。当关闭人工协助时，正在等待的协助请求会以 disabled 结束。重新开启设置后，后续操作会恢复相应行为。
已经完成的借用不会被撤销，已经结束的人工协助请求也不会被重新打开。
这种设置方式将两个问题拆开：
一个问题是，智能体是否可以直接借用用户已经打开的标签页。
另一个问题是，当它遇到必须由人完成的步骤时，是否可以向用户发起协助请求。
BrowserSkill 没有把这两件事混成一个粗糙的开关，而是让用户分别决定浏览器控制与人工介入的边界。
--no-focus：让任务在不抢占注意力的情况下启动
BrowserSkill 的任务通过 bsk session start 启动。
如果希望避免启动任务时自动聚焦 Agent Window，可以加入 --no-focus：
1 | bsk session start --no-focus |
这个参数体现了一种很细微却很重要的体验考虑。
自动化任务不一定应该打断当前正在进行的工作。用户可能正处于写作、会议、阅读或处理其他页面的过程中，而智能体可以在另一处窗口里开始自己的浏览器任务。
Agent Window 是可见的，但不必总是强行抢占用户的视线。
当人工协助被关闭，智能体仍会继续尝试
如果人工协助被关闭，request-help 会返回 disabled，不会再要求用户确认任何人工动作。
此时，Skill 会引导智能体重新观察页面，并在已有登录状态、已授权输入与现有工具的范围内，继续合理尝试完成任务。
在任务授权与宿主规则允许的情况下，具备图像理解能力的模型也可以尝试进行图形验证。
但 BrowserSkill 同样明确承认，有些边界不会因此消失。
仅能通过手机完成的二维码扫描、人脸验证、不可用的短信验证码，以及面向纯文本模型的图像验证码，仍然可能阻塞任务。disabled 并不意味着任务已经完成，也不意味着智能体获得了新的权限。
这份边界感很清楚。
关闭人工协助，只是改变了协助请求的处理方式；它不会把本来属于人类的验证动作自动变成智能体可以越过的权限。
全页截图，让长页面能够被完整捕捉
除了网页操作本身，BrowserSkill 还提供截图能力。
可以截取当前视口：
1 | bsk screenshot --session <id> --out viewport.png |
可以截取指定元素：
1 | bsk screenshot --session <id> --ref @e3 --out element.png |
也可以截取完整页面：
1 | bsk screenshot --session <id> --full-page --out page.png |
对于可能需要更长等待时间的页面，可以指定超时：
1 | bsk screenshot --session <id> --full-page --timeout 5m --out page.png |
全页截图会从上到下滚动普通 HTTP 或 HTTPS 页面，包含滚动过程中加载的内容，并在完成后恢复原始滚动位置和临时样式。
在截图过程中，目标标签页需要属于当前会话，也就是已经被创建或借用。--tab-id 可以选择特定目标标签页，但不会自动激活它。
全页截图与元素引用截图不能同时使用。全页捕捉与 PNG 编码默认有两分钟超时，--timeout 可以调整这个时限，并且只能和 --full-page 一起使用。
如果通过 Ctrl-C 取消截图或传输，BrowserSkill 会停止当前操作。失败的截图不会保存为不完整图像。
在输出处理上，PNG 数据会写入磁盘并以分块形式传输。CLI 会先在输出位置旁创建临时文件，只有在接收完全部数据后，才以原子方式替换目标文件。已有输出文件会在成功时被替换。
这使得全页截图不仅是一个简单的截屏动作，也是一套考虑了长页面、内容加载、超时控制、取消操作与文件完整性的浏览器能力。
不过，全页截图也有明确的适用范围。它不会自动化 Chrome 内部页面、浏览器商店、嵌套滚动面板或虚拟列表。它沿着页面文档本身的滚动轨迹工作，而持续无限增长的页面可能会触及设定的超时时间。
支持 DeepSeek Harness 的原生浏览器工具体验
对于使用 DeepSeek Harness 的场景，BrowserSkill 提供了专门的 dsh 插件。
该插件会向智能体提供原生的 browser_* 工具，并在 Web UI 中展示浏览器会话的实时视图。插件会代表智能体调用 bsk，因此整体路径依旧遵循 BrowserSkill 的本地桥接架构。
在已安装 bsk CLI 并连接浏览器扩展后，可以将插件加入某个 dsh 配置文件：
1 | dsh plugin --profile web add @wxg-prc-cpg/browser-skill-dsh-plugin |
这个插件已经包含 browser-skill Skill，因此在 dsh 场景中不需要再执行 bsk install-skill。
插件不会自动更新。需要升级时，可以执行：
1 | dsh plugin --profile web update @wxg-prc-cpg/browser-skill-dsh-plugin --latest |
升级后需要重启对应配置文件。
这种专门集成让 DeepSeek Harness 不只是通过通用 Shell 命令间接使用 BrowserSkill，而是能够以原生浏览器工具的形式接入同一套能力。
更新时，先让正在进行的浏览器任务完成
对于默认的本地安装方式，BrowserSkill 建议在更新前先完成正在进行的浏览器任务。
更新命令如下：
1 | bsk update --yes |
当命令安装更新后，会使用默认启动设置重启正在运行的后台守护进程。
如果是通过安装器替换二进制文件，则可以在任务结束后重启已有守护进程：
1 | bsk daemon restart |
对于使用自定义端口、宿主机管理的沙箱守护进程或远程服务器的场景，更新过程则需要由对应宿主或监督系统负责停止与重新启动。此时可以使用不重启守护进程的更新方式：
1 | bsk update --yes --no-restart-daemon |
浏览器扩展则通过浏览器商店更新。对于未打包的开发构建，需要重新构建并重新加载扩展。
更新后，可以查看 CLI、守护进程与扩展版本，并再次执行健康检查：
1 | bsk --version |
BrowserSkill 也提醒，某些新能力，例如全页截图，需要 CLI 与扩展版本彼此匹配。
这说明浏览器自动化并不是单一二进制文件的工作，而是 CLI、后台守护进程与扩展协同运行的系统。保持这些组件的版本协调，是完整能力能够正常工作的前提。
面向开发者的工作区结构
BrowserSkill 的仓库采用 Cargo 与 pnpm 工作区组织。
其中包括：
crates/bsk-cli，负责bskCLI 与本地守护进程crates/bsk-protocol，提供共享通信类型与 JSON Schemaapps/extension，承载浏览器扩展packages/ui，提供扩展共用 UI 支持packages/i18n，提供英文、简体中文与韩文的本地化支持packages/dsh-plugin-browserskill，提供 DeepSeek Harness 插件evals/browser，提供确定性的本地页面与中立的浏览器能力评估
其中，bsk-protocol 负责 CLI、守护进程与扩展之间的通信协议。其 JSON Schema 可以通过以下命令生成：
1 | cargo run -p bsk-protocol --bin dump-schema --locked |
这种结构将命令行、通信协议、浏览器扩展、共享界面、国际化、插件与评估拆分为明确的组成部分。
BrowserSkill 并不是把浏览器自动化压缩为一段简单脚本，而是围绕本地通信、浏览器扩展、Agent Harness、用户确认、会话管理与协议协作搭建出完整链路。
不是替用户接管浏览器，而是让智能体学会礼貌地借用
BrowserSkill 最鲜明的特点，不只是让 AI Agent 能够使用浏览器。
更重要的是，它让智能体在使用浏览器时保留了边界。
它复用真实登录状态，却不要求把用户工作迁移到新的测试环境。
它在独立 Agent Window 中执行任务，却不阻止用户继续使用自己的浏览器。
它能够借用已有标签页，却把借用设计成明确、可确认、可归还的行为。
它支持人工接管，却不把人工协助当成无条件绕过网页限制的方式。
它能够让不同 Agent Harness 通过 Shell 接入，却不将能力锁定在特定模型、框架或宿主中。
从 CLI、守护进程与浏览器扩展组成的本地桥，到借用标签页、全页截图、人工协助、自动化设置与 DeepSeek Harness 插件，BrowserSkill 试图回答的是一个越来越现实的问题：
当 AI 开始进入人们真实使用的浏览器，它应该如何行动。
BrowserSkill 给出的答案，不是让智能体无边界地控制一切，而是让它在清晰的通道、可见的窗口、明确的确认与可控的权限中完成工作。