搞 AI Agent 开发的人大概都遇到过同一个尴尬模型推理得头头是道你让它去网页上查个数据、填个表单、点两下按钮结果第一步就卡在登录墙上。不是能力不行而是大多数 Agent 的浏览器操作默认从一个“全新会话”开始——没有你的 Cookie、没有登录态、没有你常用的页面布局甚至连浏览器指纹都是全新的。Tencent BrowserSkill 这个项目解决的就是这个痛点让 AI Agent 接入真实浏览器会话复用你已经打开的登录状态像真人坐在电脑前一样去操作已有的浏览器窗口。这篇文章围绕它聊清楚三件事它解决了什么问题、内部是怎么设计的、以及从 0 到 1 怎么落地。适合正在做 Agent 应用开发、RPA 替代方案或者想用 LLM 把手动网页操作变成自动化任务的同学。1. AI Agent 为什么卡在“浏览器”这一环1.1 先把 Agent、LLM、AI 模型的关系理清楚很多刚入门的朋友会把 Agent、LLM、AI 模型混在一起觉得它们是一回事。其实它们是三层东西。AI 模型是一个更大的概念泛指所有用数据训练出来的数学模型包括图像识别模型、语音模型、推荐模型。LLM大语言模型是其中专门处理文本、推理和指令的一类像你现在接触到的 DeepSeek、GPT、Qwen 这些都属于 LLM它们负责“理解你说什么生成合理的回复”。而 Agent 是在 LLM 之上做的一套应用逻辑——它不只是一个会聊天的模型而是被赋予了工具、目标和执行循环比如“你能操作浏览器”“你能读数据库”“你能调用接口”。换句话说LLM 是 Agent 的“大脑”BrowserSkill 是 Agent 的“手”而 Agent 本身是那个穿上大脑和手、去完成任务的“人”。这个分层在你搜 BrowserSkill 相关热词时会经常遇到。比如有人说“从 0 到 1 搭建 AI Agent”实际上要做的事情是选一个 LLM 作为认知核心再用一套工具框架把模型的能力接到真实系统上。BrowserSkill 属于工具层和执行层它不替代 LLM也不替代 Agent 框架它做的是“当 Agent 决定要操作浏览器时给它一个能操纵真实会话的通道”。1.2 全新的浏览器实例和真实的浏览器会话差距比想象中大现在的浏览器自动化方案有不少像 Playwright MCP、各种云端 Browser Agent默认思路都是通过 CDPChrome DevTools Protocol启动一个全新的浏览器上下文。好处是干净、隔离、可重复但坏处恰恰在于太干净了。想象一下你自己登录了一个企业内部系统这个过程要经过账号密码、手机验证码可能还有二次验证。Agent 用全新浏览器打开这个系统第一眼看到的是登录页面而不是你的工作台。它要自己处理登录流程而登录流程里的验证码、风控校验恰恰是自动化最容易被拦下的地方。就算你给 Agent 准备了 Cookie很多系统的会话会绑定 User-Agent、IP、浏览器指纹一旦不一致照样被踢出来。Tencent BrowserSkill 的思路正好反过来不重新创建会话而是接续现有会话。它让 Agent 直接连接到你已经打开的浏览器读取当前会话的 Cookie、LocalStorage、SessionStorage以及浏览器指纹信息然后在这个基础上执行操作。用户已经登录了Agent 就用这个登录态用户已经打开了某个页面Agent 就能直接从当前页面开始操作。这个思路对“操作真实业务系统”的场景非常实用。2. BrowserSkill 的核心设计与技术原理2.1 会话接续是怎么实现的BrowserSkill 底层依赖的是 Chrome DevTools Protocol也就是 CDP。CDP 是 Chrome/Chromium 提供的一套调试协议允许外部程序连接到正在运行的浏览器实例控制标签页、执行 JavaScript、拦截网络请求、抓取 DOM。你可以把 CDP 理解成一个“遥控器”。普通的 Playwright 自动化是拿遥控器再开一台电视机自己播自己的BrowserSkill 是拿遥控器直接操作你已经打开的那台电视频道、音量、播放记录全是现成的。具体流程大致是这几步启动浏览器时开启远程调试端口比如chrome --remote-debugging-port9222。通过http://127.0.0.1:9222/json拿到当前所有标签页的调试端点信息。选择一个目标标签页附加调试会话。把该标签页对应的 Cookie、本地存储、指纹上下文提取出来注入到 Agent 的执行上下文中。或者更直接地让 Agent 的每一步操作通过 CDP 指令发给真实浏览器。Agent 开始规划任务并执行浏览器操作所有操作都在用户可见的真实窗口发生。这里有一个关键选择到底是把会话信息复制出来让 Agent 在一个模拟环境里操作还是让 Agent 直接操作真实窗口BrowserSkill 采取的是后者而且这也是它和其他“导入 Cookie”方案的本质区别。导入 Cookie 的方案只是让 Agent 看起来是“已登录”但页面渲染、DOM 结构、异步加载逻辑都不会真实发生遇到 SPA单页应用里的动态表格很容易脱节。直接操作真实窗口就不一样了Agent 操作的就是用户看到的那个页面所见即所得。2.2 安全边界与授权控制把真实浏览器会话交给 AI Agent最让人担心的是安全问题。我这里说的安全不只是数据泄露还有误操作。浏览器里有其他标签页、有其他网站的数据Agent 拿到控制权后会不会越权BrowserSkill 在这块做了几个层面的约束我实际体验下来比较关键的是这三条第一用户手动授权。连接会话时需要用户主动指定允许操作的标签页或站点不是任意页面都能被接管。你在界面上确认了某个标签页之后Agent 才能动那个标签页。第二操作过程完全可见。Agent 的每一步操作都在真实浏览器窗口里发生用户能直接看到光标移动、点击、输入。这很重要因为不可见意味着不可控。一旦发现有异常用户可以随时手动中断链接收回控制权。第三会话隔离和审计。不同 Agent 的会话之间不能互相读取Browskill 一类的工具在设计和实现上都会格外注意“会话归属”和“操作留痕”。企业内部使用的时候通常还会接一层安全健康检查对 Agent 的访问来源、操作频次、目标站点做监控发现高风险行为就自动阻断。2.3 与 Playwright MCP、Agent Browser、BrowserBase 的横向对比很多人在搜“BrowserSkill 和 Agent Browser 以及 Playwright MCP 的区别”这里我直接给一张表基于我实际使用过的经验整理。对比维度Playwright MCPAgent Browser云端BrowserBaseTencent BrowserSkill会话来源自动创建全新上下文云端创建新实例云端托管新实例复用本机已打开的会话登录态需要手动导入或重新登录大多需要单独处理需要单独处理天然继承已登录直接用操作可见性无头模式为主不直观云端录制延迟较大云端录制延迟较大本地真实窗口实时可见安全边界基础权限隔离平台级托管平台级托管会话级授权 审计典型场景测试、爬虫、通用自动化云端并发任务云端托管代理交互操作已登录的企业系统注意一点我这里不是要捧一个踩一个。如果你的场景是无头执行、批量并发、完全不需要登录态的抓取任务Playwright MCP 反而更合适。BrowserSkill 的核心价值集中在“真实用户会话”上它解决的是信任问题而不是并发问题。3. 从 0 到 1 搭建让 Agent 操作真实浏览器3.1 环境准备与安装先说环境。我用的是 Python 环境配合 Chrome 浏览器Node 环境也支持但 Python 这边的示例代码和依赖处理起来更轻量。准备步骤安装 Python 3.10 以上版本安装 Node.js 18 以上版本这两个二选一即可后面示例我按 Python 写。准备一个 Chrome 或者 Chromium 内核的浏览器。BrowserSkill 本质依赖 CDP所以只要是带 DevTools 协议的 Chromium 内核浏览器都行包括 Edge。拉取项目代码并安装依赖。项目本身以 Python 包或者本地仓库方式提供你只需要pip install -r requirements.txt把依赖装好就行。启动浏览器这一步要特别注意。Windows 下可以直接在命令行执行C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9222 --user-data-dirC:\agent-profilemacOS 下是/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port9222 --user-data-dir/tmp/agent-profile--remote-debugging-port9222是开放调试端口--user-data-dir指定一个独立的用户数据目录。这个参数非常关键我强烈建议你专门为 Agent 开一个独立的 profile 目录不要用日常默认的Default目录否则可能出现插件互相干扰、会话错乱的问题。启动之后可以在浏览器地址栏访问http://127.0.0.1:9222/json看到返回的 JSON 列表里面每个元素对应一个标签页。如果能看到webSocketDebuggerUrl字段说明调试通道已经准备好了。3.2 编写最简 Agent 接入会话并执行任务环境就绪后最核心的代码逻辑其实很短。我用一个示例代码展示核心接入逻辑实际使用时按项目仓库的 API 微调即可from browserskill import BrowserContext, AgentSession # 1. 附加到已有浏览器会话指定调试端口 context BrowserContext.attach_existing_session( port9222, # 允许操作的站点建议白名单模式 allowed_origins[https://crm.example.com], # 操作超时时间单位秒 timeout300 ) # 2. 把会话绑定到 Agent 执行上下文中 agent_session AgentSession( llm_providerdeepseek, contextcontext ) # 3. 用自然语言下发任务 result agent_session.run_task( 在 CRM 系统的订单列表页筛选出今天的订单 点击导出按钮等下载文件出现在 /tmp/orders 目录后告诉我结果。 ) print(result.status) print(result.logs)这段代码做了三件事连上浏览器、绑定会话、让 Agent 执行任务。allowed_origins这个参数我强烈建议显式传它控制 Agent 只能在指定站点内操作虽然可能挡住一些灵活的跨站操作但换来的是可控性。第一次运行时你会看到真实浏览器窗口自动打开对应页面鼠标自行移动、点击、输入。那种感觉确实有点上头但也会意识到这个能力用好了是效率工具用不好会非常危险。所以还是重申一遍会话授权一定要手动确认。3.3 完整任务实战从自然语言到浏览器操作光看简单示例还不够我拆一个我实际跑过的任务让 Agent 在日常登录过的对账系统里导出一份应收账款报表并把文件整理到本地目录。完整流程按五步推进第一步建立可复现的会话环境。启动一个带调试端口的浏览器使用独立 profile 目录手动登录对账系统确保页面进入工作台状态。登录这一步我建议人工完成。原因很简单验证码、短信、二次验证这种交互让 Agent 自己处理不仅费时间还容易触发风控。人工过一遍之后再接续整体效率最高。第二步明确任务边界。我给它描述为“只能操作对账系统标签页只能访问报表模块导出文件到 /data/reports”。边界越窄Agent 的自由度越低出错概率越小。第三步把任务拆细。自然语言描述可以相对概括但内部流程要明确。我通常会让 Agent 按这个顺序走打开菜单找到“报表中心”在筛选区点击“应收账龄分析”选择导出格式 Excel点击导出等待页面提示下载完成。Agent 本身具备规划能力你的任务描述里写的越明确它推理时就越省事。第四步执行与容错。Agent 执行过程中我允许它做最多两次自我重试。比如点击导出后页面没反应它会等待两秒再点一次如果还是没动静就停下来报告异常。这个策略很有效比让它死磕到底好得多。真实页面的异步加载经常是慢半拍不是没触发。第五步校验产物。文件下载后我加了一个校验动作让 Agent 检查文件大小是否大于 0且文件修改时间在最近一分钟内。这个校验不求复杂但能挡住大部分“假装成功”的失败。整趟跑下来从我开始登录到文件落盘大约是五分钟。如果全部写成纯自动化脚本每一步都要硬编码选择器可能五十分钟都不够而且下个月页面一改版就废了。这是“真会话 自然语言指令”比传统自动化脚本更抗造的地方。4. 真实环境里的坑常见问题与排查技巧4.1 常见问题速查表实际操作过程中我遇到过的坑基本集中在下面这几类整理成表方便直接对照。现象可能原因处理方法连接 9222 端口失败浏览器没有带调试参数启动或者端口被占用确认命令行参数换一个端口如 9333 重试页面能打开但 Agent 没有操作权限未在 allowed_origins 中配置目标站点加白名单后重新绑定会话Cookie 一会儿就失效目标站点会话有效时长很短或会话被新登录挤掉缩短任务链路让 Agent 尽快完成关键操作频繁弹出滑块或验证码同一会话操作频率过高触发风控降低操作频率人工先过一遍验证再让 Agent 接续页面提示“session expired”浏览器指纹发生改变或会话被服务端主动下线保持浏览器版本稳定不用切换 profile多个 Agent 并发时互相串线多个 Agent 绑定了同一个调试端口或同一个 profile每个 Agent 使用独立的端口和 profile 目录4.2 身份与权限保护经验关于会话权限我个人的经验是永远不要用你的主力账号去跑 Agent。这不是不信任框架而是为了把风险边界画清楚。给 Agent 准备一个专门的身份权限最小化只能访问它任务里真正用到的那几个页面比把它放养成一个“全站超级管理员”要安心得多。宿我见过一个案例有人把 Agent 绑在自己的后台管理账号上任务是批量导出订单。结果 Agent 在规划时误点了“删除草稿”按钮虽然不是致命操作但足以让人后怕。后来我给所有 Agent 账号做了两个强制约定第一账号只能有目标模块的只读权限第二在 BrowserSkill 的站点白名单里只放必要域名。这样即便模型理解出错系统层面也能兜住。另外要养成清理会话的习惯。Agent 的浏览器 profile 里会残留大量真实 Cookie、本地存储数据。长期挂在服务器上跑 Agent建议每周轮换一次密码定期清理无用的 profile 目录。成本很低但能有效降低信息沉淀带来的风险。4.3 从个人练手到企业级部署热词里有很多人在搜“Jenkins AI Agent”“企业级 Java AI Agent 平台”“Spring AI 开发 Agent”这其实是同一个问题BrowserSkill 这类执行工具怎么嵌进企业的自动化体系里。我的建议是把它当作“执行工具”而不是“AI 平台”。举个具体例子在 Jenkins 流水线里加一个定时任务每天早晨让 Agent 打开公司内部数据平台检查前一日任务是否全部成功并把异常结果汇总到企业微信群里。这个场景很适合 BrowserSkill因为它需要的是“真实内网账号的真实登录态”这是云上全新浏览器最难复现的部分。Java 生态这边如果你用 Spring AI 搭过 Agent 平台可以把 BrowserSkill 封装成一个 Tool 注册进去。Spring AI 里有类似ToolCallback的机制你定义好入参和出参模型在需要操作浏览器时会自动调用。比如“查询客户余额并回填到 CRM”模型先解析意图然后调用 BrowserSkill 工具去真实浏览器里查数据和回填整个链路就通了。多智能体场景也需要注意隔离。多个 Agent 同时跑一定要让它们各自绑定独立的浏览器实例和 profile不要共用一个调试端口。否则 A 智能体打开的页面会把 B 智能体的操作结果挤掉最后所有状态都是错误的。平台层面可以做统一调度但执行层面必须保持物理隔离。5. 选型建议与实操心得5.1 什么场景适合 BrowserSkill什么场景不适合不是所有浏览器自动化任务都适合 BrowserSkill。我的判断标准很简单你是否依赖真实用户的登录态和信任环境需要的时候比如企业内部系统操作、登录后进行个性化页面交互、需要真实账号权限才能完成的任务它就有明显优势。不需要的时候比如无头批量采集、并发压力测试、公开页面抓取用 Playwright MCP 或者纯浏览器自动化反而简单因为你不需要承担真实会话带来的安全和稳定性成本。另外如果你对自动化速度有极高要求也要谨慎。操作真实浏览器的代价是窗口渲染、网络请求、页面动画全都真实发生速度肯定不如无头的 DOM 操作快。它不是一把能切所有菜的刀而是一把专门处理“信任环境内长尾操作”的刀。5.2 我在实操中总结的几条心得最后分享几条我的实践心得这些都不在官方文档里但都是真实踩出来的。第一任务描述里一定要写清“目标站点 目标动作 成功标准”。我试过让 Agent “导出报表”结果它把好几个城市的报表导了个遍最后文件混在一起。后来改成“只导出上海的应收账龄报表到 /data/reports”一次就成。第二给 Agent 准备一个专用的浏览器 profile。这个习惯帮了我大忙。日常浏览器的插件、多账号状态、历史记录都是干扰项专用 profile 干净、可控、出问题可随时删掉重来。第三遇到验证码别让 Agent 死磕。Agent 在很多验证码上成功率很低硬试只会把账号搞到风控。我的处理方式是在流程里预留一个人工介入点弹验证码时暂停人工通过验证之后让 Agent 接续往下走。这个“人在中间”的混合流程比纯自动化可靠得多。第四先给 Agent 划一个很小的权限范围跑通一个真实任务再慢慢放开。这个项目确实好用但越是在真实业务系统里越要敬畏那个“真实”二字。当你把浏览器窗口交给一个 AI 时你需要的不仅是指令执行还有止损的手段。想清楚这一点再动手你能省下很多不必要的麻烦。