真正的难题不是自动化，是登录态
让智能体操作浏览器这件事，技术上早就不算难。难的是另一件事：让它操作你正在用、并且已经登录了一堆网站的那个浏览器，同时不把浏览器搞乱。
过去一年里多数方案的解法是绕开这个问题——给智能体开一个空白浏览器实例。隔离确实干净，代价是登录态要从零重建，于是验证码、二次验证、会话过期这些原本属于人的工作，一件不少地落回人身上。智能体跑得越远，卡在登录上的概率越高。
腾讯在 9 月开源的 BrowserSkill 选了另一条路：让智能体借用你已有的标签页，用完归还，浏览器其余部分不动。项目采用 MIT 协议，托管在 GitHub 的 Tencent 组织下，公开统计的星标数在两万一千左右。
三层进程，智能体摸不到浏览器
这套设计的结构比功能清单更值得看。
整条链路里，智能体只做一件事：通过 Shell 调用 bsk 命令。它不直接与浏览器通信，也拿不到浏览器的接口。中间隔着两层本机进程——bsk CLI 与常驻的 bsk daemon，再到浏览器扩展，三者之间靠本地 IPC 与绑定在 127.0.0.1 上的 WebSocket 连接。
这么分层换来的是权限位置的清晰。浏览器权限留在扩展那一侧，智能体那一侧只有「发出一个 Shell 命令」的能力。要判断「这个智能体能做什么」，只需要看扩展给了什么权限，而不需要推理模型会在什么情况下说服自己越界。
运行时支持 macOS（Apple Silicon 与 Intel）、Linux（x64 与 ARM64）与 Windows x64；浏览器端支持 Chrome 与 Edge，其他 Chromium 内核的浏览器在支持未打包扩展的前提下预期可用，Firefox 在计划中。
为什么是命令行工具，而不是 MCP 服务
这个选择决定了两件事。
它先决定了兼容面。任何能执行 Shell 命令的智能体都能用，不绑定特定模型、框架或 harness。已适配的清单包括 Cursor、Claude Code、Codex、OpenClaw、CodeBuddy、WorkBuddy、Pi、Hermes Agent 与 DeepSeek Harness，并且提供了一条 bsk install-skill 的安装路径，把技能说明装进对应的 harness。
它同时决定了审计面。每一次调用都是一次明确的 Shell 调用，留下可查的记录；反过来，纯 MCP 客户端接不上这套工具，因为 MCP 客户端不一定有执行 Shell 的能力。这是用兼容性换来的一处取舍。
安装机制里有个细节值得一提：技能安装带内容基线比对——当本地文件与上次安装的版本一致时，会话启动与健康检查会自动更新；一旦检测到本地改动，自动更新会暂停并给出提示。这个设计承认了一件事：用户迟早会改技能说明，而静默覆盖用户改过的文件比不更新更糟。
四个值得单独说的设计
其一是人机接管。遇到验证码、登录、确认弹窗这类必须由人处理的步骤，智能体会主动请求用户接管，完成后继续。这比「遇到就失败」和「硬闯」都更接近可用。
其二是授权开关的位置。借出标签页的权限放在浏览器设置里，而不是命令行参数里。
这个位置本身就是一层防护。命令行参数是智能体可以自己加的东西——一个被注入内容说服的模型，完全可以尝试在下次调用时带上某个开关。放在浏览器设置里，意味着这件事必须由人在浏览器界面里完成，提示词层面的说服无从下手。这条设计把「模型能说什么」与「应用允许什么」分开了。
其三是任务运行在独立的可见窗口里。Agent Window 与用户自己的窗口互不干扰，用户可以继续用浏览器，也能看到智能体在做什么。可见性是这里的关键——不要求用户盯着，但要求用户随时能看见。
其四是沙箱环境的配置。如果 agent 跑在一个每次命令后都会回收后台进程的沙箱里，常驻 daemon 会被反复杀掉，官方给出的做法是把 daemon 放在持久化的宿主环境里，通过共享 BSK_HOME 加上 BSK_AUTO_START=0 连接。这类问题在本地开发时不出现，在 CI 与云沙箱里几乎必然出现。
与另一条路线的对照
要理解这套设计的位置，需要把浏览器智能体的几条路线并排看。
内置 agent 的体验最顺——没有额外安装，打开就能用。代价是权限留在浏览器内部，而浏览器内部的边界划分由厂商决定。九月公布的一个漏洞类别正好落在这一层：研究者发现恶意扩展可以越过「不可信扩展」与「高权限智能体」之间的边界，在特权上下文里执行代码，五款主流浏览器受影响，两家厂商为此发布了 CVE。
空白沙箱实例把隔离做到位，代价是丢失真实登录态，进而丢失真实上下文——智能体看不到你正在处理的工单、正在填的表单、正在比价的页面。
外部桥接保留了登录态，也把权限位置外移到了可枚举的一侧。它的代价同样明确：多了一个本机常驻进程要维护，多了一个安装步骤，而且扩展本身的来源与权限仍然需要用户自己确认。
三条路线没有一条是全面占优的。它们的差别不在能力上限，而在把「谁决定智能体能做什么」这件事放在哪一层，以及这个决定能不能被用户看见和修改。
实际使用时要留意什么
借标签页这个动作本身意味着：智能体看见的内容与你看得见的内容是一样的，包括那个标签页里已经存在的会话信息、表单内容与页面状态。如果被借的标签页恰好停在邮箱或后台系统上，那么智能体在工作过程中接触到的信息范围就比预期更大。这不是设计缺陷，而是「复用真实登录态」这件事的必然结果。
本地运行也不等于零风险。整条链路都在本机，没有数据出网的中转，这是隐私上的优势；但本机运行的扩展与守护进程，一旦自身被替换或被其他本地程序影响，影响范围是整台机器。来源可信、版本可查、权限清单清楚，这三条仍然要自己核。
在 CI 与自动化环境里使用时要额外注意两点：常驻进程的存活问题，以及登录态从哪来。如果 CI 环境里的浏览器是全新的，那这条路线的价值就回到与空白沙箱接近的水平。
需要标注的边界
本文的项目参数、支持平台与适配清单来自仓库说明与安装文档，星标数来自第三方统计，会随时间变化。文中提到的「权限放在浏览器设置」是当前文档描述的行为，具体到每个浏览器版本的实现可能有差异，建议在自己环境里实测一次再下结论。
另外，开源工具的安全边界会随版本演进。项目当前对 Firefox 的支持仍在计划中，跨浏览器的行为一致性在短期内不必指望。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。