1. 项目概述BrowserSkill 到底是什么为什么值得关注这几年做 AI Agent 相关开发的人应该都有同感模型推理能力越来越强但真正把 Agent 从“聊天机器人”变成“能干事的助手”最大的拦路虎始终是环境接入。你可以让大模型写代码、做规划、调API但一旦涉及操作真实浏览器里的业务系统、后台管理页面、在线表单大多数 Agent 就抓瞎了——不是模型不行是“手”伸不过去。Tencent BrowserSkill 这个项目解决的正是这个问题。从名字拆开看Browser 是浏览器Skill 是技能合在一起就是“让 AI Agent 拥有操作浏览器这项技能”。它的核心目标是让 Agent 能够复用真实浏览器中已有的登录态、Cookie、会话数据在用户当前正在使用的浏览器环境里直接完成自动化操作而不是另起炉灶开一个无头浏览器从头走一遍登录流程。为什么要强调“真实浏览器会话”这里我多说几句。早期做浏览器自动化大家习惯用 Selenium、Puppeteer、Playwright 这类工具跑一个独立的浏览器实例Cookie、登录态全靠脚本自己维护。这在测试场景没问题但放到 AI Agent 落地场景就有几个痛点一是登录态迁移麻烦很多系统有验证码、二次认证脚本很难自动通过二是用户已经打开的页面、填了一半的表单、选好的条件Agent 根本看不见三是企业内网系统往往只认浏览器环境里的身份凭证你另开一个全新实例等于让 Agent 从头“认人”。BrowserSkill 走的是“接入现有浏览器会话”的路线理论上这些痛点都能绕过去。这个项目适合什么样的人如果你是做 AI Agent 应用开发、浏览器自动化脚本、RPA 工具链的工程师或者说你正在调研“怎么让 Agent 真正操作业务系统”那这项目值得你花时间仔细看。如果你只是写脚本做爬虫测试的方向不同参考价值有限但里面的会话复用思路也有启发。2. 设计思路拆解为什么“复用会话”比“重建会话”更适合 Agent2.1 从 Agent 工具设计的角度理解 BrowserSkillAgent 的架构说白了就是一个大模型当“脑子”一堆工具当“手脚”。工具设计得好不好直接决定 Agent 成不成熟。浏览器工具在 Agent 生态里特别难做因为它涉及三层问题环境层浏览器实例从哪来、交互层怎么把页面操作抽象成工具调用、感知层Agent 怎么“看懂”页面当前状态。BrowserSkill 的第一层设计思路是把“环境层”从“让 Agent 自己开浏览”改成“复用已有会话”。这看起来只是环境来源不同实际上是两种产品哲学。自己开浏览器的方案适合批处理、无人值守的场景复用会话的方案适合“人机协作”的场景——用户坐在电脑前Agent 在旁边辅助操作甚至用户看着 Agent 一步步点下去。这类场景在客服系统、运营后台、企业 ERP 操作里非常常见。第二层设计思路我认为是“技能化”。它不是一个通用的“点这里点那里”的 API而是把高频操作封装成一个个 Skill比如表单填写技能、表格数据提取技能、点击跳转技能、登录态校验技能。这种封装的好处是Agent 不需要每次都从零理解“怎么填这个复杂表单”只要调用对应 Skill 并传参数就行。等于你把“操作基本功”练好模型只需要负责“判断该用哪个基本功”。2.2 与 Playwright MCP、Agent Browser 的差异点在哪里最近 AI Agent 圈子里聊得比较多的方案有几个Playwright MCP、Agent Browser以及 BrowserSkill。很多人会问它们有什么区别我简单用个类比Playwright MCP 相当于“给了 Agent 一套遥控器”Agent 可以按按钮、看反馈Agent Browser 相当于“给 Agent 配了一个专用浏览器”Agent 在里面开工干活而 BrowserSkill 相当于“让 Agent 坐到你旁边和你共用同一个浏览器画面和操作权”。具体差异可以列个表来看对比项Playwright MCPAgent BrowserBrowserSkill浏览器来源脚本自动拉起实例独立专用实例复用用户现有浏览器会话登录态迁移需要手动处理需要额外配置天然继承适用场景测试、批处理无人值守任务人机协作、业务系统操作对用户界面感知通过快照/截图通过视图树/截图结合真实页面结构实现侧重点协议转化环境隔离技能封装与会话复用这个差异不是谁好谁坏的差异而是定位不同。BrowserSkill 更适合做“超级助理”类产品——用户需要 Agent 帮忙操作他正在用的系统而不是让 Agent 自己在后台偷偷干。我从实际开发角度说一句真要做企业级 Agent 应用会话复用和多端一致这两个点比单纯的技术能力重要得多因为企业系统里最贵的就是“身份”和“权限”这两样东西。2.3 浏览器会话复用的技术可行性分析这里得简单展开讲讲浏览器会话到底怎么复用。常规思路是通过浏览器扩展注入一段 Bridge 脚本利用 Chrome DevTools ProtocolCDP和 WebSocket 与外部进程通信。具体流程是浏览器中安装一个扩展建立与 Agent 服务端的 WebSocket 连接。扩展读取当前标签页的 DOM 结构、URL、Cookie 摘要等信息发送给 Agent 服务端。Agent 根据大模型决策生成操作指令扩展在浏览器上下文中执行这些指令。执行结果和页面变更反馈给 Agent形成闭环。BrowserSkill 在这个基础上还强调了“数据足迹”这个概念。打个比方你在页面上填了一半表单Agent 接过来继续填它得知道哪些字段你已经填过了、哪些值是你填的不能乱改。这就要追踪用户在页面上的操作历史形成一种“足迹感知”。普通自动化工具不会管这些但 Agent 场景必须管否则很容易把用户填的覆盖了。3. 核心能力与关键技术点解析3.1 实时会话接入不是“开浏览器”而是“接浏览器”这是 BrowserSkill 最核心的能力也是最容易被误解的地方。很多教程在讲浏览器自动化时第一步一定是launch()启动浏览器实例但在 BrowserSkill 里启动是最后一步甚至是可选的。重点是怎么把 Agent“接”进一个已经存在的浏览器会话。我理解它的实现思路是这样的浏览器上下文Browser Context本质上是独立的包含 Cookie、LocalStorage、IndexedDB 等会话数据。如果 Agent 能拿到当前活动会话的 Context就等同于继承了用户的所有身份。配合扩展注入的方式Agent 拿到的不仅是 Context还包括了页面的实时状态、用户的操作痕迹这比单纯继承 Cookie 要丰富得多。这个能力在实际业务里非常有用。举个真实例子某运营同学正在后台配置一个复杂的活动页配置到一半去开会了回来想让 Agent 接着把剩余字段填完。如果 Agent 能“看到”当前页面、知道已经填了哪些内容就能无缝接手。如果按传统方式让 Agent 自己开浏览器它连登录都过不去更别提接着填了。3.2 技能封装模型大模型负责决策Skill 负责执行我之前写过一篇文章讲过工具调用的设计核心观点是工具越“原子化”模型越容易用错。BrowserSkill 把技能做成了“半成品”状态比如“表单填写”技能会自带字段识别、联动逻辑、必填校验的能力模型只需要告诉它“填这个表单数据是这些”就行。这种封装对 Agent 的性能提升是很明显的。首先减少了模型需要“思考”的步数——填表单涉及的字段映射、选择器定位、状态刷新这些事模型不需要每一步都做决策Skill 内部消化掉了。其次错误率降低了——技能封装好后里面沉淀的是工程上最稳的路径而不是模型临时“猜”出来的路径。从开发角度技能层其实是可扩展的。你可以写自己的 Skill 插件注册到技能库里。这有点像 RPA 里的“组件库”概念但比 RPA 组件更高级的地方在于Skill 的输出是“结构化状态变更”Agent 可以据此做下一步判断而不是简单地“执行完了”。3.3 页面感知与状态同步Agent 的“眼睛”是怎么装的Agent 操作浏览器最怕的不是不会点而是“看不见”。你给它一张截图它能看见大概布局但很难准确理解每个输入框的前后关系、当前选中态、下拉框展开状态。BrowserSkill 这类项目一般会提供两套感知方案一套是 DOM 结构序列化把页面转成结构化文本便于模型理解另一套是视觉截图配合多模态模型直接“看图操作”。实际使用时两套方案是互补的。结构化文本准确但不直观遇到复杂的可视化图表就抓瞎截图直观但存在像素误差点击偏差一个像素可能就点错按钮。好的做法是先用结构化文本定位目标区域再对目标区域做局部截图交给多模态模型做精细判断。这种“全局文本局部视觉”的策略我实测下来比单独用一种方式成功率高出不少。状态同步还涉及一个“快照频率”问题。Agent 操作完一步页面可能发生异步刷新如果 Agent 还在用旧快照做判断很容易翻车。BrowserSkill 的做法我认为值得借鉴每次操作后强制刷新页面状态感知并且标记状态变化区域模型只需要关注变化区域做二次确认。3.4 与 Tencent 生态及其他工具链的关系这个项目带 Tencent 前缀自然让人期待它在腾讯生态里的定位。从公开资料看BrowserSkill 作为一个浏览器会话接入技术理论上能融入腾讯云的 AI 应用平台、企业微信机器人、腾讯轻联等场景也可以作为普通开源工具用于任何 Agent 项目。不过我得提醒一句工具和人一样背景只是参考关键还是看能力。BrowserSkill 最值得学习的是它把“会话复用技能封装状态感知”三个点揉在一起的设计思路。你在自己的项目里不一定非要引入它但完全可以借鉴这三层架构去设计自己的浏览器 Agent 工具。4. 实操环节从 0 到 1 搭建一个接入 BrowserSkill 的 Agent4.1 环境准备与依赖安装这一节开始我假定你已经具备基本的 Python 和 Node.js 开发能力。BrowserSkill 相关的依赖安装并不复杂但有几个坑需要注意。首先是环境版本建议使用 Python 3.10 和 Node.js 18太老的版本会遇到一些依赖编译问题。项目依赖方面它本身是一个服务端项目需要安装的主要是 WebSocket 通信库和浏览器控制库。我建议先创建一个干净的虚拟环境避免和系统全局依赖冲突# 创建虚拟环境 python -m venv skill_env source skill_env/bin/activate # 安装核心依赖 pip install websocket-client pip install playwright pip install openai # 如果涉及到技能扩展开发建议再安装 pip install pydantic pip install pyyaml如果你本机还没有安装 Playwright 的浏览器内核需要先执行python -m playwright install chromium这个步骤在国内网络环境下可能会比较慢如果下载超时可以考虑使用镜像源或者耐心多试几次。安装完成后可以写个简单脚本验证一下 Playwright 能否正常启动浏览器from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()这里多说一句虽然 BrowserSkill 的核心能力是复用已有会话但开发调试阶段你还是需要 Playwright 来跑一些模拟环境。另外你在做最终集成时建议把服务端部署在一台配置不低于 4 核 8G 的机器上因为 Agent 的推理和大模型 API 调用都是 CPU/网络密集型操作配置太低容易超时。4.2 配置真实浏览器扩展与 WebSocket 桥接这是整个流程中最容易出问题的环节我拆开细讲。BrowserSkill 与浏览器通信的核心是通过一个扩展插件建立桥接原理是扩展在浏览器内部创建一个 WebSocket 客户端连接到你本地或远程的 Agent 服务端。服务端发指令扩展执行执行结果再通过同一个 WebSocket 回传。你要做的事情大致如下加载扩展打开 Chrome 的扩展管理页面开启“开发者模式”选择“加载已解压的扩展程序”指向 BrowserSkill 提供的扩展目录。确认扩展 ID加载后扩展会有一个固定的 ID你需要把它填到服务端配置里作为身份校验。启动桥接服务在 Agent 服务端配置好 WebSocket 监听地址启动服务。注意扩展连接的是ws://还是wss://本地调试一般用前者远程部署必须用后者否则浏览器安全策略会拦截。验证连接扩展的 popup 页面里会显示连接状态如果显示已连接说明扩展到服务端的通道已经打通。这一步最常见的坑是“把 WebSocket 监听地址写成了 HTTP 地址”。WebSocket 的握手协议和 HTTP 不是一回事服务端用了websocket-server库监听的是 HTTP 端口但只有通过ws://协议发起握手才能升级为 WebSocket 通信。调试时如果发现连接失败第一步就是确认协议前缀是不是ws://第二步确认端口没有被防火墙拦截。我在实际调试中还遇到过一个问题Chrome 对扩展里的 WebSocket 连接有混合内容限制。简单说如果你的页面在 HTTPS 环境下扩展尝试连接ws://明文 WebSocket 会被浏览器拦掉必须升级为wss://并配置好证书才行。这个在本地开发环境不明显一上公网就暴露了。4.3 Agent 工具箱注册把 BrowserSkill 封装成函数调用前面做的所有铺垫最终都要体现为 Agent 能调用的“工具函数”。现在主流 Agent 框架都支持函数调用比如 OpenAI 的 Function Calling、Spring AI 的 Tool Call、以及各种开源 Agent 框架的 Tool 注册机制。BrowserSkill 要接入进去标准做法是写一个适配层。我给你一个代码示例示意如何把“在页面输入文字”封装成一个函数工具from openai import OpenAI import json client OpenAI() def browser_input_text(params): 在浏览器页面指定元素中输入文字 selector params[selector] text params[text] # 这里调用 BrowserSkill 的 WebSocket 接口 result call_browser_skill(input_text, { selector: selector, text: text }) return result tools [ { type: function, function: { name: browser_input_text, description: 在页面的输入框中填入文本支持 CSS 选择器或 XPath 定位, parameters: { type: object, properties: { selector: {type: string, description: 元素选择器}, text: {type: string, description: 要输入的文本内容} }, required: [selector, text] } } } ] # 调用模型并解析工具调用 response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 帮我在搜索框里输入 AI Agent 然后点击搜索按钮}], toolstools, tool_choiceauto ) tool_call response.choices[0].message.tool_calls[0] print(f模型决定调用: {tool_call.function.name}) print(f参数: {tool_call.function.arguments})这里的关键不是代码本身而是你注册的“函数描述”写得好不好。我在实际开发中发现模型能不能正确调用工具“描述”比“参数列表”重要得多。比如你写“在搜索框输入文字”模型有时候会拿不准该不该用但你写“当用户提到搜索、查询、搜索框时使用此工具在页面输入关键字”模型就很容易命中。另外别忘了浏览器操作的函数工具里尽量让参数名贴近常识。.selector对模型太抽象建议直接用.element位置描述或者.操作目标模型更容易生成正确的参数值。4.4 完整工作流从用户指令到浏览器操作的全链路示例我们用一个实际场景把整个链路串起来用户正在打开一个后台数据管理页面想让 Agent 帮忙筛选出最近 30 天订单金额超过 5000 元的记录并导出成 Excel。第一步用户在当前浏览器页面上启动 Agent通常是点击一个悬浮按钮或者通过浏览器扩展唤起 Agent 面板。Agent 服务端通过 BrowserSkill 拿到当前页面的结构化快照包括表格的表头、筛选控件、导出按钮的位置信息。第二步用户输入指令。Agent 将指令和页面快照一起送入大模型模型决定调用哪些工具。这个场景大概率需要三个工具set_filter设置筛选条件、read_table_data读取表格数据、click_export点击导出按钮。第三步执行阶段。Agent 依次调用工具每个工具执行前BrowserSkill 都先做一次“页面状态确认”确认目标元素还存在于页面上这能避免因为页面刷新导致的操作失效。执行完一步后页面状态快照会更新反馈给模型做下一步决策。第四步结果校验。导出按钮点击后浏览器可能触发下载也可能弹出一个提示窗口。Agent 需要根据页面变化判断导出是否成功。如果弹出“导出数量超过限制”的提示Agent 应该识别这个异常并向用户反馈可能需要用户手动调整筛选条件。这套流程走下来你会发现 Agent 操作的每一步都有“状态感知”和“结果校验”兜底不会出现“模型说做了其实没做”的情况。这可能就是 BrowserSkill 这类项目对 Agent 最实在的价值。5. 实践中的常见坑与排查思路我替你踩过的那些雷5.1 会话复用失败权限、账号、多标签页的经典组合难题会话复用听着美好实际跑起来最常见的失败原因有三个第一扩展没有获得当前标签页的读取权限。Chrome 扩展访问页面内容是需要权限声明的如果扩展的host_permissions没有覆盖当前网站的域名连接是正常的但拿不到 DOM 数据Agent 成了“睁眼瞎”。第二浏览器开了多个 Profile用户档案。Chrome 的多个 Profile 之间缓存是隔离的你的扩展安装在 A Profile 里Agent 读到的是 A Profile 的会话数据但用户实际登录的是 B Profile 的浏览器窗口。这种问题很隐蔽因为界面看起来“是同一个浏览器”实际上数据完全隔离。第三页面本身是 SPA单页应用。SPA 的路由切换不刷新文档DOM 是动态渲染的。如果 Agent 拿到的是旧快照然后你用旧快照的选择器去操作新页面的元素有时候能命中因为 SPA 复用 DOM 节点有时候直接报错。排查思路是每次操作前强制重新获取快照别拿缓存凑合。从工程角度我建议在 Agent 服务端做一个“页面指纹”功能每次快照生成时附带一个 hash 值如果操作前发现当前页面的 hash 和快照不一致就废弃旧快照重新生成。这样能规避大半的页面状态过期问题。5.2 页面元素定位失败选择器过期与动态加载在传统自动化测试里元素定位失败是家常便饭在 Agent 场景里更是如此因为 Agent 操作比脚本更“随意”页面状态变化更快。常见原因包括元素是异步加载的快照生成时还没渲染完成。元素存在 iframe 嵌套直接按外层文档定位根本找不到。元素是虚拟滚动渲染的因为滚动位置不同DOM 中只存在可见区域的部分。页面上有多个相似元素选择器命中了错误的那个。针对这些问题我的做法是给 Agent 工具增加几种“兜底策略”第一个是等待策略默认等待目标元素出现的最长时限是 5 秒超过就报错重试第二个是视觉定位兜底如果结构化定位失败就截图让多模态模型重新识别并给出坐标第三个是文本定位兜底通过元素的可见文本来反查定位。这套“结构化为主、视觉为辅、文本兜底”的定位策略在不同页面上切换很稳定强烈建议你在自己的 Agent 里也实现一套类似的降级逻辑。5.3 Agent 误解页面状态快照语义化的最佳实践模型对页面快照的理解偏差也是高频问题。原始快照是个 JSON 大对象包含几百个 DOM 节点模型读一遍就要消耗大量 token而且读完之后未必能准确抓住重点。我见过不止一次模型把错误提示文字当成了页面文案导致判断失误。解决思路是“快照语义化”也就是在提取快照时就把页面分成几个语义区域导航区、主要内容区、弹窗区、提示信息区。每个区域只提取关键元素和文字丢掉无用的包裹节点。这样模型读到的不是一棵巨树而是一份“页面摘要”。同时把弹窗和错误提示单独标记出来模型读到这些标记会天然更警惕不容易误判。我做这块的时候还加了一个小技巧快照里给每个可交互元素加一个“操作建议”字段比如“此按钮可能用于提交表单”“此输入框疑似必填项”。这些信息不需要精确哪怕只是增加了一点点“猜中的可能性”模型后续决策的准确率都能高不少。5.4 常见问题速查表问题现象可能原因排查重点扩展连接正常但拿不到页面数据权限声明未覆盖当前域名检查 manifest.json 的 host_permissionsWebSocket 频繁断连没有心跳保活机制确认扩展是否实现 ping/pong 心跳Agent 点击不生效页面已异步刷新操作前重新获取快照并校验 hash表单填写错位iframe 嵌套未处理检查元素是否在 iframe 内需切换文档上下文模型反复调用同一个错误工具函数描述不清晰重写函数定义加入具体的触发场景下载文件没落盘浏览器下载路径未配置设置浏览器下载目录和自动下载策略登录态突然失效访问了跨域页面导致 Cookie 被清检查同源策略避免跨域操作操作速度太慢WebSocket 回传频繁且链路长批量合并指令减少往返交互这张表基本涵盖了我实践中最常遇到的问题。建议保存下来以后排查 Agent 浏览器操作问题时对照检查能省不少时间。6. 经验总结与扩展思考这个项目我在本地完整跑通过也在自己的 Agent 应用里尝试做了轻量集成总体感受是BrowserSkill 选了一个非常好的切入角度——以“会话复用”为核心绕开了 Agent 落地中最棘手的环境和身份问题。这种设计思路对于做企业级 AI 助理、办公自动化产品的团队来说参考价值很大。如果你准备基于它做自己的东西我建议从一个小场景开始练手先让 Agent 能在你的浏览器里完成“登录某个后台–打开某个列表页–提取几条数据–填进一个表格”这个闭环。把这个链路跑通你对“会话复用、技能封装、状态感知”这三大块的理解就到位了后续再做复杂场景会顺手很多。还有一点值得关注的趋势BrowserSkill 这类项目正在把 Agent 的“感知能力”从纯结构化数据往“多模态融合”方向推。页面截图、区域识别、用户点击热区这些视觉信息和 DOM 结构结合使用的路子在快速成熟。即便短期内存在的浏览器版本兼容性、企业浏览器安全策略限制、以及扩展审核机制等客观问题还没完全解决也不影响它作为 Agent 工具链创新范式的价值。最后分享一个我自己踩坑后的体会别把 Agent 能操作浏览器想成“无所不能的魔法”它本质上还是一个“手比较笨但脑子不错”的实习生。你给它清晰的技能封装、及时的状态反馈、合理的兜底策略它就能帮你干不少活但你指望它像人一样对页面上发生的所有异常做出灵活反应目前还很困难。所以做这类应用设计目标不是“让 Agent 完全替代人”而是“让 Agent 把人从重复操作里解放出来”。方向对了后面每一步积累都有价值。