浏览器自动化这个方向过去两年我陆陆续续试过不少方案从最早的 Selenium 到后来的 Playwright、Puppeteer再到各种基于 CDP 的封装库绕来绕去始终卡在同一个坎上登录态。你要么让脚本自己走一遍登录流程把账号密码写在配置里或者环境变量里要么手动导出 Cookie 再喂给脚本要么干脆用扫码登录配合人工介入。每一种都别扭尤其是当目标站点有风控、有二次验证、有设备指纹的时候脚本登录的成功率低得让人想砸键盘。腾讯这次开源的 BrowserSkill 走了一条完全不同的路——它不去模拟登录而是直接接管你本机已经登录好的浏览器。密码不用给Cookie 不用导验证码不用过因为那个浏览器本来就是你日常在用的那个。这个思路听起来简单但背后涉及的技术选型和工程取舍相当有意思我花了两天时间把它的源码和文档翻了一遍又实际跑了几轮测试下面把这些东西整理出来。1. BrowserSkill 到底解决了浏览器自动化里的哪个死结1.1 传统方案为什么总在登录这一步翻车先说清楚问题本身。浏览器自动化的核心诉求是让程序代替人去操作网页但绝大多数有价值的网页操作都发生在登录之后。你打开一个后台管理系统、一个数据分析平台、一个内容发布工具第一件事就是登录。传统自动化框架处理登录的方式无非三种第一种是脚本模拟输入账号密码然后点击登录按钮第二种是预先保存 Cookie 或 localStorage 再注入到新开的浏览器上下文里第三种是调用站点提供的 API Token 绕过登录界面。这三种方式各有各的坑。第一种最直接但现在的登录页面普遍有滑块验证、行为验证、设备指纹检测脚本的鼠标轨迹和键盘事件跟真人差异太大很容易被识别出来。第二种看起来聪明但 Cookie 有有效期过期了就得重新导出而且很多站点的 Cookie 跟设备指纹绑定换一个浏览器实例就失效。第三种最稳定但前提是站点得提供 API而且 Token 的获取和刷新又是一套额外的维护成本。更关键的是这三种方式都要求你把某种形式的凭证交给自动化脚本。账号密码也好Cookie 也好Token 也好本质上都是在扩大凭证的暴露面。对于一个内部工具或者个人项目来说可能无所谓但如果是团队协作场景凭证管理就成了一个绕不开的合规问题。1.2 BrowserSkill 的切入角度不模拟登录直接借用已有会话BrowserSkill 的思路是既然你本机的 Chrome 浏览器里已经登录好了那我为什么不直接连上去用它通过 Chrome DevTools Protocol 连接到你已经打开的浏览器实例复用你当前的用户配置目录User Data Directory包括所有的 Cookie、localStorage、Session Storage、已安装的扩展、甚至你当前打开的标签页。对于目标网站来说这些操作跟你自己手动点击没有任何区别因为从浏览器的视角来看就是同一个用户在同一个会话里操作。这个思路的关键在于 Chrome 本身提供的远程调试能力。Chrome 在启动时可以通过--remote-debugging-port参数开放一个调试端口任何实现了 CDP 协议的程序都可以通过这个端口连接到浏览器获取页面列表、执行 JavaScript、模拟输入、截取网络请求等等。BrowserSkill 做的就是把这套能力封装成对 AI 友好的接口让 AI Agent 能够以自然语言指令的方式驱动浏览器完成操作。注意远程调试端口默认只监听本机回环地址不要把它暴露到公网否则任何能访问到该端口的人都可以完全控制你的浏览器。1.3 和 Playwright、Puppeteer 的本质区别在哪很多人第一反应是这不就是 Playwright 的connectOverCDP吗确实Playwright 和 Puppeteer 都支持通过 CDP 连接到已有的浏览器实例。但 BrowserSkill 跟它们的定位不一样。Playwright 和 Puppeteer 是给开发者用的编程库你需要写代码来定义每一步操作。BrowserSkill 是给 AI Agent 用的技能层它把浏览器操作抽象成了一套语义化的动作集合AI 只需要理解打开某个页面点击某个按钮提取某段文字这样的意图具体的 CDP 调用由 BrowserSkill 内部处理。另一个区别是用户配置目录的处理。Playwright 默认会创建一个全新的浏览器上下文即使你连接到已有浏览器它也可能在新的标签页里操作跟你当前的登录态是隔离的。BrowserSkill 则明确要求复用你当前的用户配置目录这意味着你所有的登录态、扩展、书签、历史记录都是可用的。这个设计选择直接决定了它的适用场景——它不是用来做大规模并发爬取的而是用来做个人助理式的浏览器操作的。2. 把 BrowserSkill 跑起来需要跨过的几道坎2.1 环境准备Chrome 版本和调试端口的那些事BrowserSkill 对 Chrome 版本有要求建议使用 120 以上的稳定版。我实测下来Chrome 109 虽然也能连上但部分 CDP 命令的返回格式有差异会导致一些高级功能异常。如果你用的是 Chromium 内核的其他浏览器比如 Edge 或者 Brave理论上也支持但 BrowserSkill 的默认配置里写死了 Chrome 的路径需要手动改一下。启动带调试端口的 Chrome 有两种方式。第一种是关闭所有 Chrome 窗口然后用命令行启动# macOS 下的启动命令 /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --remote-debugging-port9222 \ --user-data-dir/Users/你的用户名/chrome-debug-profile# Windows 下的启动命令 C:\Program Files\Google\Chrome\Application\chrome.exe ^ --remote-debugging-port9222 ^ --user-data-dirC:\chrome-debug-profile这里有个关键点--user-data-dir指定的目录不能是你日常使用的默认配置目录。Chrome 不允许两个实例同时使用同一个用户配置目录如果你强行指定默认目录Chrome 会直接忽略调试端口参数启动一个普通窗口。所以你需要创建一个独立的配置目录第一次启动后在这个新窗口里重新登录你需要的网站。虽然多了一步登录操作但只需要做一次之后这个配置目录里就保存了所有登录态。第二种方式是用 Chrome 的快捷方式在目标路径后面追加参数。Windows 下右键 Chrome 快捷方式在目标字段末尾加上--remote-debugging-port9222 --user-data-dirC:\chrome-debug-profile之后双击这个快捷方式启动的就是带调试端口的实例。提示如果你日常用的 Chrome 已经开着需要先完全退出包括后台进程再用调试参数启动。macOS 下可以用CmdQ彻底退出Windows 下检查任务管理器里有没有残留的 chrome.exe 进程。2.2 安装 BrowserSkill 并验证连接BrowserSkill 的安装方式取决于你使用的 AI Agent 平台。如果是配合 Claude Desktop 或者类似的 MCP 客户端使用通常是通过 npm 或者 pip 安装对应的包然后在配置文件里注册这个 Skill。以 npm 为例npm install -g tencent/browserskill安装完成后需要配置 MCP 服务器的连接信息。在 Claude Desktop 的配置文件claude_desktop_config.json里添加{ mcpServers: { browserskill: { command: npx, args: [-y, tencent/browserskill], env: { CDP_PORT: 9222 } } } }配置好之后重启 AI 客户端如果一切正常你应该能在工具列表里看到 BrowserSkill 提供的各种浏览器操作能力。验证连接是否成功的最简单方法是让 AI 执行一个列出当前打开的标签页的操作如果它能正确返回你 Chrome 里正在浏览的页面标题和 URL说明连接已经通了。我踩过的一个坑是端口冲突。9222 这个端口有时候会被其他调试工具占用如果连接失败可以先检查端口占用情况# macOS/Linux lsof -i :9222 # Windows netstat -ano | findstr 9222如果发现被占用换一个端口就行比如 9223同时记得把 BrowserSkill 配置里的CDP_PORT也改掉。2.3 第一次让 AI 操作浏览器的正确姿势连接通了之后不要一上来就让 AI 去操作复杂的后台系统。先从一个简单的页面开始比如让 AI 打开一个新闻网站提取首页头条的标题。这个过程中你可以观察 AI 是怎么理解你的指令、怎么选择操作方式的。一个典型的交互流程是这样的你对 AI 说帮我打开某某网站找到搜索框输入浏览器自动化然后告诉我搜索结果第一条的标题。AI 会先调用 BrowserSkill 的导航能力打开页面然后通过 DOM 查询定位搜索框元素执行输入操作再触发搜索最后提取结果。整个过程你可以在 Chrome 窗口里实时看到页面在自动滚动、输入、点击这种可视化反馈对于调试来说非常友好。注意第一次操作时建议把 Chrome 窗口放在可见的位置不要最小化。虽然 CDP 在后台也能工作但某些页面会检测窗口的可见性状态最小化可能导致渲染异常或者脚本执行被节流。3. 复用登录态背后的技术细节与边界条件3.1 用户配置目录里到底存了什么Chrome 的用户配置目录是一个包含大量文件和子目录的文件夹跟登录态直接相关的包括文件/目录存储内容对自动化的意义Cookies加密的 Cookie 数据库维持登录会话的核心凭证Login Data保存的账号密码自动填充登录表单时使用Local Storage各站点的 localStorage部分站点的 Token 存在这里Session Storage会话级存储页面关闭后失效但同一会话内可用Preferences浏览器配置影响页面渲染和脚本行为Extensions已安装扩展某些扩展会修改页面行为BrowserSkill 复用整个配置目录意味着上述所有数据都是可用的。这跟你在新开的无痕窗口里操作有本质区别——无痕窗口不加载任何已有 Cookie也不共享 localStorage等于是一个全新的访客身份。但这里有一个容易被忽略的细节Chrome 对 Cookie 等敏感数据做了加密加密密钥跟操作系统账户绑定。在 macOS 上密钥存在 Keychain 里在 Windows 上密钥通过 DPAPI 保护。BrowserSkill 之所以能直接使用这些数据是因为它连接的是同一个 Chrome 进程Chrome 自己负责解密BrowserSkill 只是通过 CDP 读取已经解密后的运行时状态。这也是为什么它不需要你提供任何密码——它根本不碰加密存储只操作内存中的会话。3.2 哪些场景下这个方案会失效复用登录态虽然方便但并不是万能的。以下几种情况需要特别注意第一种是站点使用了设备指纹绑定。有些安全级别较高的系统会把登录态跟设备的硬件指纹如显卡型号、屏幕分辨率、字体列表等绑定如果你换了机器或者改了硬件配置即使 Cookie 还在登录态也会失效。BrowserSkill 复用同一台机器的同一个浏览器配置通常不会触发这个问题但如果你把配置目录拷贝到另一台机器上就可能遇到。第二种是站点检测到 CDP 连接。虽然 CDP 本身是 Chrome 官方提供的调试协议但一些反自动化系统会通过检测navigator.webdriver属性、CDP 特有的运行时特征、或者页面加载时序的异常来判断当前浏览器是否被自动化工具控制。BrowserSkill 在这方面做了一些规避处理比如注入脚本覆盖navigator.webdriver的返回值但这不是万无一失的遇到检测严格的站点仍然可能被识别。第三种是登录态本身有短时效性。有些系统的会话 Token 有效期只有几十分钟过期后需要重新认证。BrowserSkill 无法自动续期你需要在 Chrome 里手动重新登录一次然后 AI 才能继续操作。3.3 多标签页和窗口管理的实际体验BrowserSkill 支持同时操作多个标签页这在处理需要跨页面比对的场景时很有用。比如你要从一个列表页提取所有详情页的链接然后逐个打开详情页抓取内容最后汇总。AI 可以打开多个标签页并行处理也可以在一个标签页里顺序导航。但实际使用中我发现标签页数量超过五六个之后AI 的上下文管理会变得混乱。它有时候会搞混哪个标签页对应哪个任务导致在错误的页面上执行操作。我的做法是尽量保持标签页数量精简完成一个任务就关掉对应的标签页并且在指令里明确告诉 AI 当前应该操作哪个页面。窗口管理方面BrowserSkill 可以创建新的浏览器窗口也可以复用已有窗口。如果你希望自动化操作不影响你当前正在浏览的页面可以让 AI 新建一个窗口来操作这样你的主窗口不受干扰。但要注意新建窗口仍然共享同一个用户配置目录所以登录态是通用的。4. 把 BrowserSkill 接入 AI Agent 工作流的几种玩法4.1 信息采集与整理从手动复制粘贴到自动汇总我日常用得最多的场景是信息采集。以前的做法是打开十几个标签页逐个阅读手动复制关键信息到笔记软件里。现在我把这个流程交给了 BrowserSkill 配合 AI Agent给 AI 一个起始 URL 和采集规则它自动翻页、提取、去重、格式化最后输出一份结构化的 Markdown 文档。具体操作上我会先让 AI 打开目标页面分析 DOM 结构确定要提取的字段对应的 CSS 选择器。这一步很关键因为不同网站的 DOM 结构差异很大AI 需要先看懂页面才能准确提取。BrowserSkill 提供了获取页面 HTML 和查询元素的能力AI 可以据此推断出合适的选择器。提取到数据后AI 可以直接在对话里输出表格也可以调用文件写入能力保存到本地。我通常会让它保存成 CSV 或者 Markdown 表格方便后续导入到其他工具里处理。整个流程从原来的半小时缩短到几分钟而且不会因为疲劳而漏掉信息。4.2 表单填写与批量操作把重复劳动交给 AI另一个高频场景是表单填写。很多后台系统需要定期录入数据字段多、格式要求严格手动填容易出错。BrowserSkill 可以让 AI 读取你提供的结构化数据比如一个 Excel 表格或者一段 JSON然后逐条填写到网页表单里。这里有一个实操技巧对于下拉框、日期选择器、富文本编辑器这类非标准输入控件直接设置value属性往往不生效因为前端框架如 React、Vue会监听特定的事件来更新内部状态。正确的做法是模拟真实的用户交互——先聚焦元素再触发input或change事件必要时还要模拟键盘输入。BrowserSkill 内部对这些情况做了处理但如果你自己写脚本扩展需要特别注意这一点。批量操作时建议加上适当的延迟。虽然 CDP 执行速度很快但目标网站的服务器可能有频率限制操作太快容易触发风控。我通常会在每条记录之间加 1 到 2 秒的随机延迟模拟人工操作的节奏。4.3 页面监控与变化检测让 AI 帮你盯着BrowserSkill 还可以用来做页面监控。比如你关注某个商品的价格变化、某个公告页面的更新、某个数据看板的指标波动可以设置一个定时任务让 AI 定期打开页面、提取关键数据、跟上次的结果对比有变化就通知你。这个场景下Chrome 需要保持运行状态BrowserSkill 才能连接到它。如果你的电脑会休眠或者关机监控就会中断。我的做法是把这套环境跑在一台常开的设备上Chrome 以调试模式启动后就不关了AI Agent 也保持运行。这样即使我不在电脑前监控任务也能持续执行。提示长时间运行的 Chrome 实例可能会因为内存泄漏而变慢建议每隔几天重启一次。可以在启动脚本里加一个定时重启的逻辑重启后重新登录需要的网站即可。5. 安全边界哪些事能做哪些事不能做5.1 凭证安全为什么不给密码不等于没有风险BrowserSkill 的核心卖点是密码不用给这确实降低了凭证泄露的风险。但这不意味着没有安全顾虑。AI Agent 通过 BrowserSkill 获得的浏览器控制权等同于你本人坐在电脑前操作浏览器。它能访问你所有已登录的网站能读取页面上的所有信息能执行页面上的所有操作。所以关键问题变成了你信任这个 AI Agent 吗如果你用的是本地部署的模型数据不出本机风险相对可控。如果你用的是云端 AI 服务那么页面内容会被发送到云端进行处理这就涉及数据隐私问题了。我的建议是对于涉及敏感信息的网站如网银、企业内部系统不要接入云端 AI如果确实需要自动化用本地模型或者自己写脚本。另一个容易被忽略的点是 CDP 端口的访问控制。前面提到过调试端口默认只监听本机但如果你在容器或者虚拟机里运行 Chrome端口映射配置不当可能导致端口暴露。务必确认--remote-debugging-port绑定的地址是127.0.0.1而不是0.0.0.0。5.2 操作边界AI 应该被允许做哪些事即使技术上有能力做也不代表应该让 AI 去做。我给 BrowserSkill 设定了几条硬性规则不执行任何涉及资金的操作转账、支付、下单不修改任何账号安全设置改密码、绑手机、改邮箱不删除任何数据。这些操作即使 AI 判断正确一旦出错后果也很严重不值得冒这个险。对于发布内容类的操作发帖、发文章、发评论我采取的是AI 准备、人工确认的模式。AI 负责打开页面、填写内容、上传附件但在点击最终发布按钮之前暂停等我确认后再继续。BrowserSkill 支持这种分步执行的模式你可以在指令里明确要求 AI 在关键步骤前停下来等待确认。5.3 合规使用尊重网站的使用条款自动化操作浏览器这件事本身不违法但具体到某个网站可能违反了它的使用条款。很多网站在服务协议里明确禁止使用自动化工具访问。大规模爬取、频繁请求、绕过访问限制这些行为轻则被封号重则可能涉及法律风险。我的原则是只对自己有权限访问的内容做自动化操作频率控制在合理范围内不绕过网站的任何技术保护措施。BrowserSkill 的设计初衷是提升个人效率不是用来做大规模数据采集的。把它用在这个定位上既安全又可持续。6. 实际跑下来遇到的几个坑和对应的解法6.1 页面加载完成不等于元素可用这是我在实际使用中最常遇到的问题。CDP 的Page.navigate命令返回时只代表页面开始加载不代表 DOM 已经就绪更不代表你要操作的元素已经渲染出来。对于用了前端框架的页面元素可能是异步渲染的导航返回后还需要等几百毫秒甚至几秒才能操作。BrowserSkill 内部有一些等待逻辑但不够智能。我的做法是在指令里明确告诉 AI打开页面后等待搜索框出现再操作。AI 会调用等待元素出现的能力轮询检查目标元素是否存在于 DOM 中。如果等了超过设定时间还没出现就报错而不是继续执行。另一个相关的坑是 iframe。如果目标元素在 iframe 里直接查询是找不到的需要先切换到对应的 iframe 上下文。BrowserSkill 支持 iframe 切换但 AI 有时候会忘记这一步导致操作失败。遇到这种情况我会在指令里明确说明目标元素在 iframe 内。6.2 弹窗和遮罩层的处理很多网站在首次访问时会弹出 Cookie 同意框、订阅提示、新手引导遮罩这些浮层会挡住页面元素导致点击操作被拦截。AI 如果不识别这些浮层就会一直点不到目标元素。处理方式有两种一种是让 AI 先检测页面上有没有常见的弹窗关闭按钮比如带有关闭同意跳过文字的按钮有就点掉另一种是在 BrowserSkill 的配置里预设一些通用的弹窗处理规则。我倾向于第一种因为不同网站的弹窗样式差异太大预设规则很难覆盖全。还有一种情况是弹窗出现有延迟页面加载完看起来干干净净过了两秒突然弹出来。这种就需要在操作前加一个短暂的等待或者用重试机制——如果点击失败等一秒再试一次。6.3 登录态过期后的自动恢复虽然 BrowserSkill 复用了登录态但登录态本身是有有效期的。我遇到过好几次 AI 操作到一半突然报错一看是登录过期了页面跳转到了登录页。这时候 AI 如果继续按原计划操作就会在登录页上乱点。我的解法是在关键操作前加一个登录态检查让 AI 先判断当前页面是不是登录页通过 URL 特征或者页面上的登录表单元素如果是就暂停任务并通知我手动登录。这个检查逻辑可以写成一个简单的判断不需要太复杂但能避免很多无效操作。对于登录态频繁过期的站点可以考虑在 Chrome 里安装一个自动刷新页面的扩展保持会话活跃。但这只对部分站点有效有些站点的会话过期是服务端控制的客户端刷新没用。6.4 性能调优让操作更快更稳BrowserSkill 默认的操作速度已经不错了但在一些细节上还可以优化。比如截图操作默认是全页面截图如果页面很长截图会很慢。如果只需要验证某个元素的状态可以只截取该元素的区域。另一个优化点是减少不必要的页面导航。如果多个任务在同一个页面上操作尽量合并指令避免反复打开关闭页面。每次导航都有网络请求和渲染开销累积起来很可观。还有就是合理使用 CDP 的Runtime.evaluate直接执行 JavaScript。对于一些复杂的 DOM 查询和数据提取用 JavaScript 一次性完成比通过多个 CDP 命令逐步操作要快得多。BrowserSkill 暴露了这个能力但 AI 不一定总是选择最优路径你可以在指令里引导它用 JavaScript 一次性提取所有需要的数据。7. 这套方案适合谁不适合谁BrowserSkill 最适合的场景是个人效率工具。你有一个日常使用的浏览器里面登录了各种网站你希望 AI 帮你自动完成一些重复性的浏览器操作比如信息采集、表单填写、页面监控。这种情况下BrowserSkill 的复用登录态特性直接消除了最大的障碍让你可以快速把想法落地。它不太适合的场景是大规模并发采集。BrowserSkill 连接的是单个浏览器实例虽然可以开多个标签页但并发能力有限而且共用同一个用户配置目录意味着所有请求都来自同一个身份容易被目标网站识别和限制。如果你需要做大规模采集还是应该用专门的爬虫框架配合代理池。另一个不适合的场景是无人值守的长期运行。BrowserSkill 依赖 Chrome 保持运行而 Chrome 在长时间运行后可能出现内存泄漏、页面崩溃等问题。虽然可以通过定时重启来缓解但整体稳定性不如无头浏览器方案。如果你的任务需要 7x24 小时不间断运行建议考虑其他方案。对于企业内部的流程自动化BrowserSkill 有一定的适用空间但需要评估数据安全风险。如果流程涉及敏感数据建议用本地模型配合 BrowserSkill避免数据外传。同时要做好操作审计记录 AI 的每一步操作便于追溯和排查问题。我在实际使用中的体会是BrowserSkill 最大的价值不是技术上的突破而是思路上的转变——它把让 AI 模拟人操作浏览器变成了让 AI 借用人的浏览器来操作。这个转变消除了登录态这个最大的摩擦点让浏览器自动化的门槛一下子降低了很多。当然它也有自己的边界和局限理解这些边界在合适的场景里使用它才能发挥出最大的价值。