腾讯开源了一个让 AI 直接用你已经登录好的浏览器的项目我最初看到这个描述时愣了一下随后反应过来这思路确实早就该有开源实现了。过去大半年我折腾过各种浏览器自动化方案最折磨人的永远是登录态——要么让模型去识别验证码要么手动导出 Cookie 再导入临时容器既繁琐又不稳定。这个项目等于把最大的一块绊脚石直接搬走了AI 智能体连接的不是一个全新的干净浏览器而是你日常使用的那个已经登录了各种网站的浏览器实例。Cookie、本地存储、会话、浏览器指纹全都继承AI 在里面点按钮、填表单、翻页面就像你自己坐在电脑前操作一样。这篇文章我会从设计思路、技术原理、本地实测到踩坑记录把它讲透。不管你是开发者、运营、测试还是只想让 AI 帮你处理个人数据的普通用户都能找到可以直接抄作业的部分。1. 它解决了什么让 AI 接管你「已经登录好」的浏览器1.1 一句话看懂这个项目一句话版本这是一个浏览器智能体Browser Agent你用自然语言告诉它任务它通过本地调试协议连接你正在运行的 Chrome 或 Edge在你已经登录好的浏览器里执行点击、输入、滚动、读取等操作最后把结果整理给你。它不需要你写规则脚本也不需要把登录凭据交给任何远程服务登录态全程留在你的本机浏览器里。很多人第一次听到这个概念会想这不就是 RPA机器人流程自动化吗其实差别非常大。传统 RPA 靠录制的固定步骤跑页面一改就失效而现在这类浏览器智能体靠大模型理解页面语义动态决定下一步操作页面变动了它能自己适应。更有意思的是它复用了你的真实浏览器环境这让很多原来绕不开的难题瞬间消失。1.2 它跟常见自动化工具差在哪我把几个方案的差异整理成一张表方便你直观感受。对比维度Playwright/Selenium传统 RPA云端 AI Agent腾讯这套浏览器智能体初始状态新建无状态浏览器依赖录制脚本云端虚拟浏览器复用你已登录的真实浏览器登录处理需要手动登录/传 Cookie需要维护登录态经常要求用户扫码或授权天然继承不用处理验证码/风控常见拦路虎常见拦路虎云端 IP 易触发风控基本不触发环境与你一致技术门槛要写代码要录制和调试脚本低但不可控低自然语言即可数据隐私数据在本机数据在本机页面内容要上传云端可配置脱敏本地闭环从表格可以看出前几种方案解决的是如何自动化操作浏览器而它解决的是如何让 AI 在真实可信的浏览器环境里自动化操作。这两个问题的难度不在一个量级。登录态、风控、验证码这些曾经让人想摔键盘的事情随着直接复用已登录浏览器这个思路一起消失了。1.3 什么人适合用它如果你属于下面任何一类我建议你花半小时跑通一个最小示例试试。个人用户想让 AI 帮你汇总各平台账单、查快递、管理订阅又不想把密码交给第三方。开发者想给自己的项目加一个自然语言驱动浏览器的能力或者做内部工具。运营和客服每天有大量重复的后台操作比如批量审核、数据回填、报表导出。测试人员不想维护繁琐的 UI 自动化脚本希望用自然语言描述流程就能回归。我自己的定位是本地私有助理它登录的是我的账号跑在我的电脑上读的是我有权访问的数据最后把结果整理给我。2. 为什么「登录态」是浏览器智能体的命门2.1 我过去受够了 Login 地狱先说说我之前的真实经历。用 Playwright 写过爬虫和自动化脚本的朋友应该都有印象脚本跑起来浏览器窗口打开然后卡在登录页面。你需要在脚本里硬编码账号密码或者手动登录一次再把 Cookie 序列化保存下次加载。听起来不难但实际用起来问题一堆。验证码会突然升级二次验证的推送频率不可控有时候平台检测到新设备登录直接要求短信验证整个脚本就挂了。更离谱的是风控同一个账号在新开的浏览器环境里操作平台可能判定为异常登录。因为新浏览器没有历史 Cookie、没有本地存储、指纹信息也是全新出厂的在风控系统看来这就是一个陌生人突然用一台陌生设备登录了你的账号。2.2 登录态不只是 Cookie风控为什么盯上新环境很多人以为把 Cookie 复制过去就等于登录了。实际上登录态是一整套环境信息的集合。除了 Cookie还有 localStorage、IndexedDB、Service Worker 缓存、浏览器指纹等。浏览器指纹包括但不限于User-Agent、屏幕分辨率、系统时区、语言偏好、Canvas 绘制结果、WebGL 渲染信息、已安装字体列表、硬件并发数。你把 Cookie 迁移到新浏览器指纹对不上某些风控严格的平台依然会判定为风险操作。这也是为什么导出 Cookie 再导入的方案在个人小范围用可以但稍微正式一点就脆弱不堪。而直接用你已经登录好的浏览器这个思路等于把整套环境打包继承下来Cookie 是对的指纹是对的本地存储也是对的跟你平时操作电脑的状态完全一致。风控系统看到的就是本人常用设备在常用环境里操作自然放行。2.3 对使用者的安全体验凭据不出本机顺着登录态这个话题我想多说一点安全层面的理解。早期云端 AI Agent 的做法是在云端给你开一个虚拟浏览器你扫码登录然后 AI 在里面操作。问题是你登录过的会话信息在云端是可见的页面内容也会被模型读取。对很多涉及个人隐私或公司内部系统的场景这个模型天然让人不放心。这套复用本地已登录浏览器方案的安全模型很不一样凭据始终留在你本机的浏览器进程里模型需要读取页面时拿到的是经过结构化的文本或截图而不是你当前页面的完整 Cookie。如果配置得当敏感字段还能做脱敏处理。也就是说AI 是借你的眼睛和手在干活而不是接管你的保险箱。3. AI 是如何「看见」和「操作」浏览器的3.1 看得见可访问性树 截图双通道要让大模型操作浏览器第一步是让它看见页面。这里有个很实际的问题直接把整个 DOM 塞给模型Token 消耗大得离谱而且 HTML 里大量标签、属性、样式信息根本不重要。项目在这件事上走的是双通道路线。第一个通道是可访问性树Accessibility Tree这是浏览器渲染后给屏幕阅读器用的语义化结构只保留对用户有意义的元素比如按钮、输入框、链接和它们的文字说明。对模型来说这比原始 HTML 干净得多也更容易理解。第一个通道是视觉截图把当前页面截图交给多模态模型让 AI 从视觉上理解布局、图表、图片内容。两者结合起来AI 既有结构化的骨架又有视觉化的画面。我实测下来的感受是可访问性树在处理表单、按钮、导航这些常规元素时非常可靠截图则在遇到图表、Canvas、复杂视觉布局时更有价值。两者互补才让 AI 能应对真实世界的网页而不是只能在测试网页里工作。3.2 操作得了通过调试协议控制真实浏览器看见之后就是操作。这里的关键技术叫 Chrome DevTools Protocol简称 CDP。它是浏览器提供的一套调试协议允许外部程序通过 WebSocket 与浏览器通信控制页面跳转、模拟鼠标点击、键盘输入、执行 JavaScript。我举个例子下面是一段极简的 CDP 消息作用是让页面里某个按钮执行点击import json import websocket # 仅为示意实际库以仓库文档为准 ws.send(json.dumps({ method: Runtime.evaluate, params: { expression: document.querySelector(button.submit-btn).click() } }))当然真实的浏览器智能体不会这么粗暴地手动写选择器它会让模型从可访问性树里挑选一个元素然后通过 CDP 的Input.dispatchMouseEvent模拟真实鼠标点击。CDP 默认只监听本地回环地址 127.0.0.1也就是只有本机程序能连接。新版 Chrome 对调试端口还增加了一些授权限制遇到连不上的情况先排查这一步。这个设计其实很重要它防止了远程攻击者通过公网端口直接控制你的浏览器。3.3 想清楚Agent 循环操作能力有了AI 怎么决定下一步做什么答案是经典的 Agent 循环观察、思考、行动、再观察。每一步模型拿到当前页面状态输出一个结构化的动作指令比如{ thought: 页面已经加载完成需要先点击登录按钮, action: click, target: 登录 }系统执行动作后重新采集页面状态喂给模型如此循环直到任务完成。这个循环里还有几个工程细节任务达到最大步数时自动停止防止无限循环某一步失败时允许模型重新规划高风险动作可以触发人工确认。理解了这个循环你就明白了为什么自然语言能驱动浏览器——本质上是大模型在不断做状态到动作的映射跟人在浏览器里一步步操作的心理过程很像。3.4 为什么这种项目现在开源正当时我觉得时机也很关键。多模态大模型的成熟让看截图理解页面变成现实工具调用Function Calling能力的规范化让模型能稳定输出结构化动作Agent 框架的爆发解决了循环、记忆、回退这些工程问题。而浏览器作为几乎所有在线服务的入口自然成为 AI Agent 最值得落地的场景之一。这套能力现在开源等于把底座交给大家踩坑和扩展后续社区会冒出各种垂直玩法。4. 本地实操从部署到让智能体跑你的后台4.1 环境准备清单在你动手之前先确认这几样东西一个桌面版 Chrome 或 Edge 浏览器建议是较新的稳定版。Python 3.10 或 Node.js 18取决于你更喜欢哪门语言。一个可用的模型 API只要是 OpenAI 兼容格式就行如果不想付费也可以用本地 Ollama 部署开源模型。Git用来克隆项目仓库。模型选择方面我建议第一遍先用 API 跑通流程不要一上来就上本地模型否则你会分不清是项目的问题还是模型能力的问题。等流程跑熟了再换本地模型节省成本。4.2 两条连接真实浏览器的路线这是整个部署里最关键的一步。要让 AI 用你已经登录好的浏览器有两种常见做法我建议你按自己的场景选。路线 A独立用户数据目录推荐新手。启动一个带专属用户目录的 Chrome第一次启动时手动登录你需要操作的网站之后 AI 每次都复用这个目录。好处是跟你日常浏览器完全隔离误操作不会影响你的真实会话。# macOS 示例 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome \ --user-data-dir$HOME/.my-agent-profile \ --remote-debugging-port9222Linux 上类似google-chrome --user-data-dir$HOME/.my-agent-profile --remote-debugging-port9222。Windows 则注意用 Chrome 安装目录下的 chrome.exe 路径。启动后你在弹出的浏览器窗口里登录需要的网站之后它就一直保持登录状态AI 每次都能直接用。路线 B直接连接正在运行的日常浏览器。如果你想临时让 AI 操作你此刻正在用的浏览器可以关闭当前 Chrome 后用调试参数重新启动google-chrome --remote-debugging-port9222 --user-data-dir$HOME/.config/google-chrome这么做的好处是 AI 直连你现有的所有登录态坏处是风险更高——AI 在你日常工作环境里跑误操作会直接影响真实会话。我把两条路线做了个对比帮你决策。对比项路线 A 独立用户目录路线 B 直连日常浏览器隔离性好操作独立差与工作环境共享登录复用第一次手动登录一次自动复用全部登录态风险低误操作影响小中高误操作影响真实数据适合场景长期跑固定任务临时让 AI 帮忙操作无论哪条路线都要记住一个铁律调试端口不要暴露到公网。别在启动命令里加--remote-debugging-address0.0.0.0之类的参数默认只监听本机才是安全的。4.3 把一个真实任务跑通部署好之后我建议你先跑一个纯读取的低风险任务。以 Python 为例代码结构大概是这样的import asyncio from browser_agent import Agent # 具体导入名以实际仓库为准 async def main(): agent Agent( port9222, modelyour-model-api-key, # 或使用环境变量注入 ) result await agent.run( 打开数据分析后台把昨天的订单量统计出来用表格形式展示 ) print(result.summary) asyncio.run(main())我强调几点实操中的注意项首次跑任务别选带删除、支付、发送等破坏性操作的场景。先让它做读取数据并汇总这类纯查询任务。模型 API Key 用环境变量传不要硬编码在脚本里更不要提交到 Git。如果任务是操作你的后台系统请在 AI 执行前先确认系统有时间回滚机制或者有测试环境。任务描述里尽量给边界比如只读取最近 7 天数据不要点击任何删除按钮如果遇到弹窗跳过。跑通之后你会看到 AI 在浏览器里一步步操作光标移动、点击、等待页面加载、读取数据、整理输出。那个画面其实很奇妙——就像一个隐形人在替你上班。4.4 把权限关进笼子这类工具能力越强权限管理就越重要。我建议你至少在三个层面做限制域名白名单只允许 AI 访问你指定的网站域名其他一律拦截。比如可以设置为只允许你的后台系统域名和账单平台域名。敏感动作二次确认点击删除提交转账支付这类高影响按钮前弹窗征求你的确认。只读模式很多场景你根本不需要 AI 去改数据只需要读取和汇总。开只读模式后AI 只能执行滚动、点击展开详情这类低风险操作写操作全部禁止。这些配置通常在项目的配置文件中完成不同实现的字段名略有差异但核心思路一致默认不允许按需开放。5. 实际应用场景我实测下来的几种用法5.1 个人数据处理账单、订阅、快递我自己用得最多的场景是个人账单和订阅管理。我以前每个月要打开支付平台、信用卡网站、几个订阅服务后台挨个看扣费记录再手动汇总到表格里。有了这套浏览器智能体之后我只要说一句去这几个平台查一下本月所有自动扣款整理成表格告诉我它就会打开每个网站利用我已登录的会话读取账单最后给我一份汇总。整个过程我不需要输入任何密码登录态是现成的。快递查询也是类似场景。几家快递公司网页版的查询流程各不相同但 AI 能自适应页面变化帮我查完所有在途包裹的状态。这件事如果用传统脚本写维护成本会高得吓人——因为每个快递网站的页面改版都会让脚本失效。5.2 运营与客服的批量操作如果你是运营或客服重复性后台操作是最适合交给它的场景。我见过一个实际用法运营每天要审核一批用户提交的信息以前是逐条打开、点击通过、关闭、下一条。现在给智能体一个任务在审核后台把今天的待审核记录逐条打开如果内容合规就点击通过最后给我一个通过数量的汇总。它能一直跑遇到拿不准的情况会停下来问你。这里我特别要提醒批量操作是高危场景。如果你给它的指令涉及通过这种有业务后果的动作一定要配置人工确认。我见过翻车案例——模型理解错了字段把本该打回的全部点击了通过还好业务上有回滚机制。5.3 测试与 QA 的自然语言化测试场景也很有意思。传统 UI 自动化测试要写大量选择器和断言页面一改就崩。现在你可以用自然语言描述测试用例登录后台新增一个商品填必填字段提交确认列表里出现新商品。智能体自己在页面里定位元素、操作、校验结果甚至还能截图保存证据。这种模式特别适合冒烟测试。每次发版前跑一轮自然语言定义的冒烟用例不用维护繁琐的脚本发现页面变化时 AI 会自动调整操作策略。缺点是执行速度比传统脚本慢毕竟每一步都要模型推理所以更适合低频的验收场景不适合需要毫秒级并发的压力测试。5.4 内容采集的合规边界利用登录态读取数据的能力天然适合做自己有权访问的数据的采集。比如你自己的后台报表、你订阅的数据服务、你名下的账单记录。这个场景效率极高因为不用处理登录和风控。但我要说清楚合规边界不要拿它去爬取需要特殊权限才能访问的平台内容也不要绕过反爬机制去采集你不拥有或不具备访问权的数据。不同平台的服务条款对自动化抓取有明确规定登录态复用不代表你有权访问所有数据。做内容采集之前先确认你对数据有合法的访问和使用权这是底线。6. 我踩过的坑以及几条保命建议6.1 稳定性翻车现场弹窗、懒加载、iframe先说稳定性。虽然这个项目解决了登录态的大问题但它并没有解决网页本身的一切怪癖。我实测时遇到最多的三类问题是弹窗遮挡、懒加载、iframe 嵌套。弹窗是最常见的坑。很多网站一进来会弹订阅引导、Cookie 同意框、活动浮层这些弹窗会遮挡按钮AI 点击目标元素时经常点到弹窗上。我的解决方法是在任务指令里明确加一句遇到弹窗先关闭再继续或者提前在浏览器里装一个全局弹窗拦截扩展。懒加载的问题是页面很长的时候底部元素没有滚动到可视区域就不在可访问性树里AI 找不到目标。项目通常会内置滚动逻辑但有时滚动速度太快触发的是滚动加载而不是逐项加载。遇到这种情况我一般会把任务拆小或者明确告诉它每滚动一屏就等待一秒。iframe 嵌套则更隐蔽。可访问性树对跨域 iframe 的穿透能力有限AI 有时候能看到 iframe 的存在但拿不到内部元素。如果你的目标系统大量使用嵌入式页面建议先确认这个坑或者改用坐标点击的辅助模式。6.2 模型手滑怎么办破坏性动作必须设防大模型在理解页面上偶尔会出错这种出错在普通场景没多大影响但如果目标元素是删除或提交按钮后果就可能严重了。我见过一次真实情况让 AI 整理某后台的废弃记录它从一个下拉菜单里识别到了清空全部选项如果不是我开了敏感动作确认那批数据就没了。所以我的建议非常直接所有涉及删除、清空、转账、支付、发送到外部邮件的动作一律开启人工确认。任务指令里就写清楚禁止动作比如不要点击任何包含删除、清空、注销字样的按钮。在敏感页面启用只读模式从机制上禁止写操作。如果 AI 反复尝试执行未授权动作直接停止任务并检查日志。记住浏览器智能体是在你的真实账号环境里操作它没有数据删除后还能恢复的魔法。防一手永远不亏。6.3 登录态安全别把本地端口当摆设登录态复用是优势也是安全责任。既然模型能通过调试端口操作你的浏览器这个端口就必须看管好。我整理了几条保命建议调试端口只用本机回环地址不要改成0.0.0.0也不要搞端口映射到外网。使用独立用户目录跑智能体不要直接操作你存了大量密码和支付信息的日常浏览器配置。日志和截图做脱敏避免把 Cookie、Token、手机号等敏感信息写进日志文件。长时间不用的调试进程要关掉别让一个带登录态的浏览器端口一直开着挂后台。给智能体用的浏览器配置里最好只登录任务必需的网站不要把全部个人账号都塞进去。这些不是危言耸听。一个带全套登录态、还被调试端口开放的浏览器如果暴露在网络上基本等于把你所有账号的钥匙放在了门口。6.4 版本迭代和依赖坑项目还很年轻这类项目迭代非常快你如果把它当成一个稳定的长期依赖来用需要有心理准备。Chrome 升级带来 CDP 行为变化、模型版本切换导致动作输出格式不兼容、依赖包更新引入未知问题这些我都遇到过。我的经验是第一固定你环境里的 Chrome 版本至少在关键任务运行期间不要随意升级第二把项目依赖版本锁定不要直接用 latest第三跑关键任务之前先在有变动的页面上做一次冒烟验证第四遇到莫名其妙的问题先去 GitHub Issues 里搜你踩的坑大概率已经有人踩过了。我自己现在的用法是把它当成一个带眼睛和手的本地助理每周五让它去几个后台把报表汇好顺便把订阅账单汇总出来我只要最后过目一眼。它还不完美偶尔会在奇怪弹窗上卡住但方向已经对了——浏览器智能体本来就该在我们日常环境里工作而不是在模型厂商的云端虚拟桌面里。如果你也打算跑起来建议从低风险、纯读取的任务开始跑熟之后再逐步放开权限。这篇就到这祝你的第一个智能体任务顺利跑通。