上周我把一个早就该自动化的任务交给编码 Agent 去做——整理某个后台系统的运营数据，逻辑很简单：登录、点几个菜单、导出一张表。结果 Agent 在登录页卡了整整两个小时。不是它不会点按钮，而是身份验证这一关根本过不去，验证码、短信、行为校验轮番上阵，无头浏览器怎么模拟都差一步。后来朋友提了腾讯 BrowserSkill 这个项目，我才意识到，这个问题根本不是"能不能点"，而是"你是谁"。BrowserSkill 的思路很特别：让 AI Agent 直接借用你当前已经登录的真实浏览器，通过一条本地桥把浏览器会话和编码 Agent 连接起来。Agent 不需要重新登录、不需要模拟指纹，它只是以一个"实习生"的身份，被放进了一个已经验明正身的浏览器环境里。这篇文章我想把这个工具的定位、工作原理、搭建路径以及我在实测中踩到的坑完整写一遍，特别是它和 Playwright MCP、Agent Browser 这类方案的差异，帮你选型时少走弯路。
1. 编码 Agent 跑得好好的，为什么一碰浏览器就翻车
1.1 登录态：Agent 最缺的不是能力，而是"身份"
先说一个最容易忽略的事实：编码 Agent 本质上是"无状态"的。哪怕你用的模型上下文再长，它每次接到任务时，关于"我是谁""我做过什么"的持久的会话身份几乎是零。大型语言模型的对话机制决定了它擅长处理的是"接下来该做什么"，而不是"我三分钟前登录过那个网站"。
而 Web 应用判断你是谁，靠的是一整套复杂的会话状态：Cookie、Session ID、LocalStorage、浏览器指纹、IP 和 TLS 特征等等。普通文本任务根本碰不到这一层，但一旦让 Agent 操作浏览器，"身份"就是生死线。你想让 Agent 打开一个后台系统的报表页面，页面还没来得及渲染，先反问一句：你是谁？凭什么给你看？
用一个生活化类比：你进公司大楼，保安不会每次都考核你的身份，而是发给你一张临时工卡，之后每一道闸机只认这张卡。Agent 很擅长帮你规划怎么走过走廊、怎么按电梯、怎么找到会议室，但它手里没有那张工卡。于是每次走到闸机前，它都只能停下来，反复试探。
这时候如果你坚持让 Agent 用无头浏览器重新走一遍登录流程，它面对的就不再是一个简单的密码框，而是一个专门用来拦截自动化程序的完整防线。
1.2 反自动化机制：浏览器越来越难"装成真的"
不少人对浏览器自动化还停留在 Selenium 时代，"用代码打开网站，找到输入框，填写提交"就完事。真实情况远不是这样。现在的 Web 应用会做一套组合拳：检测navigator.webdriver标记、分析鼠标轨迹和点击间隔、检查 Canvas 指纹、要求过验证码，甚至在你登录后持续做行为风控。
一个相当讽刺的现实是，反自动化技术越做越强，很大程度是因为滥用太严重——爬虫、刷量、恶意注册。真正的普通用户被误伤的也很多。你让 Agent 去登录一个验证严格的系统，这和让它去破解一套安全机制没什么区别，反复被拦下来几乎是必然的。
我见过有人为了让无头浏览器"看起来像真的"，往代码里塞了一大堆反检测脚本，改 UA、改 WebGL 指纹、模拟随机点击延迟。折腾了两周，最后还是会被一些高版本的安全策略识别出来。方向就不对：你在试图把一个假身份演成真的，而对方的安全模型早就在等这样的演员了。
1.3 最常见的三种绕路方案及其代价
既然无头登录这么难，那实际项目中大家是怎么绕的？我在不同团队里看到过三种主流做法，它们各有各的代价。
第一种：把登录后的 Cookie 复制出来，塞给脚本。这种方法确实能绕过登录页，但 Cookie 往往绑定了 User-Agent、IP 甚至设备指纹，换个环境就失效；很多关键 Cookie 还带有严格的过期时间，分钟级别失效的也不算罕见。更麻烦的是，一些敏感系统的 Cookie 是 HttpOnly 的，你从浏览器 DevTools 里根本复制不出来，得用工具从存储文件里挖，一不小心就把自己的账号安全搞出个洞。
第二种：用 Playwright 或 Puppeteer 起一个持久化 profile，手动登录一次，以后复用。这是目前比较主流的方式，确实能解决部分问题。但持久化 profile 本质上还是一套被自动化框架"托管"的浏览器环境，很多反自动化系统依然能识别出其中的自动化特征。另外，只要登录态一过期，又得回到手动登录，整个流程就断在那里。
第三种：用桌面自动化工具去控制真实浏览器，比如 pyautogui、Win32 API 模拟鼠标键盘。这个方案是真的能拿到真实浏览器环境，但它非常脆：屏幕分辨率变了、渲染节奏慢了一点、某个弹窗挪了位置，脚本立刻失灵。维护成本极高，而且你没法让 Agent 读懂页面状态，只能按固定坐标盲点，等于把 AI 用成了按键精灵。
这三种方案我都试过，最后得出的结论是：最难的从来不是"驱动浏览器"这个动作，而是"以一个合法身份存在于一个真实浏览器环境里"这件事。BrowserSkill 恰好是从这个事情本身下手的。
2. BrowserSkill 的定位：不是浏览器驱动，而是一座本地桥
2.1 它不"造"浏览器，而是"借"你现成的浏览器
大多数浏览器自动化方案的工作路径是：帮你启动一个新的浏览器实例，然后在这个新实例里模拟一切。这里的隐含假设是——一个新的、干净的浏览器实例才是最可控制的。
BrowserSkill 的思路几乎反过来了。它不启动任何新浏览器，而是找到你本机正在运行的、已经登录过的那个真实浏览器进程，直接挂上去。Agent 发出的指令通过本地通道传到这个真实浏览器，浏览器执行操作，再把结果送回给 Agent。
这个思路最大的好处，是它把"身份验证"和"自动化操作"这两件事彻底拆开了。身份验证本来就是一个难题，验证码、短信、二次确认，每一步都是为了证明"对面是真人"。与其让 Agent 去模拟真人，不如直接在一个已经完成全部验证的真人会话里干活。你不需要让 Agent 重新证明自己是谁，它只需要借用你已验证好的那张"工卡"。
我第一次看到这个设计时，第一反应是：这不就是"魔法"吗？一个已登录好的浏览器，一个本地桥，再加一个 Agent，就等于一个能操作你常用线上服务的自动化助手。确实有魔法的味道，但底子非常务实。
2.2 "本地桥"和 SSP 意味着什么
标题里的 SSP，我个人的理解是 Session Sharing Protocol，也就是会话共享协议。它描述的就是这条本地桥的核心职责：把真实浏览器里的登录态、Cookie、页面上下文，安全地、可控地共享给另一端的编码 Agent。
Bridge 这个词在软件工程里被用滥了，但放在这里非常贴切。BrowserSkill 不是浏览器本身，也不是 Agent 本身，它是两者之间的一个中介层。在这个链路里，浏览器负责它最擅长的事——渲染真实页面、维持真实登录态、通过所有风控校验；Agent 负责它最擅长的事——理解任务、做决策、规划下一步操作。中间的桥负责把 Agent 的意图翻译成浏览器听得懂的指令，再把浏览器的状态翻译成 Agent 看得懂的结果。
用角色来理解就是：浏览器是"身体"，Agent 是"大脑"，本地桥就是连接大脑和身体的神经系统。
从架构角度看，这条桥有几个隐含的设计意图，值得注意。第一，它必须是本地的，登录态这种级别的私密数据不应该经过任何云端中转；第二，它应该遵循最小权限原则，Agent 只能拿到它完成当前任务需要的操作能力，而不是整个用户配置文件；第三，它应该是可观测的，桥两端发生了什么，你随时能查看、能中断。这三点在后面的实操部分会直接影响具体配置。
2.3 为什么坚持"本地"而不是"托管在云端"
如果你用过一些云端的浏览器自动化服务，可能会疑惑：登录态放在云端，随时随地能用，不是更方便吗？这个问题的答案既有技术层面，也有安全层面。
技术层面，本地方案延迟极低。Agent 让浏览器打开一个页面，返回结果一般在几十毫秒级别；而云端方案里，截图要上传、指令要下发、页面状态要同步，来回几趟面对复杂的交互任务会非常难受。更别提如果目标系统做了 IP 风控，你的云端服务器 IP 大概率早就进了风控库。
安全层面更直接。浏览器登录态是个人身份的核心凭证，放在本机，你可以用操作系统的文件权限、防火墙、杀软来保护它；放在云端，等于把家里的钥匙交给一个远程仓库保管。大部分安全最佳实践都不建议这么干。BrowserSkill 坚持本地桥的形态，在我看来正是因为这是唯一既实用又相对可控的方案。不是说它绝对安全，而是把风险边界画得很清晰：身份不离开你的机器。
3. 桥的每一环：从浏览器"开口说话"到 Agent 完成一次登录态任务
3.1 第一步：让浏览器进入可调试状态
要让 BrowserSkill 接管你的浏览器，首先需要让浏览器"开口说话"。Chrome 内核的浏览器都内置了远程调试协议（CDP，Chrome DevTools Protocol），正常情况下它只对 DevTools 开放。你需要用参数启动浏览器，把这个调试通道打开。
一个典型的启动命令是这样的（以 Chrome 为例）：
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --remote-debugging-port=9222 \ --user-data-dir=/tmp/browserskill-profile \ --remote-debugging-address=127.0.0.1Windows 下换成chrome.exe的完整路径，参数一样。有三个细节值得多说一句：
--remote-debugging-port=9222指定调试端口，这个端口只应监听127.0.0.1，千万别去掉--remote-debugging-address的限制，否则局域网里任何设备都能往你的浏览器里塞指令。--user-data-dir指定一个独立的 profile 目录，这是为了跟你的日常浏览器数据分开。如果你直接复用默认 profile，Chrome 会拒绝启动，因为默认 profile 已经被你日常运行的那个浏览器实例占用了。- 如果你希望 BrowserSkill 能直接继承你平时登录过的那些站点会话，这里就有一个关键操纵：你需要在启动这个调试模式浏览器之前，先把日常 Chrome 完全退出，然后用同一个默认 profile 来启动；或者把登录态顺着复制到新的 user-data-dir。这个我后面在踩坑部分专门展开。
3.2 第二步：把 BrowserSkill 本地桥拉起来并验证连通
浏览器调试端口开好之后，你可以先用一个最简单的命令确认浏览器已在"可被接管"状态：
curl http://127.0.0.1:9222/json/version如果返回一段包含浏览器版本、调试协议版本的 JSON，说明 CDP 通道已经通了。到这个阶段，其实你已经有能力用 WebSocket 连接这个端口去做各种自动化操作了，BrowserSkill 做的事，就是把这一步变成编码 Agent 可以理解和调用的一层工具。
接下来就是启动 BrowserSkill 本身。不同版本可能提供的启动方式不太一样，有的通过命令行直接启动桥接服务，有的打包成一个可执行文件双击运行，有的是给你的 Agent 环境装一个插件。具体命令以官方 Release 页面的说明为准，我不在这里写死某种命令，避免误导。
启动成功后，你通常会看到一个本地地址加端口，比如http://127.0.0.1:8xxx，它对外暴露了一组接口，本质上是一份"浏览器操作能力清单"。你把这个地址告诉 Agent，Agent 就能通过它下发指令。聊到这一步，你其实已经完成了一条完整的链路：浏览器 → CDP 通道 → BrowserSkill 桥 → 编码 Agent。
判断桥是否连好，我有一个很实用的标准：让 Agent 打开一个需要登录的页面。如果 Agent 能看到页面正常渲染出登录后的内容，说明会话继承成功；如果它打开页面后跳到了登录页，那就是 profile 选错了，登录态根本没进到调试浏览器里。
3.3 第三步：把 BrowserSkill 挂到编码 Agent 上
编码 Agent 接入 BrowserSkill 的方式，大致有两种。
一种是直接把桥提供的接口声明成 Agent 的工具。这适用于大多数开源 Agent 框架，你可以把"打开页面""点击元素""填写输入框""读取页面文本""保存截图"这些能力逐条映射成 Agent 的 function calling 工具，Agent 在规划任务时会按需调用。
另一种是走 MCP（Model Context Protocol）协议。如果你的 Agent 已经支持 MCP，那更省事，BrowserSkill 可以作为 MCP server 注册进去，Agent 启动时自动发现工具列表。MCP 的好处是接口标准统一，切换 Agent 时不用重新配指令集。
我自己接入的时候，初始配置只用了四五个工具：打开 URL、读取当前页面的文本内容、点击指定坐标或指定元素、输入文本、截图。不要一上来就把所有操作能力都打开，工具太多的时候，大型模型反而容易选错，精简工具列表能让 Agent 的行为明显更可控。
配好之后，我建议跑一个最小验证：让 Agent 打开你日常最常登录的站点，然后让它汇报当前页面顶部显示的用户名或导航栏文本。如果它能准确读出登录后的信息，说明会话继承和操作链路都通了。
3.4 Agent 看到的是"画面"还是"结构"：回传形态的取舍
做过浏览器自动化的人都知道，Agent 需要"感知"页面状态才能做出下一步决策。BrowserSkill 这类桥接方案里，回传数据主要有三种形态，各自的取舍完全不同。
第一种是截图回传，把浏览器的可见区域截图给 Agent 看。画面信息最丰富，适合让 Agent 理解布局、发现弹窗、判断某个区块是否加载完成。代价是 token 消耗大，而且视觉模型对齐小的 UI 元素时偶尔会看错。
第二种是 DOM 结构回传，把页面的语义化结构提取出来发给 Agent。对文本密集型页面效果好，token 消耗小，Agent 能精确找到按钮、表单、链接。但遇到复杂前端框架，DOM 树会非常长，需要做裁剪和摘要，不然一条消息就塞满了。
第三种是状态摘要回传，也就是 Bridge 提前帮你总结"当前页面发生了什么"。比如"登录成功，跳转到控制台，有一个绿色提示条"。这种回传最省 token，但前提是总结逻辑得靠谱，否则 Agent 会在一个错误的认知上做决策。
实操中我是混用的：页面刚加载完用截图让 Agent 确认全局，需要精确操作的时候切换到 DOM 结构，日常轮询用状态摘要。这不算什么高级技巧，但能明显降低跑任务的失败率。
4. 同赛道的三个方案怎么选：BrowserSkill、Agent Browser 与 Playwright MCP
4.1 三者出发点完全不同
现在市面上能"让 Agent 操作浏览器"的方案不少，除了 BrowserSkill，还有 Playwright MCP，以及一些叫 Agent Browser 的项目。很多朋友会问，它们到底有什么区别？直接比参数表意义不大，先看出发点更清楚。
Playwright MCP 是微软开源 Playwright 的 MCP 化封装。它在 MCP 协议之上暴露一组浏览器自动化工具，Agent 想点击就调用点击工具，想填表就调用填表工具。它的底层驱动还是 Playwright 自己拉起浏览器实例，所以本质上依然是"Agent 拥有一个新浏览器"。
Agent Browser 这类项目则更偏产品形态，直接把浏览器作为 Agent 的"感官和手"，通常提供一套 Agent 外围的界面层，让你通过会话方式指挥浏览器干活。它和 BrowserSkill 最大的不同在于，Agent Browser 里的浏览器往往是被 Agent 框架托管的全新实例，登录态还是要你自己处理。
BrowserSkill 的出发点则完全不同：它默认你本机已经有一个真实的、登录过的浏览器，它只是想办法把"这个浏览器的操作权"安全地交给 Agent。换句话说，前面两个方案是"给 Agent 配一个浏览器"，BrowserSkill 是"让 Agent 借用你的浏览器"。
4.2 用一张表看核心差异
我把几个关键维度列成对照表，方便你按自己的场景去衡量：
| 维度 | BrowserSkill | Playwright MCP | Agent Browser 类 |
|---|---|---|---|
| 核心思路 | 复用真实浏览器会话 | 提供 Playwright 工具给 Agent | Agent 内置托管浏览器 |
| 登录态处理 | 直接继承已登录状态 | 重新登录或持久化 profile | 多数需要重新登录 |
| 反自动化识别风险 | 低，因为它是真实浏览器 | 中，自动化特征较明显 | 中高，托管环境易被识别 |
| 性能开销 | 极低，复用现有进程 | 中，每次需拉起浏览器实例 | 中高，经常还要持久化存储 |
| 部署复杂度 | 低，本地即可 | 中，需要配置 MCP 环境 | 中高，依赖产品框架 |
| 适合场景 | 强身份验证、真实登录态 | 无登录或弱登录的页面操作 | 产品化的人机协作浏览 |
这个表格只能给一个大方向，实际边界没有那么泾渭分明。比如 Playwright MCP 也支持 connect-over-cdp 去连接已有浏览器，但那是把 CDP 作为连接通道，和 BrowserSkill 默认的"复用会话"设计目标不同。
4.3 什么样的场景优先选谁
先说结论。如果你要操作的系统有严格的登录验证、敏感后台、或者你个人的账户数据，BrowserSkill 是明显更顺手的方案。因为你既不用调验证码，也不用花精力做反检测伪装，它天然就是一个"真人已登录"的浏览器。
如果你做的是公开页面自动化、表单测试、或者对登录态要求不高的数据采集，Playwright MCP 更合适。它工具链完善，元素的定位能力更强，写起测试用例来也更顺。毕竟 MCP 生态里它的成熟度和社区活跃度都很高。
Agent Browser 一类方案更多是产品层面发力，适合你想把浏览器操作能力封装成一个对外产品，而不是自己本地跑任务。它对开发效率的提升可能没有前两者直接。
我自己目前的组合是：日常爬公开资料用 Playwright MCP，碰到必须登录的后台操作、需要我真实账号身份的任务，一律切到 BrowserSkill。两者不冲突，各管一段。
4.4 一个典型的适用场景：后台报表自动化
举个我实际跑过的例子。我有一套推广后台，导出报表必须先登录，登录过程有短信验证码，而且系统会做行为风控，频繁切换 IP 就会被锁定。
之前用 Playwright 做，得提前把 cookie 导入持久化 profile，两天一过期，过期就得手动登录一次。后来切到 BrowserSkill，我只需要在本地把调试浏览器开着，日常先登录好后台放着。Agent 下命令：打开报表页、切换日期范围、点击导出、等待下载完成。整个过程不需要任何验证码交互，因为后台看到的就是一个已经登录的、稳定 IP 的、行为完全真实的浏览器在操作。
跑了一周多，只出现过一次问题，还是因为我的导出操作太频繁触发了限流，而不是身份验证的问题。这就是"真实会话复用"方案真正的价值。
5. 从 0 到 1 的搭建路径：日志、会话与踩坑记录
5.1 开始之前必须做的三件琐事
第一次搭 BrowserSkill 之前，很多人会直接执行命令，然后被各种怪问题卡住。我给三个前置建议，能省你不少时间。
第一，确认浏览器能支持 CDP。Chrome、Edge、Brave 这些 Chromium 内核浏览器都可以，Firefox 走的是另一套 WebDriver BiDi 协议，兼容性要单独看。务必用较新的版本，老版本的 CDP 接口更新不完整。
第二，确定你要用哪个用户数据目录。是复制一份常用登录态到独立目录，还是临时直接用默认 profile？我强烈建议为自动化任务单独建一个 profile 目录，日常浏览器照常用，两者互不干扰。这也是防"误操作"的第一道隔离墙。
第三，检查端口占用。9222 是常见调试端口，如果本机已有别的工具占用，换一个不常用的端口。启动后第一时间用curl http://127.0.0.1:端口/json/version验证，这一步过不了，后面全部白搭。
5.2 我第一次跑通的完整过程
拿我 Mac 上的实际过程举例。先完全退出 Chrome，然后执行：
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --remote-debugging-port=9222 \ --user-data-dir=/tmp/bs-work \ --remote-debugging-address=127.0.0.1 &浏览器起来后，我在/tmp/bs-work这个新目录里手动登录了一次目标后台。这就是"让这个 profile 拥有登录态"的关键一步。登录完不用退出浏览器，保持窗口开着。
接下来启动 BrowserSkill 的桥接服务，端口号它在启动日志里会打出来。我用 Agent 的方式简单测了一下：让 Agent 打开后台首页，读出页面上我的账号信息。Agent 顺利读取到了，说明桥已经通了。
整个过程大约十分钟。这里有一个容易被忽略的点：为什么第一次要在新 profile 里手动登录？直接复制一个现成的 profile 目录不行吗？可以，但复制 profile 的前提是复制的目标浏览器没有在运行，否则是文件锁状态，复制出来的数据是残缺的。手动登录一遍虽然麻烦，但最稳。
5.3 踩坑链路一：调试端口完全没有反应
我第一次启动时遇到的问题是：Chrome 确实起来了，但访问http://127.0.0.1:9222/json/version一直连接不上。排查过程是这样展开的。
先看进程是否存在，命令行参数是否生效。如果浏览器已经有一个实例在跑，新执行的带--remote-debugging-port的命令并不会真正开一个新实例，而是把参数传给已有实例，然后退出。已有实例没有监听调试端口，所以 curl 必然失败。这就是典型的"看起来参数写了，其实没生效"。
我的排查链路：ps查看所有 Chrome 进程 → 发现多个实例在跑 → 全部退出 → 再带着参数重新启动 → curl 立刻通了。这个问题如果你不了解 Chrome 的单实例逻辑，很容易卡一下午。遇到调试端口连不上，第一反应就该是：是不是已经有一个不认这个参数的浏览器实例活着？
5.4 踩坑链路二：浏览器"接管了"但登录态丢了
另一个让我印象深刻的坑是：连上之后，Agent 能打开页面，但所有网站都显示未登录。原因也很直接——我用--user-data-dir指定了一个全新的目录，这个目录里除了浏览器的默认配置，什么都没有。登录态、Cookie、账户信息一概没有。
这种问题的排查链路：先看浏览器地址栏，手动在目标网站打开一个页面，如果跳到登录页，意味着 profile 里根本没会话。再确认浏览器是不是连了远程调试的 profile 之后才登录的，如果登录发生在日常浏览器，而调试浏览器用的是别的目录，两边数据天然不互通。
我的解决方式很简单:要么先退出日常浏览器，用默认 profile 带调试参数启动;要么在新 profile 里手动登录一次。前者继承全部日常会话，但会让你日常浏览器和 Agent 共用一套证书，风险高;后者隔离干净，只是每次新增站点要手动登录一次。做自动化任务我更推荐后者，安全边界清楚。
6. 边界条件与安全底线：这两个问题必须在用之前就想清楚
6.1 哪些场景不建议让 Agent 借用你的浏览器
BrowserSkill 不是万能的。有几类场景它确实是"不合适"的，硬上会很难受。
第一，高并发任务。它依赖的是你本机一个孤独的浏览器实例，并发能力天然受限。如果你要一次性跑几百个页面，或者做大规模采集，应该用真正的自动化集群方案，而不是把真实浏览器的任务通道当成压测工具。
第二，需要长时间无人值守的周期性任务。真实浏览器的会话会过期，页面会休眠，系统会弹更新提示。我跑过几次隔夜任务，最后发现浏览器被系统更新重启了，任务白跑一整晚。这种情况更适合用有内置重试机制的服务化方案，而不是本地桥借会话。
第三，你无法接受 Agent 在你的真实浏览器里误操作造成的后果。只要 Agent 有操作能力，就有出错的可能。它可能点错按钮、发错消息、删错数据。如果你把这些操作放在日常主要使用的 profile 里，风险是实打实的。这时候你需要权衡：是隔离 profile 牺牲便利，还是承担真实环境误操作的风险。
6.2 权限边界：如何把"借用"控制在你能接受的范围内
安全边界这件事，我强烈建议在搭好之后立刻做几个设置。第一，调试端口只监听本机，--remote-debugging-address=127.0.0.1这个参数不能省。第二，为自动化单独用 profile 目录，别和日常浏览器混用。第三，定期清理自动化 profile 里的登录态，隔一段时间重新登录一次，避免一个不用的长会话在后台挂着。
更重要的是，要在 Agent 指令层面做约束。比如在 Agent 的系统提示词里明确写：只允许读取和导出，不允许修改、删除、发送任何内容。这个约束不是铁律，但能显著降低 Agent"自由发挥"的概率。我自己还会在关键操作前增加人工确认环节，比如"删除、发送、提交"这类动作，必须在执行前停下来问用户。
这类约束听起来有点像给自己绑手绑脚，但它换来的安全回报非常大。你借出去的不是一个浏览器，而是你的数字身份。操作越敏感，"借用"的范围就应该越小。
6.3 给新手的实用配置清单
如果你准备开始尝试，我整理了一份可以直接照做的清单：
- 用独立 profile 目录启动调试浏览器，端口固定为高位端口，只监听 127.0.0.1。
- 登录你需要操作的目标站点，确认登录态可用后再启动 BrowserSkill。
- Agent 工具列表保持精简，只开放完成当前任务必需的操作能力。
- 在 Agent 系统提示词里写明禁止修改、删除、发送等高风险操作。
- 定时检查自动化 profile 的会话列表，不需要的站点直接退出登录。
- 关键任务前置步骤先跑一次人工手动流程，确认页面路径和预期结果。
这份清单不是理论产物，是我在跑了几十次实际任务之后总结出来的。大多数问题都是漏了其中一条导致的。
最后分享一个小技巧。本地桥跑起来之后，我习惯把调试浏览器单独放到一个桌面，用定时脚本每隔一段时间自动刷新一次关键后台页面，防止长时间挂机导致登录态过期。遇到必须人工输入的验证码，我会在 Agent 指令里写死"先暂停并通知我"，而不是让它反复重试，这样既省 token，也避免触发风控。
这个工具不是银弹，但它提供了一个特别合理的思路：把最难的部分——身份、会话、反自动化——交给已经解决过这些问题的真实浏览器，让 Agent 把力气花在它真正擅长的决策和规划上。方向对了，剩下的就只是时间问题。
