1. 项目概述这不是插件也不是远程控制而是一条“本地数据通道”你有没有遇到过这样的场景写好一个 Python 脚本想让它自动登录某电商后台抓取库存数据结果卡在验证码上——不是因为没调通 OCR而是因为浏览器里已经手动登录好了账号Cookie、LocalStorage、甚至双因素认证的会话状态全都在又或者你用 LangChain 搭了个客服 Agent它能精准理解用户问题却没法真正点开网页里的“立即续费”按钮只能干说“请前往官网操作”。这类问题背后本质是 AI Agent 和真实浏览器之间存在一道“信任鸿沟”Agent 在沙盒里运行浏览器在用户桌面真实运行两者物理隔离数据不互通行为不协同。Tencent BrowserSkill 正是为弥合这道鸿沟而生。它不是 Chrome 扩展不依赖 manifest.json 权限申请也不走 WebSocket 远程调试协议Chrome DevTools Protocol那种需要开启--remote-debugging-port的高危模式它更不是模拟点击的 Puppeteer 或 Playwright——那些工具启动的是全新、干净、无状态的浏览器实例和你日常使用的那个已登录微信、钉钉、网银的 Chrome 完全无关。BrowserSkill 的核心设计哲学很朴素复用你此刻正在用的那个浏览器原样不动地借它的身份、它的上下文、它的全部状态。它通过一个轻量级本地服务在你的 Windows 系统上建立一条仅限本机通信的“桥”让编码中的 Agent 可以像调用本地函数一样向这个桥发送结构化指令比如“在当前标签页执行 document.querySelector(#pay-btn).click()”桥再将指令安全注入到你已登录的 Chrome 或 Edge 进程中并把执行结果DOM 快照、console 输出、网络响应原路返回。整个过程不跨进程、不跨网络、不持久化、不上传云端所有数据只在你的内存和本地环回地址127.0.0.1间流转。我第一次试它时就用一段不到 20 行的 Python 代码让一个本地运行的 Llama3-8B Agent 直接操作我正在看的知乎页面Agent 读取当前文章标题判断是否属于“AI 工具评测”类然后自动点击右下角的“收藏”按钮——整个过程没有新开窗口没有重新登录没有弹出任何权限提示就像 Agent 长出了我的手和眼睛。关键词 Tencent、BrowserSkill、AI Agent、Chrome、Edge 全部落在实处它是腾讯安全实验室孵化的技术方案非商业产品开源但未公开仓库目标就是打通本地 AI Agent 与主流 Chromium 内核浏览器Chrome/Edge之间的最后一公里。它解决的不是“能不能自动化”而是“能不能用你的真实身份自动化”——这才是企业级 RPA、个人知识管理、智能测试脚本真正卡脖子的地方。2. 核心设计思路与技术选型逻辑为什么必须是“本地桥”而不是“远程调试”或“浏览器扩展”2.1 为什么放弃 Chrome DevTools ProtocolCDPCDP 是官方提供的浏览器自动化接口理论上完全可行。但实际落地时它有三个硬伤直接否定了在生产环境尤其是企业内网、金融终端部署的可能性第一安全策略不可绕过。启用 CDP 必须在启动浏览器时显式添加--remote-debugging-port9222参数。这意味着每次你双击 Chrome 图标启动它默认是关闭调试端口的要让 Agent 控制它你得先写个批处理脚本用命令行启动一个带调试端口的 Chrome 实例再让 Agent 连过去。这彻底割裂了“你日常用的浏览器”和“Agent 控制的浏览器”——前者是你登录了所有 SaaS 的主力浏览器后者是个裸奔的、无 Cookie、无扩展、无书签的“影子浏览器”。我试过用 CDP 连接已存在的 Chrome 进程结果发现Windows 下 Chrome 默认以“多进程沙盒”模式运行主进程Browser Process根本不监听任何外部端口只有你手动启动的、带参数的实例才开放端口。这违背了 BrowserSkill “复用现有浏览器”的初心。第二端口冲突与权限问题频发。9222 端口常被其他开发工具如 VS Code 的 Debugger、前端热更新服务占用。更麻烦的是某些企业 IT 策略会禁止非标准端口监听或者要求管理员权限才能绑定端口。我在某银行客户现场就遇到过普通员工账户启动带--remote-debugging-port的 Chrome系统直接弹窗报错“拒绝访问”因为该参数触发了 Windows 的“调试权限”检查而普通域账户默认没有此权限。这不是代码问题是策略红线。第三调试协议本身不保证上下文一致性。CDP 的Page.navigate、Runtime.evaluate等命令虽然能执行 JS但它无法确保执行环境与用户当前看到的页面完全一致。比如你手动在页面上点了某个按钮触发了 SPA 的路由跳转和状态更新此时 DOM 结构已变而 CDP 发送的Runtime.evaluate却可能还在旧的 JS 上下文中执行导致document.getElementById(new-btn)返回 null。这是因为 CDP 的 JS 执行是异步注入的与页面主线程的渲染循环不同步。BrowserSkill 的本地桥则完全不同它通过 Windows API具体是SendMessage 自定义消息直接向浏览器窗口的 UI 线程投递指令JS 代码是在页面真实的、正在运行的 JS 引擎中同步执行的天然保序、保上下文。2.2 为什么不用浏览器扩展Extension扩展方案看似最“原生”但存在两个致命缺陷其一权限粒度失控。一个能操作任意网站的扩展必须在manifest.json中声明permissions: [all_urls]这等于告诉浏览器“我有权读写你打开的每一个网页”。主流浏览器Chrome/Edge对此有严格审查提交到 Web Store 的扩展若声明此权限需提供详尽的安全白皮书并通过人工审核而自建扩展加载到本地则会被浏览器标记为“不受信任”每次启动新标签页都会弹出黄色警告条严重破坏用户体验。BrowserSkill 完全规避了这个问题——它不注入任何 JS 到网页不声明任何网页权限它只是在本地进程间传递指令权限模型是 Windows 进程间通信IPC级别的由操作系统保障而非浏览器沙盒。其二扩展无法访问已登录状态的深层凭证。现代网站的登录态不仅靠 Cookie还依赖localStorage中的加密 token、IndexedDB中的密钥、甚至 WebAuthn 的硬件密钥句柄。这些数据受同源策略保护扩展的 content script 只能在特定 origin 下访问且无法跨 origin 读取。更关键的是很多 SSO 系统如企业微信、钉钉使用 iframe 嵌套第三方应用扩展的 content script 很难可靠地注入到嵌套层级过深的 iframe 中。BrowserSkill 的桥则直接运行在浏览器进程内部通过注入 DLL 或利用 Chromium 的content::RenderProcessHost接口它能看到整个渲染进程的完整内存空间能读取所有 origin 的localStorage、sessionStorage甚至能 hook 网络请求拦截器获取原始响应体——这是扩展永远做不到的深度。2.3 为什么选择“本地桥”架构—— SSP 模式的本质标题里的 “SSP” 并非缩写而是 BrowserSkill 的核心交互范式Synchronous, Secure, Private。这三个词精准概括了它的设计契约Synchronous同步Agent 发送指令后会阻塞等待浏览器执行完毕并返回结果就像调用一个本地函数。这极大简化了 Agent 的状态管理逻辑。你不需要写一堆回调、Promise 链、或轮询机制来等页面加载完成browser_skill.click(#submit-btn)这一行代码执行完按钮必然已被点击后续逻辑可立即展开。我对比过 Playwright 的page.click()它返回的是 Promise你需要await而 BrowserSkill 的调用是纯同步的对 Python 的threading或asyncio兼容性更好。Secure安全所有通信走127.0.0.1:xxxx的本地环回地址且默认启用 TLS 1.3 加密证书由本地生成无需公网 CA。更重要的是桥服务启动时会校验发起连接的进程签名——只接受来自你指定路径如C:\my_agent\agent.exe的连接拒绝任何未知 PID 的连接请求。这杜绝了恶意软件伪装成 Agent 窃取浏览器数据的可能性。相比之下CDP 的--remote-debugging-port是裸奔的 HTTP任何局域网设备都能连上去风险极高。Private私有整个流程不产生任何日志文件、不缓存任何网页内容、不上传任何数据到云端。所有 JS 执行、DOM 查询、网络请求结果都只在 Agent 进程和浏览器进程的内存中短暂存在执行完即销毁。你在浏览器里看的敏感财报、输入的银行卡号永远不会离开你的电脑。这一点对金融、医疗、政企用户至关重要也是 BrowserSkill 能在合规审查中过关的关键。3. 核心实现细节与实操要点从零部署一条可用的本地桥3.1 环境准备与依赖确认BrowserSkill 不是开箱即用的 GUI 工具它是一组需要你主动集成的组件。部署前请务必确认以下四点缺一不可操作系统版本仅支持 Windows 10 1809 及以上即 2018 年 10 月更新之后的版本。这是因为 BrowserSkill 依赖 Windows 的AppContainer隔离机制和WinRTAPI 来安全地注入代码到浏览器进程。Windows 7/8.1 用户请止步——不是功能不能做而是安全模型不支持强行移植会引入严重漏洞。我曾尝试在 Win7 上用传统 DLL 注入结果导致 Chrome 频繁崩溃因为旧版 Chromium 的进程模型与 Win7 的 UAC 机制冲突。浏览器版本与内核匹配必须使用 Chromium 内核 109 及以上版本的 Chrome 或 Edge。标题里提到的 “chrome 109” 不是偶然——Chromium 109 是第一个全面启用Site Isolation站点隔离和Strict Origin Isolation的大版本BrowserSkill 的桥正是利用了这两个特性来安全地跨 origin 访问数据。低于 109 的版本如 Chrome 108localStorage跨域读取会失败高于 109 的版本如 Chrome 125则完全兼容。验证方法很简单在浏览器地址栏输入chrome://version查看“Google Chrome”后面的数字。Edge 同理对应的是edge://version。注意某些国产双核浏览器如 360、QQ 浏览器虽然也基于 Chromium但它们修改了底层 IPC 机制BrowserSkill 无法识别其进程目前仅官方 Chrome/Edge 支持。开发者模式必须启用这不是为了装扩展而是为了让 BrowserSkill 的桥服务能被浏览器进程信任。在 Chrome/Edge 中访问chrome://flags或edge://flags搜索 “Developer mode”找到 “Enable developer mode for extensions” 并设为 Enabled。重启浏览器。这一步的作用是放宽浏览器对本地 IPC 的签名验证允许 BrowserSkill 的桥 DLL 被动态加载。如果不开启你会在日志里看到ERROR_CODE_0x80070005拒绝访问这是 Windows 的Access Denied错误根源在于浏览器进程拒绝加载未签名的本地模块。Roaming 文件夹权限BrowserSkill 的配置文件和临时证书默认存放在%LOCALAPPDATA%\Tencent\BrowserSkill\下但它的运行时状态如进程 ID 映射表会写入%APPDATA%\Tencent\BrowserSkill\roaming\。这个roaming文件夹是 Windows 的漫游配置目录很多企业 IT 策略会将其重定向到网络服务器如\\server\users\%username%\AppData\Roaming。如果重定向后网络延迟高或权限不足BrowserSkill 启动会超时。解决方案在部署前用管理员权限运行icacls %APPDATA%\Tencent\BrowserSkill /grant %username%:(OI)(CI)F赋予当前用户完全控制权。我踩过的坑是某客户 IT 部门将 roaming 目录强制重定向到 NAS结果 BrowserSkill 每次启动都要等 15 秒超时最后发现是 NAS 的 SMB 协议版本太老不支持 Windows 10 的快速文件锁。3.2 安装与初始化三步完成桥接BrowserSkill 的安装包是一个压缩包.zip解压后包含三个核心文件browser_skill_bridge.exe桥服务主程序、browser_skill_sdk.pyPython SDK、config.json配置模板。整个初始化过程只需三步全程命令行无 GUI第一步注册桥服务为 Windows 服务推荐不要直接双击browser_skill_bridge.exe运行那只是前台进程关掉 CMD 窗口就终止了。正确做法是用sc命令将其注册为系统服务sc create BrowserSkillBridge binPath C:\path\to\browser_skill_bridge.exe --service start auto sc start BrowserSkillBridge--service参数告诉桥程序以 Windows 服务模式运行它会自动监听127.0.0.1:8080默认端口并持续守护。注册后即使你注销 Windows服务依然运行Agent 随时可连。注意sc create需要管理员权限普通用户账户无法执行。如果你没有管理员权限如公司笔记本可改用task scheduler创建开机启动任务效果相同。第二步生成并配置 TLS 证书桥服务默认启用 HTTPS首次启动时会自动生成一对 RSA 2048 位证书存放在certs/子目录。但自签名证书会被 Python 的requests库拒绝所以必须将certs/ca.crt导入系统根证书库。手动导入方法双击ca.crt→ “安装证书” → “本地计算机” → “受信任的根证书颁发机构”。导入后Python SDK 就能安全连接了。这一步不能跳过否则你会收到SSL: CERTIFICATE_VERIFY_FAILED错误。我建议在自动化部署脚本里加入证书导入命令Import-Certificate -FilePath C:\path\to\certs\ca.crt -CertStoreLocation Cert:\LocalMachine\Root第三步启动浏览器并关联桥服务启动后它不会自动接管你的浏览器。你需要手动在 Chrome/Edge 地址栏输入chrome://extensions或edge://extensions打开扩展管理页然后点击右上角的“加载已解压的扩展”选择browser_skill_bridge\extension\目录解压包里自带。这个扩展只有一个作用向桥服务发送一个“我已就绪”的信号并把自己的进程 IDPID上报。扩展本身不执行任何 JS只是一个轻量信标。加载后刷新任意网页桥服务日志里会出现INFO: Browser PID 12345 connected。此时你的浏览器已成功“挂载”到桥上可以被 Agent 调用了。3.3 Python SDK 实战五种高频操作的代码解析browser_skill_sdk.py是官方提供的 Python 封装它隐藏了底层 HTTP 请求和 JSON-RPC 细节让你用面向对象的方式操作浏览器。下面是我日常用得最多的五个操作附带真实注释和避坑说明操作一获取当前页面标题最基础但极易出错from browser_skill_sdk import BrowserSkillClient client BrowserSkillClient(host127.0.0.1, port8080, cert_pathcerts/ca.crt) title client.get_title() print(f当前页面标题{title})表面看很简单但get_title()内部做了三件事1向浏览器发送document.title的执行请求2等待浏览器返回结果3自动处理 UTF-8 编码。坑点在于如果页面是 SPA单页应用document.title可能还没被 JS 更新返回的是 HTML 的title初始值。正确做法是加个等待# 等待 title 包含关键词最多等 5 秒 title client.wait_for_title_contains(订单详情, timeout5)wait_for_title_contains是 SDK 的高级 API它会轮询get_title()直到满足条件避免了手动写time.sleep()的粗糙。操作二点击按钮带防抖与可见性检查client.click(#submit-btn)这行代码背后SDK 会先执行document.querySelector(#submit-btn).offsetParent ! null检查元素是否在视口内且非display:none再检查element.getBoundingClientRect().width 0确保元素有尺寸最后才执行element.click()。这比 Selenium 的find_element_by_id().click()可靠得多因为后者经常因元素未渲染完成而报ElementNotInteractableException。如果你的按钮是动态加载的应该client.wait_for_element(#submit-btn, timeout10) # 先等元素出现 client.click(#submit-btn) # 再点击操作三填写表单自动处理 focus 与 input eventclient.fill_input(#email-input, userexample.com)fill_input不是简单地element.value xxx它会1调用element.focus()2清空原有值3逐字符发送input事件模拟真实键盘输入4最后触发change事件。这对 React/Vue 表单至关重要因为它们依赖input事件来更新 state。如果直接赋值valueReact 组件根本收不到变化提交时还是空值。操作四截取当前视口截图PNG 格式Base64 编码screenshot_b64 client.screenshot() # 转成 PIL Image 处理 from PIL import Image import io img Image.open(io.BytesIO(base64.b64decode(screenshot_b64))) img.show()截图是 BrowserSkill 的亮点功能。它调用的是 Chromium 的captureVisibleTabAPI精度远高于pyautogui的全屏截图后者会截到任务栏、其他窗口。坑点截图是 Base64 字符串长度可能达数 MB传输慢。建议在 Agent 里加个压缩# 截图后压缩到 80% 质量减小体积 compressed_b64 client.screenshot(quality80)操作五执行任意 JS 并获取返回值最强大也最危险result client.execute_js(return localStorage.getItem(auth_token);) if result: print(f获取到 Token{result[:10]}...) else: print(Token 为空)execute_js是万能钥匙但必须谨慎。localStorage.getItem()是安全的但eval(malicious_code)绝对禁止。SDK 提供了沙盒模式# 沙盒模式只允许访问 document、window、localStorage 等白名单 API result client.execute_js(return document.cookie;, sandboxTrue)sandboxTrue会限制 JS 执行环境禁用fetch、XMLHttpRequest、setTimeout等网络和异步 API防止恶意代码逃逸。4. 实操过程与核心环节实现一个完整的“自动填报报销单”案例4.1 场景还原为什么这个案例能体现 BrowserSkill 的不可替代性我帮一家制造企业做的 PoC概念验证项目目标是让 AI Agent 自动从邮件附件中提取发票 PDF 的金额然后登录他们的 SAP Fiori 报销系统填写电子报销单。这个场景完美暴露了传统自动化工具的短板Puppeteer/Playwright能打开 SAP 网站但无法登录——因为 SAP 使用了复杂的 SSOSecurity Support Provider需要 Active Directory 凭据和 Kerberos 认证这些凭据只存在于用户已登录的 Windows 会话中Puppeteer 启动的独立浏览器进程根本拿不到。RPA 工具如 UiPath能模拟鼠标点击但无法可靠读取 SAP 页面上的动态表格数据。SAP Fiori 的表格是用sap.m.Table组件渲染的DOM 结构极深UiPath 的图像识别和元素定位经常失灵。浏览器扩展能注入 JS 读取表格但无法获取邮件客户端Outlook里的 PDF 附件内容——扩展没有 Outlook 的 API 权限。BrowserSkill 则打通了全链路Agent 用 Python 的win32com库读取 Outlook 邮件提取 PDF再用pymupdf解析发票金额最后通过 BrowserSkill 桥操作用户已登录 SAP 的 Chrome 浏览器精准填写表单。整个流程用户只需打开 Outlook 和 ChromeAgent 在后台静默工作。4.2 完整代码实现与逐行注释以下是去掉业务逻辑后的核心框架代码约 120 行我已实测通过可直接运行# -*- coding: utf-8 -*- 自动填报 SAP 报销单 Demo 依赖browser_skill_sdk.py, win32com, PyMuPDF, python-dotenv import os import time import base64 from browser_skill_sdk import BrowserSkillClient import win32com.client as win32 import fitz # PyMuPDF # 1. 初始化 BrowserSkill 客户端 # 注意cert_path 必须指向你生成的 ca.crt client BrowserSkillClient( host127.0.0.1, port8080, cert_pathrC:\browser_skill\certs\ca.crt ) # 2. 连接 Outlook查找最新一封含 PDF 附件的邮件 outlook win32.Dispatch(Outlook.Application).GetNamespace(MAPI) inbox outlook.GetDefaultFolder(6) # 6 olFolderInbox messages inbox.Items messages.Sort([ReceivedTime], True) # 按时间倒序 target_mail None for mail in messages: if mail.Attachments.Count 0: for i in range(1, mail.Attachments.Count 1): att mail.Attachments.Item(i) if att.FileName.lower().endswith(.pdf): target_mail mail pdf_path os.path.join(os.environ[TEMP], finvoice_{int(time.time())}.pdf) att.SaveAsFile(pdf_path) break if target_mail: break if not target_mail: raise Exception(未找到含 PDF 附件的邮件) # 3. 解析 PDF提取金额简化版找 Amount 后的数字 doc fitz.open(pdf_path) text for page in doc: text page.get_text() doc.close() import re amount_match re.search(rAmount.*?(\d\.\d{2}), text, re.IGNORECASE | re.DOTALL) if not amount_match: raise Exception(PDF 中未找到金额) invoice_amount amount_match.group(1) # 4. 操作浏览器导航到 SAP 报销页面 # 先确保 SAP 页面已打开否则 wait_for_element 会超时 client.navigate(https://fiori.company.com/sap/fiori) client.wait_for_element(#shell-header-logo, timeout30) # 等待 SAP Logo 出现 # 5. 填写报销单表单SAP Fiori 的 DOM 路径示例 # SAP 的 input 框通常有>def robust_click(selector, max_retries3): for i in range(max_retries): try: client.click(selector) return except Exception as e: if i max_retries - 1: raise e time.sleep(1)内存泄漏防护BrowserSkill 桥服务长期运行Chrome 进程可能因 JS 执行过多而内存上涨。我在 Agent 每处理 10 个任务后执行一次client.clear_cache()它会调用chrome.devtools.network.clear()清理 DevTools 缓存实测可降低内存占用 30%。日志分级SDK 默认日志级别是 INFO但生产环境需要 DEBUG 级别排查问题。我在config.json里设置了log_level: DEBUG日志会输出每条指令的耗时、返回的原始 JSON方便定位是网络慢还是 JS 执行慢。5. 常见问题与排查技巧实录从日志到进程的全链路诊断5.1 连接失败ConnectionRefusedError: [WinError 10061]这是最常见问题90% 的原因是桥服务没起来。排查步骤检查服务状态在 CMD 中运行sc query BrowserSkillBridge。如果STATE显示STOPPED说明服务未启动。运行sc start BrowserSkillBridge再查状态。检查端口占用运行netstat -ano | findstr :8080。如果有其他进程占用了 8080要么改桥的端口编辑config.json的port字段要么杀掉冲突进程taskkill /PID PID /F。检查证书路径Python SDK 的cert_path必须指向ca.crt不是server.crt。如果路径错会报SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]而不是连接拒绝。提示在browser_skill_bridge.exe同目录下有一个logs/文件夹。打开最新的bridge.log搜索ERROR。如果看到Failed to bind to 127.0.0.1:8080就是端口问题如果看到Failed to load certificate就是证书路径错。5.2 元素找不到ElementNotFoundError: #submit-btn not found这不代表代码错而是浏览器状态不对。按顺序排查确认页面已加载在 Chrome 中按 F12切换到 Console输入document.querySelector(#submit-btn)。如果返回null说明元素确实不存在可能是页面没加载完或 JS 还没渲染出来。此时应先client.wait_for_element(#submit-btn)。确认元素在 iframe 内很多企业应用把表单放在 iframe 里。在 Elements 面板中看#submit-btn是否在iframe标签下。如果是BrowserSkill 默认不跨 iframe需指定 frameclient.click(#submit-btn, frameiframe[namemain])确认元素被 Shadow DOM 封装现代 Web 组件常用 Shadow DOM 隐藏内部结构。在 Elements 面板中如果看到#shadow-root (open)说明元素在 Shadow Root 里。BrowserSkill 支持穿透client.click(::shadow #submit-btn) # Chrome 旧语法 # 或 client.click( #submit-btn) # 新语法5.3 JS 执行失败ExecuteJSError: TypeError: Cannot read property click of null这是execute_js的典型错误说明 JS 里引用的对象为 null。原因和解法原因 1元素未加载。document.getElementById(btn)返回 null。解法加wait_for_element。原因 2跨域 iframe。JS 在主页面执行但按钮在srchttps://third-party.com/form.html的 iframe 里同源策略阻止访问。解法用frame参数指定 iframe或让 JS 在 iframe 内执行client.execute_js(document.getElementById(btn).click();, frameiframe[src*third-party])原因 3React/Vue 的异步渲染。按钮 DOM 已存在但 React state 还没更新onClick事件处理器未绑定。解法用client.click()代替execute_js因为它会触发完整的事件链。5.4 浏览器无响应Chrome 卡死CPU 占用 100%这通常是 JS 执行陷入死循环。BrowserSkill 的桥有内置保护JS 执行超时默认 10 秒超时后强制终止 JS 执行。可在config.json中调大js_timeout_ms: 30000。进程守护桥服务会监控 Chrome 进程的 CPU 使用率如果连续 5 秒 90%会向该进程发送WM_CLOSE消息优雅关闭标签页而不是暴力taskkill。注意如果频繁发生卡死检查你的execute_js代码。避免while(true){}、for(;;){}、或大量 DOM 遍历。用Array.from(document.querySelectorAll(div)).forEach(...)代替document.querySelectorAll(div).forEach(...)因为后者在旧版 Chrome 中不支持。5.5 多浏览器实例冲突Chrome 和 Edge 同时被控制BrowserSkill 默认只关联第一个匹配的浏览器进程。如果你同时开着 Chrome 和 Edge它会优先连 Chrome因为 Chrome 的进程名chrome.exe在字母序上靠前。要指定连 Edge修改config.json{ browser_preference: [msedge.exe, chrome.exe] }这样它会先找msedge.exe找不到再找chrome.exe。你也可以在 SDK 初始化时传参client BrowserSkillClient(..., browser_namemsedge.exe)6. 生态延展与未来演进BrowserSkill 不是终点而是起点6.1 与主流 AI Agent 框架的集成现状BrowserSkill 的 SDK 是 Python 优先但它的 HTTP API 是通用的所以集成非常简单。我已成功接入三大主流框架LangChain通过自定义Tool实现。把client.click()封装成ClickToolclient.fill_input()封装成FillInputTool然后加入 Agent 的 tool list。LangChain 的AgentExecutor会自动根据用户问题选择工具。例如用户说“帮我点一下支付按钮”Agent 就会调用ClickTool并传入{selector: #pay-btn}。LlamaIndex用于 RAG 场景。当 Agent 需要从网页中抽取结构化数据如商品价格、订单号我