最近被问得最多的一件事就是 Tencent BrowserSkill 这个项目的标题到底该怎么看。标题很长但信息量很大AI Agent、真实浏览器、已登录浏览器、本地桥、SSP。每个词单独拿出来我都见过放在一起就是一个很明确的场景——让编码 Agent 直接操作你电脑上那个已经登录好的浏览器。我断断续续跟了几周也拿自己的开发机做了几次实验。先说结论这套思路真正解决的不是“能不能让 AI 操作浏览器”的问题而是“AI 操作浏览器的时候能不能直接复用你现在的登录态别让我重新输一遍密码”的问题。对于做自动化、写 Agent 工具、搞浏览器任务流的开发者来说这几乎就是每天都要撞上的墙。这篇文章不准备写成一个项目说明书而是把我拆解这个项目标题的过程、背后技术路线的取舍、以及我实际落地时踩过的坑全部整理出来。如果你是第一次接触 AI Agent只需要知道 BrowserSkill 是一类“本地桥”工具如果你已经在用 Cursor、Cline、Codex 这类编码 Agent那这篇文章里的对比和配置步骤可以直接抄作业。1. BrowserSkill 到底是什么一拆标题全是关键信息1.1 “本地桥”三个字才是真正的主角很多人盯着“BrowserSkill”这个名字以为重点在“Skill”也就是某个 Agent 技能插件。但我把整个标题反复看了几遍之后反而觉得“本地桥”才是这个项目最关键的设计。所谓“桥”就是把两个本来不能直接对话的东西连起来。这里的两端一端是 AI Agent另一端是你电脑上正在运行的、已经登录了各种网站的真实浏览器。BrowserSkill 做的事情是在它们中间开一条本地通道让 Agent 可以通过这条通道往浏览器里下发指令比如“打开这个 URL”“点击某个按钮”“读取当前页面标题”然后拿到页面执行后的结果。为什么要强调“本地”因为浏览器就在你本机Agent 也在你本机数据不需要绕到远端服务器。你不需要把 Cookie 导出、上传、再让云端重新导入整个会话链路都发生在127.0.0.1上。这个设计对隐私保护有天然优势而且延迟低页面状态的变化可以实时反馈给 Agent。我自己的理解是BrowserSkill 的定位不是一个“浏览器”也不是一个“Agent”而是一层让二者互相借力的连接件。它默认的假设是——浏览器是用户的登录态是用户的Agent 只是一个受控的“操作者”。这个边界想清楚之后很多权限和会话问题就迎刃而解了。提示你可以把 BrowserSkill 想象成一个“代驾服务”车还是你的车钥匙也还在你手里AI Agent 只是坐在驾驶位上按照你的指令操作。它要做的是把自己长期积累的驾驶经验用在你的这辆车上。1.2 SSP 到底在架构里扮演什么角色标题末尾的“SSP”是另一个让人迷惑的点。在不同分支和不同团队的项目里这三个字母的展开方式不太一样有的写成 Session Sharing Protocol有的写成 Service Provider。我按自己在类似项目里的落地经验把它理解成一个“会话共享通道”或者“桥服务层”。它的职责简单说有三块发现并连接本地已有的浏览器实例通过浏览器调试协议拿到底层控制权把浏览器当前打开的标签页、登录状态、Cookie 环境封装成一个个“可复用会话”对外暴露一套统一的、Agent 能直接调用的接口屏蔽掉底层 WebSocket 和 DOM 操作的复杂性。这意味着当你启动 BrowserSkill 之后它不会像传统自动化工具那样去新起一个浏览器窗口而是优先去找你已经开着的那个浏览器进程建立连接。如果你的浏览器已经登录了某个后台系统Agent 拿到的就是一个带有完整登录态的“工作环境”直接可以开始点按钮、填表单。把 SSP 这一层拆开之后整个项目的分工就很清楚了。BrowserSkill 负责“技能层”告诉 Agent 能做哪些操作SSP 负责“通道层”保证这些操作能落到真实浏览器上。对于使用的人来说你只需要关心 Agent 能不能完成任务SSP 底层怎么管理会话那是设计者要考虑的事。1.3 这个项目适合谁解决什么问题我觉得最吃 BrowserSkill 这套方案的是下面几类人经常用 Cursor、Cline、Codex 等编码 Agent 的开发者希望 Agent 帮自己操作本地网页而不是写一堆样板代码需要反复处理“登录后页面”的任务型开发者比如从后台系统抓取自己的业务数据、批量填表、跨系统搬运信息在搭建自己的 AI Agent 应用但不想从零实现浏览器控制层的团队以及所有被“每次自动化都要重新登录、过验证码”折磨过的人。它解决的核心问题只有一个让 Agent 能站在你已经登录好的身份基础上工作。不丢会话、不重新鉴权、不需要绕过验证码这对真实业务场景来说非常值钱。2. 为什么 Agent 必须“借用”真实浏览器而不是自己开一个2.1 无头浏览器方案的老毛病早几年做浏览器自动化大家的默认方案是启动一个无头浏览器或者用 Playwright、Puppeteer 拉起一个全新的浏览器实例。这套方案在测试场景里没有问题但一旦放到 AI Agent 的真实任务里就会连续撞墙。首先是最头疼的登录问题。很多内部系统是 SSO 单点登录你让 Agent 去跑任务它打开页面之后发现需要登录弹出来的是企业身份认证页面又跳转、又要短信验证码Agent 根本处理不了。就算是一个普通的网站只要开启了人机验证Agent 的整套流程就会卡死在登录环节。其次是无头浏览器没有“历史积累”。你在日常浏览器里保存的常用登录状态、本地存储、插件环境在无头浏览器里统统不存在。相当于让一个新人第一天上班就要处理你已经干了三年的活儿所有上下文都得重新建立。还有指纹识别的问题。无头浏览器的运行环境特征和真实用户差别很大很多网站会做风控判断识别出是非真人操作后直接拒绝访问。与其花大量精力去伪装指纹、模拟真人行为不如直接复用你真实浏览器里的环境。这也是 BrowserSkill 这条路线最聪明的地方不做伪装直接用真实环境。2.2 复用已登录会话带来的连锁收益当你让 Agent 直接操作本地真实浏览器时第一层收益是省掉了登录环节。已登录的网站、已创建的 Cookie、已经生效的本地存储全部直接被 Agent 继承。省掉的不是一步操作而是一整条鉴权链路。第二层收益是上下文完整。你在浏览器里可能已经打开了十几个标签页有的在查资料有的在后台系统里Agent 可以直接在你这些标签页之间切换读取内容甚至在一个页面上填好数据后到另一个页面去提交。这种跨标签页的协作能力是独立浏览器实例很难提供的。第三层收益是减少“被发现”的概率。因为操作的就是真实浏览器网站的访问来源、浏览器指纹、Cookie 都和日常行为一致。Agent 在里面操作看起来更像是一个真人用户在自己的浏览器里干活而不是一个自动化程序从陌生环境里发来请求。不过这里我要非常认真地提醒一句能访问不代表应该访问。Agent 借用的是你真实身份任何操作都会被记录在网站的访问日志里权限边界必须由你来定义。只让你自己的 Agent 操作你有权限的数据和功能不要把包含敏感信息的会话共享给不受信任的任务脚本。2.3 “本地桥”和“云端浏览器”的路线之争现在行业内还有另一条路线就是把浏览器环境放到云端做成一个云端浏览器或者云桌面Agent 在云端操作。这条路线的优势是环境统一、可扩展团队协作时所有人都能操作同一个浏览器环境。但缺点也很明显。云端浏览器的登录态管理成本很高尤其是遇到企业级 SSO 时用户必须先把身份信息同步到云端这里面的安全隐患比本地方案大得多。对于个人开发者的日常任务把浏览器放在本地用 BrowserSkill 这种桥接方案反而是效率最高、信任模型最简单的方式。我的经验是如果是单机任务、个人开发、或者一个小团队内部的自动化优先选本地桥如果需要大规模并发执行、多人共享环境再考虑云方案。不要一上来就追求“大而全”的基础设施。3. BrowserSkill、Agent Browser、Playwright MCP 到底有什么区别3.1 三条不同的技术路线最近网上同时有几个概念很热一个是 BrowserSkill一个是 Agent Browser还有一个是 Playwright MCP。很多人以为它们是同一个东西其实三条路线的侧重点完全不同。Playwright MCP 的核心是“把 Playwright 的能力封装成 MCP 工具”。MCP 是现在 AI 编码工具普遍支持的插件协议你只需要在配置里加一段代码Cursor 或 Cline 就能直接调用一组“打开页面”“点击元素”“读取内容”的工具。它的使用场景偏向开发和测试强调精确的 DOM 定位和断言。Agent Browser 更偏向“给 Agent 专门做一个浏览器”相当于 Agent 自己的手和眼睛。它通常是一个嵌入式的浏览器组件Agent 可以直接在里面渲染页面、感知页面结构、执行操作自由度很高但说实话成熟度参差不齐很多只是把 Electron 包了一层浏览器内核。BrowserSkill 这条路线则非常聚焦我不给你一个新的浏览器也不只是给你一组通用测试工具而是帮你把“你手上正在用的浏览器”变成 Agent 的工作台。它强调的是会话复用和本地桥接把已有浏览器的能力开放出来。从实用角度说这三者不是竞争关系而是可以叠加的。你可以用 Playwright MCP 提供细粒度的页面操作能力同时用 BrowserSkill 的思路去复用登录态也可以让 Agent 在 BrowserSkill 桥接的真实浏览器里执行任务遇到精确断言时再切到 Playwright 工具。关键是要理解每条路线的边界在哪里。3.2 选型对照表维度BrowserSkillPlaywright MCPAgent Browser浏览器来源复用本地已运行的浏览器由 Playwright 自行启动新实例内嵌的专用浏览器组件登录态直接继承已有会话默认不保留需额外处理需单独维护会话状态核心优势真实环境、低风控、省鉴权定位精确、断言能力强与 Agent 集成深度高适用场景真实业务页面任务网页自动化测试定制化 Agent 交互界面学习成本中等需理解桥接协议低MCP 生态成熟高通常需要二次开发3.3 我实际选择的参考思路我自己在做一个内部工具的时候纠结过很久是接 Playwright MCP 还是自己搭一条 BrowserSkill 式的桥。最终选择后者的原因只有一条我需要操作的页面全都依赖登录态而认证过程涉及不少跳转和验证码。如果走 Playwright MCP 路线我需要提前把所有 Cookie 塞进新启动的浏览器里Cookie 过期后又要重新处理。而我自己真实浏览器里是长期保持登录状态的中间可能还插了二次验证这些状态根本无法干净地迁移到新环境。所以我的判断是如果任务目标是“帮我在网上查资料、操作后台、填表”优先考虑 BrowserSkill 这类本地桥方案如果任务是“测试我的网页应用在不同的视口尺寸下是否正常”那 Playwright MCP 仍然是首选。4. 从 0 到 1 搭建让编码 Agent 跑通真实浏览器本地桥4.1 准备本地浏览器环境开始配置之前先把浏览器和调试端口准备好。BrowserSkill 这类桥接工具普遍依赖浏览器自带的调试接口来取得控制权。浏览器默认不会对外暴露调试能力所以需要手动开启。在 Windows 上先关掉已经运行的浏览器实例然后通过命令行启动一个新的 Chrome命令类似下面这样chrome.exe --remote-debugging-port9222 --user-data-dirC:\Users\你的用户名\.browserskill-profilemacOS 上对应的命令是/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --remote-debugging-port9222 \ --user-data-dir$HOME/.browserskill-profile这里有几个很关键的细节--user-data-dir必须指定一个新目录不要用默认配置目录否则你会发现启动失败因为浏览器不允许两个进程共用同一个用户数据目录端口号建议固定我习惯用 9222因为这是调试协议最常用的默认端口启动之后不要关掉这个终端窗口浏览器进程会一直占着这个调试端口建议把“自动打开主页”关掉用空标签页启动避免 Agent 操作时被干扰。启动之后验证一下端口是否正常工作。打开浏览器访问下面这个地址或者用命令行请求curl http://127.0.0.1:9222/json/version如果能看到一段返回 JSON里面包含webSocketDebuggerUrl这样的字段就说明浏览器调试接口已经就绪可以开始接入桥服务了。4.2 下载并启动 BrowserSkill 桥服务接下来是安装桥服务本身。不同团队的发布方式不一样有的是 Python 包有的是 Node 包。我的开发机本来就有 Python 环境所以我优先选了 pip 安装的方式命令大致是pip install browserskill如果团队发布的是 Node 版本也可以用 npm 的方式启动。具体包名以官方 README 为准但安装思路都是同一个把桥服务装到本机让它去连接刚才开启的 9222 端口。安装完成后启动桥服务的命令行参数通常只需要指定浏览器调试端口和桥服务自己的监听端口browserskill --browser-port 9222 --service-port 8787这里的 8787 是我习惯选的范围你可以改成任意未占用的端口。启动成功后终端会打印一行日志提示桥服务已经监听在127.0.0.1:8787。到这里本地链路已经通了真实浏览器在 9222 端口桥服务在 8787 端口下一步就是让 Agent 连接到桥服务。4.3 配置编码 Agent 连接现在需要把桥服务暴露给编码 Agent。如果你用的是支持 MCP 的工具比如 Cursor 或者 Cline可以在 MCP 配置文件里加一段 Server 定义让 Agent 自动加载 BrowserSkill 提供的工具集。以 JSON 配置文件为例基本结构是这样的{ mcpServers: { browserskill: { command: npx, args: [-y, tencent/browserskill-mcp], env: { BROWSERSKILL_BROWSER_PORT: 9222, BROWSERSKILL_SERVICE_PORT: 8787 } } } }配置完成之后重启编码工具Agent 侧就会多出一组以browser_开头的工具调用能力比如读取当前标签页、访问指定页面、点击页面元素、输入文本等等。如果你的编码 Agent 不走 MCP而是通过 HTTP 调用工具那可以直接把请求发到桥服务上。一个简化版的任务请求大概长这样import requests task { session: default, steps: [ {op: goto, url: https://example.com}, {op: wait, ms: 1000}, {op: extract, selector: h1} ] } resp requests.post(http://127.0.0.1:8787/task, jsontask) print(resp.json())这个任务的意思是让桥服务调度真实浏览器打开一个页面等待一秒然后提取标题内容。底层是怎么通过 WebSocket 控制浏览器的完全不用关心。如果你刚开始接触 MCP我给你一个最简单的理解方式MCP 就是一个“工具插槽”编码 Agent 通过它拿到额外能力。你在配置里告诉 Agent“这里有一套浏览器工具”Agent 就会在合适的任务里去调用它们。4.4 一个完整的真实场景演示我拿一个常见的“读取登录后数据”场景来走一遍完整链路。假设我在某个后台系统里已经登录现在想写一个 Agent 任务让它打开系统里的“项目列表”把今天的任务项摘出来。我不需要告诉 Agent 账号密码也不需要处理登录跳转只需要给它一个目标描述。在 Cursor 的对话框里我输入这样一段需求请打开后台系统的项目列表页把状态为“进行中”的项目名称和截止日期整理成表格粘贴到当前对话里。由于 BrowserSkill 工具已经接入Agent 会这样工作调用browser_activate_tab找到已经打开的浏览器标签页调用browser_goto进入项目列表页等待页面渲染这个过程中 Agent 会主动调用browser_wait或“sleep”操作调用browser_extract_text读取页面表格内容把结果整理成 Markdown 表格返回。整个流程中没有任何一步涉及登录。这就是 BrowserSkill 最核心的价值也是我在实际实验里最满意的地方。4.5 从 0 到 1 搭建自己的 AI Agent 时怎么复用这套思路如果你不是用现成的编码 Agent而是想从零搭一个自己的 AI Agent 练手项目那 BrowserSkill 的思路也完全值得借鉴。最简单的架构是三层模型层负责意图理解和任务拆解工具层负责执行具体操作桥接层负责连接真实浏览器。模型层可以选你习惯的大模型接口工具层自己定义几个函数桥接层直接用 BrowserSkill 这样的服务。我搭练手项目时会在 Python 里定义这样的工具函数def call_browser(task: dict): resp requests.post(http://127.0.0.1:8787/task, jsontask) return resp.json() tools [ { type: function, function: { name: call_browser, description: 在本地真实浏览器中执行页面操作, parameters: { type: object, properties: { task: {type: object, description: 浏览器任务描述} } } } } ]然后把call_browser作为工具传给模型。这样模型在做任务规划时如果判断需要打开网页就会生成一段符合 schema 的参数你的代码再把它转发给桥服务。前前后后也就是几十行代码的事非常适合用来理解 Agent 工具调用的完整流程。5. 实操里的常见问题与排查实录5.1 端口连不上桥服务启动失败我在实验中最常遇到的问题是 9222 端口起不来。启动浏览器时如果开了隐身模式或者已有浏览器用了同一个默认用户目录新进程会直接退出端口自然也就连不上。排查步骤比较固定先杀掉所有浏览器进程再确认命令行里的--user-data-dir指向了一个独立目录最后重新启动。如果还是连不上用netstat或者lsof查一下端口是不是被其他程序占了。netstat -ano | grep 9222如果端口已经被占用说明你上次启动的浏览器还没有完全退出需要先结束对应进程。5.2 登录态“丢了”Agent 看到的页面没登录这个问题很多人会误认为是 BrowserSkill 的 bug其实大概率是浏览器实例选错了。你需要确认 Agent 操控的浏览器窗口就是你平时手动登录过的那个浏览器。如果你在启动调试模式时指定了一个全新的user-data-dir这个目录里是没有任何登录 Cookie 的自然是一片空白。解决办法有两个方向一是把调试模式挂到你日常使用的浏览器配置目录下但一定要先完全退出浏览器再启动二是重新登录一次。从实际使用体验看我更推荐单独维护一个“工作浏览器目录”在里面登录一次需要用的后台系统之后长期复用。Cookie 有有效期过期之后再登录一次即可。5.3 Agent 操作速度太快页面还没加载完就报错页面加载是个异步过程Agent 经常在上一个指令执行完的瞬间就发起下一个指令结果元素还没渲染出来就报找不到节点。这个问题我刚开始几乎每周都要踩一次。我现在的习惯是在 Agent 的指令模板里强制加一步“等页面空闲”比如等待页面进入就绪状态或者干脆让工具提供wait_for_selector这种显式等待机制。如果你用 HTTP 方式手动写任务那就在步骤里加毫秒级的等待时长。这里的关键不是等待时间越长越好而是要“有节奏”比如短任务 500 到 1000 毫秒长任务等元素出现后再操作。5.4 多个任务同时操作一个浏览器互相干扰BrowserSkill 复用的是本地真实浏览器如果同时有两个 Agent 任务在跑它们操作的是同一个页面树很容易互相覆盖。我先执行一个任务把页面跳到了 A 页面另一个任务却想把页面切到 B 页面最后两边都乱掉。对于个人使用我建议一个浏览器实例同一时间只挂一个任务。如果你确实需要并发那就启动多个浏览器实例每个实例用不同的调试端口和独立工作目录再分别桥接。端口可以从 9222、9223、9224 依次递增桥服务这边也对应多开。5.5 操作过于频繁触发网站风控真实浏览器虽然能降低被识别的概率但如果你在同一秒内连续点击、提交表单网站后台还是会看到异常行为特征。我自己试过极端情况一分钟内让 Agent 反复刷新同一个页面结果直接被临时限制了访问。给 Agent 布置任务时尽量模拟人的操作节奏点击之间留出几百毫秒到一秒的停顿翻页的时候先滚动一下再读取内容提交表单前增加一次确认。这些细节听起来小实际上能避免大量麻烦。6. 落地之后必须想清楚的边界6.1 权限边界不是工具能替你控制的BrowserSkill 类工具有一个天然的便利也有一个天然的隐患它的权限就是你的权限。Agent 能以你的身份在浏览器里做任何事包括发送消息、删改数据、提交订单。所以在真正使用之前一定要把任务范围限定清楚。我现在的做法是只让 Agent 操作只读类任务比如查询数据、整理页面信息、填写草稿所有涉及“提交”“删除”“发送”的操作都强制经过人工确认。如果你的 Agent 框架支持工具级权限控制就把这些高风险工具单独隔离。6.2 会话数据是敏感资产别到处共享已登录浏览器里的会话数据价值很高一个登录态的泄露等于你的账号被直接接管。因此桥服务只监听本机回环地址已经是底线了不要为了图方便把它暴露到局域网或者公网。同时也不要随便把包含 Cookie 的浏览器数据目录复制到其他机器上尤其是交给不可信的任务脚本去用。你的浏览器目录里不仅有登录信息还有浏览历史、缓存、表单数据这些都是隐私。6.3 哪些场景值得用哪些场景别硬上从收益角度看BrowserSkill 最适合的场景是“高登录成本、低操作频率”的任务比如你自己经常用的业务系统、内部数据看板、需要身份信息的在线工具。反过来如果只是抓取公开的静态信息或者测试一个不涉及登录的页面那直接用传统自动化工具可能更轻量不用把整个桥接链路都拉起来。工具本身没有优劣关键是场景匹配。6.4 日志和审计别等出事再补Agent 操作真实浏览器的时候最好在桥服务层保留一份详细的操作日志记录每一步执行的时间、操作类型和结果。我自己的项目里每个任务都会落一个 JSON 日志文件包含任务 ID、调用了哪些工具、页面 URL 发生了什么变化。这份日志在平时看起来没什么用但一旦出现误操作或者你想复盘 Agent 为什么做了某个决定它就是唯一可信的线索。日志不需要很复杂重点是“事件可回溯”。7. 一点个人体会我实际用下来最深的体会是技术难度从来不是这类项目的门槛真正的门槛是“信任边界”。BrowserSkill 把已登录浏览器开放给 AI Agent本质上是在说“我允许一个自动程序代表我去操作现实世界里的网页账号”。这个决定需要你在能力、权限、风险之间找到自己的平衡。前段时间我做了一个数据整理任务Agent 通过本地桥打开了我已经登录的后台系统跨了五个标签页把信息汇总成了一张表。整个过程它没有问一次密码我没有做任何额外授权配置但站在旁边看它操作的时候我反而比平时更谨慎地盯着每一个动作。这种“信任但不盲信”的感觉可能就是这类工具最真实的使用状态。如果你准备上手试我的建议是从最小任务开始打开一个你已经登录的无害页面让 Agent 读取标题再逐步增加复杂度。先把本地链路跑通把日志和权限边界设置好再让 Agent 碰真正重要的数据。这样试错成本最低也能更快理解“本地桥”这个设计的精妙之处。