1. 这个项目到底在解决什么痛点AI Agent 这两年火得一塌糊涂但真正动手搭过的人都知道最烦人的环节往往不是模型选型也不是提示词调优而是浏览器自动化里的登录态问题。你想让 AI 帮你抓个后台报表、填个工单、跑一遍内部系统的巡检流程第一步就卡住了——目标站点要登录而 AI 手里没有你的账号密码就算你把密码给它短信验证码、扫码登录、二次验证这些关卡照样过不去。腾讯开源的 BrowserSkill 就是冲着这个场景来的。它的核心思路一句话就能说清楚AI 不碰你的密码而是直接复用你本机浏览器里已经登录好的会话。你平时用 Chrome 登录过的那些站点AI 通过 BrowserSkill 就能以你本人的身份去操作密码、Cookie、Token 全程不经过 AI 的手也不需要你把凭据写进任何配置文件。这件事的价值在哪儿我举个实际例子。假设你在一家公司做运营每天要从三个后台系统导出数据、汇总成表。这三个系统都有登录而且都开了短信验证。传统做法是写脚本模拟登录但短信验证这一关基本无解除非你去对接短信平台或者搞个手机转发工程量巨大还容易失效。BrowserSkill 的路子完全不同你自己先在 Chrome 里正常登录好然后让 AI 接管这个已经登录的标签页去点按钮、读数据、下载文件。对目标系统来说操作者就是你自己风控层面几乎无感。适合谁来用三类人最直接受益。第一类是做 AI Agent 开发的工程师尤其是需要让 Agent 操作真实 Web 系统的场景第二类是企业内部搞 RPA 或流程自动化的同学以前用 Selenium、Playwright 写脚本登录态维护是个老大难现在可以换个思路第三类是对 AI 自动化感兴趣的个人开发者想拿它做点个人效率工具比如自动整理某个已登录平台的数据。需要提前说清楚的是BrowserSkill 不是绕过登录的工具它恰恰相反——它依赖你已经合法登录的状态只是把这个状态安全地借给 AI 使用。这个定位很重要决定了它的使用边界和合规性。2. 核心设计思路拆解2.1 为什么是复用已登录浏览器而不是托管密码市面上让 AI 操作浏览器的方案大致有三条技术路线我把它们的取舍列出来对比一下你就能明白 BrowserSkill 为什么选这条路。方案登录态来源密码是否暴露验证码处理维护成本适用场景脚本模拟登录代码里存账号密码暴露难需额外对接高站点改版就崩无验证码的简单站点凭据托管服务集中存储密码集中暴露风险部分支持中但安全责任大企业统一身份场景复用已登录会话用户本机浏览器不暴露用户手动过一次即可低跟随用户操作真实业务系统操作第三条路线的精髓在于把认证和操作这两件事解耦。认证这一步交给人来做因为人本来就擅长处理各种花式验证操作这一步交给 AI因为重复劳动正是 AI 的强项。两者通过浏览器这个共享工作台衔接起来。这个设计还有个隐藏好处风控友好。很多系统会检测登录环境的一致性如果 AI 用一个全新的 IP、全新的设备指纹去登录很容易触发风控。而 BrowserSkill 复用的是你本机的真实浏览器环境指纹、IP、历史行为都是连续的系统看到的就是这个用户今天又在正常操作不会平白无故弹验证。2.2 浏览器扩展 本地服务的双组件架构BrowserSkill 的架构我理解下来是浏览器扩展加本地服务的组合。为什么非要拆成两块这里面的考量挺值得说。浏览器扩展负责的是贴近页面的活儿读取 DOM、模拟点击、监听网络请求、管理标签页。这些能力必须跑在浏览器进程里扩展是最合适的载体。但扩展有个天然短板——它的能力被浏览器沙箱限制得比较死跨域请求、文件系统访问、长连接维持这些都不太方便。本地服务补的就是这块短板。它跑在你本机作为一个独立的进程可以对外提供一个标准接口通常是 HTTP 或 WebSocketAI 侧通过这个接口下发指令本地服务再转成扩展能理解的消息扩展执行完把结果回传。这样一来AI 不需要直接跟浏览器打交道中间隔了一层稳定的协议层扩展升级、浏览器版本变化都不会直接影响 AI 侧的调用逻辑。提示这种扩展 本地服务的分层是当前浏览器自动化类工具比较主流的设计。理解了这个分层后面排查问题时你就知道该往哪一层找原因——是扩展没注入成功还是本地服务没起来还是 AI 侧协议对不上。2.3 权限最小化AI 只能看到该看的BrowserSkill 在权限控制上做了收窄。AI 拿到的不是整个浏览器的完全控制权而是针对特定标签页、特定操作的能力。比如你授权它操作某个后台页面它就只能在这个页面的上下文里活动读不到你其他标签页的内容也拿不到浏览器的密码管理器数据。这个设计背后的逻辑是信任边界。AI 再聪明它也是个外部程序把整个浏览器的控制权交出去风险太大。收窄到单页面 白名单操作这个粒度即使 AI 侧出了问题影响范围也可控。实际用的时候你会发现每次授权都是针对具体任务的任务结束授权就失效不会长期挂着一个全权限通道。3. 核心能力与实操要点3.1 环境准备装什么、怎么装动手之前先把环境理清楚。BrowserSkill 的运行依赖三样东西一个基于 Chromium 的浏览器Chrome 或 Edge 都行、BrowserSkill 的浏览器扩展、以及本地服务程序。浏览器这块建议用较新版本的 Chrome。太旧的版本比如 Chrome 109 这种在扩展 API 支持上可能有差异虽然不一定跑不起来但踩坑概率高。装扩展的方式通常是加载已解压的扩展程序或者从扩展商店安装具体看官方给的包是哪种形式。本地服务的安装一般是个可执行文件或者需要 Node.js 环境跑的脚本。我建议优先用官方提供的打包版本省得自己配依赖。如果非要自己跑源码注意 Node 版本别太低很多现代扩展通信库对 Node 版本有要求。注意安装扩展后记得在扩展管理页面确认它已经启用并且授予了必要的权限比如读取和更改网站数据。权限没给全后面操作会莫名其妙失败而且报错信息往往不直观。3.2 建立连接让 AI 找到你的浏览器环境装好后第一步是让 AI 侧和本地服务建立连接。这个过程通常是启动本地服务它会监听一个本地端口然后在 AI 侧的配置里填上这个端口或者连接地址最后在浏览器里点一下扩展图标确认扩展和本地服务握手成功。握手成功的标志一般是扩展图标变成激活状态或者本地服务的日志里出现client connected之类的记录。这一步如果卡住九成是端口被占用或者防火墙拦了本地回环。排查方法很简单先用浏览器直接访问本地服务的健康检查地址看能不能返回正常响应能返回说明服务本身没问题问题在扩展侧不能返回就往服务侧查。连接建立后AI 侧一般会拿到一个当前可用标签页的列表。你可以指定让它操作哪一个标签页也可以让它新开一个。我的习惯是专门开一个标签页给 AI 用不要和自己的工作标签混在一起这样既清晰又安全任务结束直接关掉就行。3.3 授权粒度哪些操作放行哪些拦住BrowserSkill 的授权是可以细调的。常见的授权维度包括允许访问哪些域名、允许执行哪些类型的操作读、点击、输入、下载、单次任务的有效时长。我的建议是按任务授权不要图省事给全量权限。比如这次任务只是读一个报表页的数据那就只授权读操作和那个域名点击和输入都不开。这样即使 AI 理解错了指令它也做不出破坏性动作。等下次任务确实需要点击了再单独开点击权限。授权信息一般存在本地服务的配置里或者通过 AI 侧的指令动态下发。动态下发更灵活但要注意每次任务结束后主动回收别让授权一直挂着。3.4 指令下发AI 怎么告诉浏览器干活AI 侧下发指令的格式通常是结构化的 JSON描述在哪个页面、对哪个元素、做什么操作。比如点击 id 为 submit-btn 的按钮、读取 class 为>