★ FEATURED ARTICLE 今年在折腾 AI Agent 自动化的时候我遇到一个特别扎心的场景想让 Agent 帮我把一个后台系统里几十条数据导出来结果它卡在登录页反复尝试最后还被验证码教育了一顿。后来我开始尝试 Tencent BrowserSkill思路一下子清晰了——与其让 Agent 从零开始“当陌生人”不如把你自己已经登录好的浏览器通过一条本地通道直接借给它用。这个工具解决的就是这个痛点。它本质上是一条本地桥连接着你正在使用的 Chrome/Edge 和你手边的编码 Agent比如 Claude Code、Codex、Cursor 这类。Agent 通过标准接口下发操作指令你的真实浏览器执行然后把页面状态、DOM、截图再传回去。这样一来Agent 不需要知道你的密码不需要处理验证码也不需要重新认识你公司的复杂 SSO 流程它只需要在你的登录态肩膀上干活。这篇内容我会从原理到实操把它拆开覆盖本地桥的组成、SSP 这个比较容易让人困惑的缩写、如何接入编码 Agent以及我在实际使用中踩过的各种坑。你要是也想让 AI Agent 真正“替人办事”而不是在登录页打转这篇应该能帮上忙。1. 项目整体思路与价值拆解1.1 编码 Agent 的浏览器困境编码 Agent 这几年的能力进步很快能读代码、改文件、跑命令但一谈到浏览器操作就特别容易翻车。原因很简单浏览器自动化链条里登录态是最难跨越的一道坎。几乎所有正经产品都有登录、验证码、风控动不动就要多因子认证。你让 Agent 自己去注册一个账号环境不同立刻触发风控你让 Agent 用你平时填好的账号它没有你的 cookie 和 localStorage你让它无头浏览器硬闯很多站点直接拒绝访问。所以大家后来转向一个妥协方案让 Agent 借助 Playwright、Puppeteer 这类工具从零启动浏览器再引导它手动操作登录。这条路看起来可行实际上每个站点都要定制脚本验证码还可能人机交互维护成本极高。BrowserSkill 要打破的就是这套逻辑。它选择了一个更接地气的方式浏览器是你自己已经打开的那个登录态是你自己已经建立好的Agent 只是通过本地桥去“借用”这个窗口。这一步从架构上就绕开了登录、验证码、风控这类问题把难度瞬间降低了一个量级。1.2 真实浏览器加已登录会话为什么值钱很多人会低估“已登录浏览器”的价值我举一个实际例子。我经常需要去一个内部运营后台处理数据那个后台有公司自建的 SSO 登录流程还绑定了手机令牌。以前我最怕让 Agent 碰它因为自动化工具根本迈不过去认证这关。但用 BrowserSkill 之后我只需要先把浏览器登录好Agent 借用的就是一个已经完成认证的会话。它能直接打开后台页面读取列表点击按钮甚至提交表单——所有操作都发生在同一个真实会话里服务端看到的请求环境也和正常用户完全一致。风控模型很难区分这是不是你本人操作因为底层就是同一个浏览器指纹、同一套 cookie、同一条网络链路。这个思路背后的价值是把对“身份”的管理留给用户自己把对“操作”的执行交给 Agent。浏览器替你保管身份Agent 替你干活。这种分配既有安全性又有可用性。1.3 BrowserSkill 在同类工具里的定位现在市面上已经有一些浏览器自动化方案比如 Playwright MCP、Agent Browser、browser-use 等不少博主都推荐过。BrowserSkill 和它们最大的不同在于连接方式更“人性化”。很多方案默认 Agent 自己启动一个浏览器实例然后通过 CDP 协议连接。BrowserSkill 则更倾向于让你连接当前已经在用的浏览器进程——包括你手动开的窗口。这也意味着你现有的扩展、代理配置、登录态、下载文件时的用户行为全部都能被 Agent 复用。另外它的抽象层次很舒服不是直接让 Agent 写 CDP 底层命令而是封装成一组面向任务的动作比如打开页面、点击元素、读取文本、滚动、换标签页、截图等。Agent 不需要理解浏览器内部协议细节只需要告诉它“我要在搜索框里输入关键词”剩下的事情由桥接层翻译给浏览器。这样做的好处是编码 Agent 可以像调用普通函数一样调用浏览器能力大大降低接入成本。如果你是做 AI 应用开发的不用再自己造一套浏览器同层机器直接用它当中间层就行。2. 核心原理拆解本地桥是怎么搭起来的2.1 从 CDP 到 MCP协议之间发生了什么要理解 BrowserSkill首先得搞清楚两套协议。浏览器侧主流是 CDPChrome DevTools Protocol就是 DevTools 用的那套调试协议。它能力很强能控制页面、网络、DOM但语法很底层对 AI Agent 来说直接调用学习成本太高。MCP 则是模型上下文协议Model Context Protocol是现在 Agent 工具接入的事实标准提供的是“工具列表、函数调用、参数校验”这类高层接口。本地桥的核心工作就是把 CDP 翻译成 MCP或者翻译成 Agent 能直接调用的 HTTP/函数接口。你可以在桥接层里定义一串工具比如browser.navigate、browser.click、browser.get_text每个工具内部再通过 CDP 去操作浏览器。Agent 只需要在模型上下文里看到这些工具名和参数说明就能自己决定什么时候调用、传什么参数。这个翻译过程就是整条链路里最有工程价值的代码。2.2 SSP 到底是什么标题里面带了一个缩写“SSP”我第一次看到也是一头雾水。结合整个项目的架构我认为它在这里更像是“Session Stream Proxy”一类的说法——一条会话流代理链路。可以简单理解成SSP 是本地桥的协议层标识负责把浏览器会话里的各种事件、状态、操作结果组织成流式数据供 Agent 侧消费。它不是传统意义上的某个标准协议更像是给这套本地桥起的一个项目代号。实际使用中你不需要直接跟 SSP 打交道只需要通过 MCP 工具配置把它接入即可。但理解这个缩写有它的意义当你看到日志里出现ssp开头的报错就可以知道这多半是桥接层在转发会话数据时出了问题而不是你的浏览器本身出了问题。2.3 三方协作的数据流一次完整操作大致是这样走的用户在浏览器里打开自己的页面完成登录保持窗口不关闭。用户启动 BrowserSkill 本地服务指定浏览器调试端口或进程 PID。编码 Agent比如 Claude Code的 MCP 配置里指向本地服务的地址加载工具列表。Agent 根据用户需求生成计划调用navigate、click、extract等工具。本地服务收到调用后通过 CDP 与浏览器通信在真实页面里执行操作。页面状态变化、 DOM 信息、截图结果通过本地服务返回给 Agent。Agent 根据返回内容继续决策循环执行直到任务完成。这整个过程对用户来说是可见的你鼠标还落在浏览器上你能看到页面自己在动但它是被 Agent 操纵的。所以你不用“盲信” Agent它每一步操作你都能观察随时可以喊停。3. 实操把 BrowserSkill 接入编码 Agent3.1 环境准备一个能连调试端口的浏览器实际操作第一步不是说“装个软件”而是先让浏览器允许本地方便接入调试协议。我用 Chrome 来举例。你需要以带远程调试端口的模式启动浏览器比如在命令行里指定/path/to/chrome --remote-debugging-port9222 --user-data-dir/tmp/browserskill-profile这里有两个关键点。第一--user-data-dir要单独指定一个目录或者指向你自己常用的用户数据目录。如果指向默认目录可能会和已运行的浏览器实例冲突。第二端口要固定因为后面配置本地桥时需要用到。如果你用的是已经打开的浏览器窗口不想重启也有办法。很多新版本 Chromium 支持在运行时开启调试端口或者借助扩展把调试接口暴露给本地方便。但我实际操作下来最稳的方案还是通过启动命令显式开启这样端口、用户目录、日志都一目了然。另外注意如果浏览器之前有过headless模式建议关掉因为不少网站会对无头环境做检测。BrowserSkill 的优势就在于你能用有头模式进程可见登录态自然也不会被简单识别。3.2 启动本地桥服务拿到 BrowserSkill 仓库后一般通过 Node 或者 Python 的常见方式启动。我假设它是 Node 项目操作流程大致是这样先安装依赖npm install然后启动桥接服务npm run start -- --port 8787 --debug-port 9222这里--port是本地桥监听的端口--debug-port对应浏览器的调试端口。你也可以直接修改配置文件把这些参数写进去我看过不少项目都喜欢用环境变量来管理。启动成功以后你可以在终端看到它打印出本地服务地址比如http://localhost:8787以及它检测到的浏览器版本、标签页数量。到了这一步桥接层已经能和浏览器通信了接下来只要让 Agent 接入即可。3.3 配置编码 Agent 的 MCP 工具我现在常用支持 MCP 的编码 Agent比如 Claude Code。配置 MCP 通常是在项目根目录或用户配置目录里增加一个 JSON 配置项。大致长这样{ mcpServers: { browserskill: { command: npx, args: [-y, browserskill-mcp-server], env: { BROWSERSKILL_ENDPOINT: http://localhost:8787 } } } }不同 Agent 的配置方式略有差别但核心思路一致让 Agent 拉起一个 MCP client指向本地桥服务。加载成功以后Agent 上下文里会出现一组浏览器工具你可以直接用自然语言让它“打开这个链接”、“把页面上第一个表格内容读出来”。有一个细节值得注意如果 Agent 运行在远程机器上或者跑在容器里它访问localhost指向的是容器自身不是宿主机。这时候endpoint要写成宿主机局域网 IP或者用host.docker.internal这类方案。我在远程开发环境里就踩过这种坑后面会专门说。3.4 一个完整的小任务演示我用一个真实场景来做演示让 Agent 去登录后的 GitHub 仓库页把项目的 star 数字读取出来再切换到一个 issue 页面提取标题列表。配置好 MCP 之后我只是在对话里输入了一句“用我的浏览器去打开https://github.com/some/repo把 star 数读出来然后看下最近的三个 issue 标题。”Agent 的动作大致是调用browser.get_tabs查看当前标签页。调用browser.navigate打开目标网址。调用browser.get_text定位页面上的 star 按钮文本。打开 issue 标签页调用browser.query_elements提取列表信息。汇总结果返回给我。整个过程页面切换大概十几秒浏览器里能看到标签页自己跳动不用我介入。这个体验比之前用脚本硬编码要舒服太多因为 Agent 能根据页面实际内容动态调整策略遇到弹窗提示、页面跳转都能自己处理。如果你是第一次测试我建议用一个简单的静态页面练手先确认链路通顺再去挑战真实业务系统。4. 常见问题与排查技巧实录4.1 连接类问题我先整理几个我最常遇到的连接问题。一个是“端口无法连接”。浏览器调试端口要确认真的开了检查方法是直接用 curl 访问curl http://localhost:9222/json/version如果返回 JSON 里有Browser字段说明浏览器调试服务是正常的。如果报错多半是浏览器启动参数没生效或者端口被占用。另一个是“本地桥服务起来了但 Agent 一直说找不到工具”。这种问题 90% 是 MCP 配置里的command或args写错了。用npx -y拉包时网络环境不稳定也经常导致模块加载失败。可以先用终端手动跑一次 MCP server 命令看有没有报错再放回 Agent 配置里。4.2 登录态与会话权限问题“Agent 打开的页面为什么没有登录态”这个问题我遇到过几次。核心原因是浏览器实例被重复启动后用户数据目录发生混乱。你手动开了一个浏览器窗口用着 A 目录Bridge 又拉起来一个用着 B 目录两者完全不是同一个会话。解决办法就是统一用户数据目录确保 Agent 操作的就是你已经登录的那个窗口。最好在浏览器启动时就固定参数比如用一个专用的 user-data-dir登录状态保存在那里后续所有 Agent 操作都复用同一个实例。还有个常见情况是“Agent 能操作页面但点提交时被拦截”。这类多半是网站内有更强的安全策略比如检测到自动化特征。BrowserSkill 用的是真实浏览器大部分情况下不会被拦但如果你使用的浏览器本身装了隐私插件、去广告脚本也可能影响页面行为。遇到这种情况先把它切换到干净一点的普通窗口试试能缩小排查范围。4.3 安全与性能细节本地桥最让人担心的是安全。因为只要能访问到本地服务就等于能控制你的浏览器风险极高。所以我强烈建议不要把--port绑定到0.0.0.0默认只监听127.0.0.1。不要轻易在生产机器长时间开启 Bridge用完就关。如果需要在远程环境使用至少加一层 Token 校验。性能方面如果 Agent 高频调用query_elements每轮都全量返回 DOM 可能会拖慢整个链路。好一点的桥接实现会做智能筛选只返回交互元素。但你在任务描述里也可以主动让 Agent“只提取必要信息不要返回全部页面文本”这样能显著降低响应延迟。4.4 常见问题速查表症状可能原因处理方式Agent 连不上本地服务端口监听地址不对或服务未启动检查localhost与127.0.0.1差异确认服务进程存活浏览器无法通过调试端口访问启动参数没带--remote-debugging-port重建一个带调试参数的浏览器窗口登录态失效用户数据目录不一致固定同一个--user-data-dir不要混用MCP 工具列表为空MCP server 配置错误手动运行命令看终端报错页面点击无响应页面有弹窗或 iframe让 Agent 先检查 iframe 或遮罩层切换到正确 frame 再操作操作速度很慢返回 DOM 太完整提示 Agent 只提取必要字段必要时关闭截图5. 我的使用体会与扩展思路这东西看起来简单但用顺手之后场景会被迅速放大。我现在的编码工作流里已经不限于让 Agent 帮我查询资料它会直接打开本地管理后台完成重复录入会在测试环境来回跳转验证数据甚至能在我本地起一个临时页面做 UI 冒烟测试。BrowserSkill 等于把浏览器变成 Agent 的“双手”而负责登录的是用户自己这个边界我特别认同。如果你也想在团队里推广这种模式我建议先从一个风险极低的场景开始比如信息收集、页面巡检。等 Agent 的行为足够可控可靠再逐步放开更多权限。另外桥接层本身也可以继续拓展比如加一个角色权限系统让不同 Agent 只能访问指定站点这样使用起来会更安心。我自己后续想做的事是把 BrowserSkill 的调用结果回传给一个内部日志系统这样 Agent 每次操作都能被追溯。很多企业不敢让 AI Agent 动真实浏览器担心的不是成功率而是不可控。把操作记录留下来至少能多一重安全感。最后再分享一个小技巧如果 Agent 在某个页面反复执行失败别急着换工具先手动在同一个浏览器里操作一遍把页面可能出现的弹窗、加载延迟、异常分支都记下来然后把这些观察到的情况直接补充到你的任务描述里。AI Agent 对上下文的理解远比你想的强你多给的这几行说明可能就让任务从翻车变成稳定可用。
阅读完成 · 觉得有帮助？
