BrowserSkill：编码Agent复用已登录浏览器的本地桥

说实话第一次看到“BrowserSkill”这个项目时我的第一反应是又一个浏览器自动化封装但把标题里“已登录浏览器与编码 Agent 之间的本地桥”这句话读完我意识到它解决的痛点完全不一样。用过 Cursor、Claude Code、Codex 这类编码 Agent 的人都懂Agent 写代码很强但一旦碰到需要登录态的页面比如公司后台、有权限控制的文档平台、带验证码的站点它就彻底抓瞎。不是 Agent 不够聪明而是它根本拿不到“已登录”这个环境。BrowserSkill 的核心思路非常朴素既然用户自己已经在浏览器里登录好了各种站点那为什么不让 Agent 直接“借用”这个真实浏览器的会话能力通过在本地搭一座桥Agent 可以调用浏览器当前页面的内容、执行点击和输入、读取页面状态却能完全绕开重新登录、过验证码、处理双因素认证这一大堆麻烦事。这篇内容我会从架构拆解、最小实现、实战场景、安全边界几个角度把这座本地桥讲透。1. 为什么编码 Agent 干不了“带登录态的活”要理解 BrowserSkill 的价值得先搞清楚编码 Agent 在真实环境里会卡在什么地方。很多人一开始觉得Agent 什么都能干——让它去某个网站抓个数据、填个表单、验证一下页面效果不是理所当然吗实际跑一轮你就知道噩梦从“登录”这两个字开始。1.1 Agent 没有“眼睛”更没有“登录记忆”编码 Agent 本身没有浏览器它能感知的是一个工作目录、终端输出和文件内容。让它去访问网页通常只有两条路一是直接发 HTTP 请求那就面临 Cookie 怎么带、Token 怎么刷新的问题二是调用 Playwright 这类自动化工具打开一个全新、干净的浏览器实例。问题来了这个新实例里什么都没有——没有登录态、没有历史记录、没有插件连最基本的“记住我”都是空白的。真实场景中公司后台、云控制台、设计稿平台、数据看板哪个不是靠登录态吃饭的有些还叠加了验证码、短信验证、扫码确认、企业 SSO 跳转。让 Agent 从零开始走完整套认证流程不是我打击人绝大多数 Agent 连“该点哪个按钮”都要尝试十几次最后大概率卡在某个动态验证码上然后整个任务超时。1.2 无头浏览器能解决一半但剩下的一半更致命有不少团队会用 Playwright、Puppeteer 做自动化我也用它们做过爬虫和 E2E 测试。但它们的设计目标是“模拟一个用户”而不是“复用这个用户”。它们解决的是环境隔离问题却把“认证”这个最复杂的工程问题完整地留给了你。你想想自己是不是也干过这种事用 Playwright 启动浏览器然后手动把登录后的 Cookie 从 Chrome 里抠出来塞到脚本里去。能用但维护成本极高Cookie 一过期就废。如果站点用了 HttpOnly Cookie你在脚本里根本取不到只能硬着头皮走一遍登录流程。碰到验证码你还要接打码平台或者干脆卡死在那里。而 BrowserSkill 的思路相当于把“用户已经登录好的那个浏览器”变成了 Agent 的外设。Agent 不再需要关心你是怎么登录的它只关心当前页面是什么状态、我要点击哪个元素、输入什么内容以及执行完之后页面变成了什么样。这是从“模拟用户”到“借用用户”的本质转变。1.3 会话是本地资产不应该反复重建浏览器里的登录态本质上是用户的本地资产。Cookies、LocalStorage、IndexedDB 这些东西都存储在用户自己的电脑上。为了跑一个自动化任务就要求用户在另一个环境里重新登录一遍这既繁琐也不安全。更现实的问题是很多站点有风控策略频繁的异地登录、可疑设备检测会直接触发验证甚至封号。BrowserSkill 的聪明之处在于它完全不碰认证流程——用户已经在网页里登录成功了Agent 只是站在旁边通过本地桥拿到“当前这个已认证页面的访问权”。这个过程中用户的身份没有发生任何迁移风控系统看到的始终是同一个浏览器环境自然不会触发异常。说白了登录这件事保持“人来做、人来管”才是最稳妥的。2. BrowserSkill 的本地桥架构三个角色与一次完整的握手既然核心是“本地桥”就得分清楚桥的两端分别是什么以及桥本身承担了多少责任。拆开来看BrowserSkill 涉及三个角色浏览器侧的扩展或注入脚本、本地桥服务、以及编码 Agent。三者配合才能完成一次“从 Agent 指令到浏览器操作”的完整链路。2.1 三个参与者各自是什么从功能上划分我们可以把整个链路抽象成一张表角色所在位置核心职责浏览器扩展Session Provider用户已登录的真实浏览器暴露当前页面的 DOM 状态接收操作指令并执行点击、输入、滚动、读取等动作本地桥服务Bridge用户本机提供 HTTP 或 WebSocket 端口做请求转发、权限校验、会话标识管理编码 AgentConsumer用户本机的终端/IDE通过 Tool 调用本地桥接口获取页面内容或下发操作指令很多开源项目喜欢把扩展和服务合并成一个“一体化工具”但实践中分开做更合理。扩展负责跟浏览器打交道桥服务负责跟 Agent 打交道职责边界一清晰出问题的时候排查范围就能立刻缩小。2.2 一次完整的指令链路长什么样我假设你正在用编码 Agent 调试一个前端项目页面打开后发现按钮点击无效。Agent 决定先读取一下页面控制台是否报错。一次典型的 BrowserSkill 调用流程大致如下Agent 调用本地桥工具传入动作类型getConsoleLogs。本地桥服务收到请求检查请求来源是否为本机回环地址校验 Token。桥服务通过浏览器扩展的调试通道向当前激活标签页注入读取脚本。浏览器扩展执行脚本抓取控制台日志和当前页面 URL返回结构化 JSON。桥服务把结果原样回传给 AgentAgent 分析日志并决定下一步操作。这个过程端到端耗时通常几百毫秒到一两秒取决于页面复杂度和桥的实现方式。关键是全程里浏览器窗口是真实可见的用户能亲眼看到 Agent 在操作页面而不是在一个看不见的黑盒里跑。这一点对信任感的建立特别重要。2.3 SSP 更像是“会话协议约定”标题里带了“SSP”三个字母很多人好奇是什么缩写。从项目命名习惯看我认为它更接近“S 会话 本地服务”协议的缩写——简单理解就是一套约定桥如何描述一个会话、如何给会话分配标识、Agent 如何在不知晓具体 Cookie 值的情况下引用这个会话。实际我在本地实现桥接时也是按这个思路设计协议接口的。比如获取会话信息时接口不会返回 Cookie 原文而是返回一个session_handleAgent 只需要持有这个句柄就能在后续指令中引用当前浏览器会话。这样的好处很明显敏感数据不出浏览器、不出本机Agent 永远拿不到原始凭证。2.4 为什么不直接走 CDP 或者云端中继熟悉浏览器底层的人可能会问Chrome 本身就有 DevTools ProtocolCDP直接开一个远程调试端口不就好了理论上确实行但有两个现实问题。第一开启 CDP 端口后任何本地进程都能连接并控制浏览器权限边界太粗第二CDP 给的是底层操作能力Agent 需要自己处理 DOM 定位、事件派发、等待渲染这些脏活编码 Agent 的 Tool 设计会变得异常复杂。云端中继就更不合适了——用户的登录态一旦经过第三方服务器就等于把账号安全交给了别人。浏览器里登录着网银、邮箱、代码仓库把这些 Cookie 转发到云端任何一个环节泄了密代价都不小。本地桥方案虽然少了一点“随时随地访问”的便利但换来了最大的安全感我认为这个取舍非常正确。3. 从0到1跑通 BrowserSkill扩展、桥服务与 Agent 三件套网上已经有人放出 BrowserSkill 的下载包但我觉得与其找一个现成的二进制文件直接跑不如先花半小时理解它的最小组成模块。这样就算未来项目更新、接口变化你也能自己动手改造。下面是我在本地搭建最小可用版本时的完整流程所有路径和命名都以常用实践为准。3.1 准备环境三样东西少一样都跑不起来Chrome 或 Edge 浏览器我用的是 Chrome版本 120需要支持 Manifest V3Node.js 18 以上桥服务是 Node 写的低版本跑不了 ES Module一个支持 Tool 调用协议的编码 Agent我用 Claude Code 和 Cursor 分别试过建议准备一个单独的测试目录比如~/browserskill-demo后面扩展、服务、脚本都放这个目录底下方便管理。3.2 第一步安装浏览器扩展扩展的作用是给桥服务开一扇门让桥服务能读取页面状态和下发指令。安装时有两个细节比较关键Manifest 文件里要声明activeTab权限和scripting权限不然扩展没有权限读取当前标签页的内容。host_permissions建议写成all_urls否则桥服务请求会被跨域策略挡住我一开始只配了https://example.com结果换了个站点就报错。安装方式选“加载已解压的扩展程序”开发者模式下直接指向dist目录即可。安装成功后扩展图标上会有一个小徽标表示会话通道已经激活。3.3 第二步启动本地桥服务桥服务负责把 Agent 的请求翻译成浏览器扩展能理解的消息。最小实现里我用 Node.js 自带模块就能写不需要额外依赖。先初始化项目cd ~/browserskill-demo mkdir bridge cd bridge npm init -y然后创建一个server.js实现最核心的两个接口获取当前页面内容、执行点击操作。这里我贴一个简化的参考实现import http from node:http; import { randomUUID } from node:crypto; const TOKEN process.env.BROWSERSKILL_TOKEN || dev-token; const sessions new Map(); // 浏览器扩展会通过 WebSocket 或消息通道连上来这里用 Map 做简化 function registerSession(sessionId, sendAction) { sessions.set(sessionId, sendAction); } const server http.createServer((req, res) { const auth req.headers.authorization; if (auth ! Bearer ${TOKEN}) { res.writeHead(401); res.end(JSON.stringify({ error: unauthorized })); return; } if (req.url.startsWith(/page/snapshot) req.method GET) { const sessionId req.headers[x-session-id]; const sender sessions.get(sessionId); if (!sender) { res.writeHead(404); res.end(JSON.stringify({ error: session not found })); return; } // 请求扩展返回当前页面快照 sender({ type: GET_SNAPSHOT }, (result) { res.writeHead(200, { content-type: application/json }); res.end(JSON.stringify(result)); }); return; } if (req.url.startsWith(/page/click) req.method POST) { let body ; req.on(data, (chunk) (body chunk)); req.on(end, () { const { selector, sessionId } JSON.parse(body); const sender sessions.get(sessionId); if (!sender) { res.writeHead(404); res.end(JSON.stringify({ error: session not found })); return; } sender({ type: CLICK, selector }, (result) { res.writeHead(200, { content-type: application/json }); res.end(JSON.stringify(result)); }); }); return; } res.writeHead(404); res.end(JSON.stringify({ error: not found })); }); server.listen(3721, 127.0.0.1, () { console.log(BrowserSkill bridge listening on http://127.0.0.1:3721); });注意randomUUID在 Node 18 里可以直接用不需要额外包。桥服务监听在127.0.0.1而不是0.0.0.0这样只有本机能访问外部设备即使在同一局域网也连不上。启动服务BROWSERSKILL_TOKENdev-token node server.js3.4 第三步让 Agent“看见”本地桥桥服务本身只是一个 HTTP 接口Agent 要调用它需要把它声明成 Tool。以 Claude Code 为例在工具配置文件里加一个browserskill函数内部用脚本语言请求本地桥。这里我提供一个 Python 版本的示例方便你复制import json import os import urllib.request TOKEN os.environ.get(BROWSERSKILL_TOKEN, dev-token) BRIDGE_URL http://127.0.0.1:3721 SESSION_ID os.environ.get(BROWSERSKILL_SESSION, default) def browser_call(action: str, **kwargs): 调用本地桥执行浏览器操作 headers { Authorization: fBearer {TOKEN}, X-Session-Id: SESSION_ID, Content-Type: application/json, } path { get_snapshot: /page/snapshot, click: /page/click, }.get(action) if not path: return {error: funknown action: {action}} if action get_snapshot: req urllib.request.Request( BRIDGE_URL path, methodGET, headersheaders, ) else: payload json.dumps({selector: kwargs.get(selector), sessionId: SESSION_ID}).encode() req urllib.request.Request( BRIDGE_URL path, datapayload, methodPOST, headersheaders, ) try: with urllib.request.urlopen(req, timeout10) as resp: return json.loads(resp.read().decode()) except Exception as exc: return {error: str(exc)}配置好之后给 Agent 一个测试指令“用浏览器快照工具查看当前页面的标题和导航栏文字”。Agent 会按工具定义调起browser_call桥服务再把请求转给扩展最终你会在终端看到类似这样的输出{ url: https://workbench.example.com/dashboard, title: 数据工作台, body_text: 今日任务 12 个待审批 3 个项目……, elements: [ { tag: nav, text: 项目中心 数据看板 审批流 }, { tag: button, text: 新建项目 } ] }看到这个返回就说明整条链路已经打通。你当前所在的已登录页面内容已经可以被 Agent 结构化了。3.5 常见启动失败排查我在搭建过程中踩过几个坑列出来给你做一个快速对照现象大概率原因处理方式扩展装好后图标灰色扩展权限未生效或没有刷新页面重新加载扩展并刷新目标标签页桥服务报 401Token 不一致检查启动命令的环境变量和 Agent 侧配置Agent 请求超时扩展与桥服务的连接断开了打开扩展弹窗点“重连”或重启扩展点击接口返回 404页面的选择器不在可见区域Agent 先滚动到目标位置再执行点击补充一个我自己的习惯把所有配置都放进.env文件桥服务和 Agent 工具函数都从里面读取不在代码里写死任何 Token 和端口。这样既不担心有人把密钥提交到 Git 仓库切换测试环境时也只需要改一个文件。4. 最值得实战的三个场景调试闭环、登录态数据操作与本地联调工具跑通之后关键就是让它干真活。我专门花了几天时间把 BrowserSkill 接入我日常的编码工作流逐个验证了高价值场景。下面这三个场景是真正让我觉得“本地桥”值得存在的理由。4.1 场景一前端调试的“读-改-验”闭环没有 BrowserSkill 之前我用 Claude Code 改前端样式和交互逻辑最痛苦的是反馈回路太长。Agent 改完代码我得手动去浏览器刷新再手动打开控制台看有没有报错然后还得把报错内容复制回终端告诉 Agent。一来一回十分钟就没了。现在我的流程变成了Agent 改完代码后直接调用 BrowserSkill 的click操作按下页面上的刷新按钮或者我帮它按一下 F5。Agent 调用get_snapshot获取页面最新状态。如果发现控制台有报错Agent 再调用一个封装好的getConsoleLogs接口拿到错误堆栈。Agent 对照堆栈直接修改源码再触发下一轮验证。最典型的例子是调试一个表格组件的样式问题。Agent 原本只能靠猜测调整 CSS好几次改完样式反而把别的模块弄乱了。接上 BrowserSkill 之后它能实时看到页面宽度、元素间距、是否出现滚动条一套组合操作下来两三轮就能把问题修好。这个“看到结果再动手”的能力比任何代码分析工具都好使。4.2 场景二登录态数据平台上的取数与操作第二个场景价值更直接。我经常要从内部的运营后台导出报表之前是每天手动登录、手动选条件、点导出。有了 BrowserSkill 之后只要我在浏览器里保持后台的登录状态Agent 就能自己完成整套操作。流程大概是这样的Agent 先用快照确认当前是否已经在数据平台页面。通过click点击“报表中心”菜单再通过输入接口填充日期范围。调用“导出”按钮等待文件下载完成后用本地脚本把 CSV 移动到项目目录。这里有一个细节必须提醒凡是涉及表单输入的操作我都建议在桥服务上增加一个“输入值校验”的钩子确认输入内容符合预期后再真实填进页面。因为编码 Agent 生成的内容偶尔会出现乱编码或意外拼接直接在真实系统里提交错误数据可能比人类手滑还麻烦。我在桥服务里加了一个简单的 JSON Schema 校验输入内容不在白名单里就直接拒绝。4.3 场景三本地服务的真实浏览器联调第三种场景针对做全栈开发的场景。Agent 在本地启动了一个后端服务端口是 8080前端页面要调一个需要登录态的 API。问题在于Agent 本身拿不到登录态它用命令行直接请求这个接口只能得到 401。BrowserSkill 的处理方式非常自然因为真实浏览器里已经登录过这个系统Agent 让浏览器直接访问http://localhost:8080/api/dashboard桥服务把页面上的 JSON 响应抓回来Agent 就能看到真实的登录态请求结果。这个能力的意义在于Agent 可以从“登录墙”的后面去验证自己写的接口逻辑而不必费劲去 mock 用户身份。我在测试一个新的用户权限模块时就靠这个能力从普通用户和 admin 两个视角分别检查了接口返回效率提升非常明显。4.4 三个场景共同的关键细节你可能已经发现所有场景都建立在一个前提下浏览器里的登录态得是有效的。所以每次开始长时间任务之前我建议先让 Agent 调用一次快照接口做“会话检查”确认当前页面没有跳转到登录页。如果发现掉登录了就让用户手动完成登录Agent 继续等待。把“登录必须由真人完成”设成硬性规则既能避免账号风险也能减少自动化过程中的不确定性。5. 安全边界会话借用最容易翻车的六个细节会话借用本质上是在说有一个程序可以代替你在浏览器里做操作。能力越大责任越大。我自己在试用各种 Agent 工具时对安全边界这件事格外敏感下面这几个细节我认为是 BrowserSkill 这类工具落地前必须想清楚的。5.1 敏感数据不出本机更不能出浏览器浏览器里存储的 Cookie、LocalStorage 里的 Token、自动填充的密码这些都是高敏信息。BrowserSkill 的架构里桥服务应该只返回“页面内容”和“操作结果”而不是原始凭证。Agent 在任何情况下都不需要知道 Cookie 的值——它只需要知道“这个页面是已登录状态”就够了。如果你的桥接实现里需要向 Agent 传递会话句柄建议句柄是一次性的短时间有效用完即失效而不是生成一个永久有效的会话 ID。5.2 鉴权要做在桥服务上而不是依赖网络隔离尽管桥服务只监听了127.0.0.1但局域网里的恶意程序、浏览器的恶意网页都有可能通过 DNS Rebinding 之类的技巧访问到本地端口。所以 Token 鉴权不能省而且建议在请求头里带上自定义标记比如X-BrowserSkill-Version增加一层校验维度。另外不要使用固定的端口和 Token。我建议每次启动桥服务时都生成新的随机 Token由扩展通过安全渠道推送给 Agent 工具而不是把这些信息写在明文的配置文件里。5.3 高危操作必须二次确认快照、读取、滚动这类只读操作可以自动放行但点击“提交订单”“删除数据”“发送消息”这类不可逆的高危操作绝对需要在浏览器侧弹出一个确认框。我在本地桥的服务层加了一个危险操作列表凡是命中关键词的点击请求都会先在页面底部显示一条浮层等用户手动点“允许”之后才继续执行。一开始我觉得这样会影响自动化效率后来遇到过 Agent 因为理解偏差差点在一个生产环境的后台点了“清空全部数据”。从那之后我宁可多一次确认也不赌 Agent 的理解一定准确。5.4 人机验证和二次认证永远留给用户Agent 是不应该尝试去破解验证码、滑块、人脸识别这类人机验证机制的。这既是安全问题也是法律和合规问题。绝不能让 Agent 去绕过这些机制。正确的做法是Agent 检测到页面出现验证码时自动暂停操作并通知用户手动完成。我在桥服务里专门识别了几类常见的验证框特征一旦发现验证码相关元素就会返回一个HUMAN_INPUT_REQUIRED状态Agent 收到这个状态后必须停下来说人话告诉用户需要亲自处理而不是继续尝试各种诡异的解法。5.5 日志里绝不能出现明文会话信息既然是在本机做调试日志输出不可避免。但务必小心不要在日志里打印完整的请求头和响应体尤其是包含Authorization头的部分。我在桥服务的日志模块里做了一个脱敏处理任何请求头的Authorization和Cookie字段统一替换成[REDACTED]。这点看起来微不足道却是信息安全里最容易被忽略的环节。日志文件一旦被同步到云端、或者被发给别人帮忙看问题所有会话凭证就全裸奔了。5.6 最小权限不要把整个浏览器的控制权交给 Agent最后一条也是最容易被忽视的。很多浏览器自动化工具的默认做法是“给 Agent 全部控制权”让它能打开任意标签页、读取任意域名下的数据。但本地桥的语义其实可以更克制只允许 Agent 操作当前激活的标签页或者最多只允许操作一组白名单域名。我在桥服务里维护了一张允许访问的域名列表任何指向列表之外的页面操作请求都会被拒绝。这样做的好处是即便 Agent 的指令因为 prompt 注入而偏离预期它也无法越权访问用户的网银或邮箱。6. 和 Playwright、CDP 相比BrowserSkill 到底赢在哪这个项目刚出来的时候有不少人问这不就是换了个马甲的 Playwright 吗我在实际体验之前也是这么想的。但把三套方案都跑过一轮真实场景之后我得出一个很明确的判断它们解决的问题完全不在一个维度上。6.1 先看一个直观的对比表对比维度Playwright / Puppeteer直接使用 CDPBrowserSkill 本地桥登录态复用需要手动注入 Cookie 或重新登录需要处理认证流程天然复用用户当前会话人机验证处理困难通常需要额外服务困难不需要处理交给用户即可Agent Tool 接入复杂度高需要封装大量底层操作极高API 最基础低面向业务动作设计权限边界无边界脚本拥有全部控制权无边界端口开放即全控可按域名、按操作类型精细限制使用成本需要维护独立的浏览器环境需要手动调参数只需本地跑一个服务和扩展从表里能看出Playwright 更像是一套“通用浏览器自动化 SDK”它的核心竞争力是跨浏览器兼容性和细粒度的操作控制。但当你把它接到编码 Agent 上时中间少了一层“业务语义”的翻译Agent 调用起来很别扭。6.2 为什么我不建议直接裸用 CDPCDP 是 Chrome 提供的底层调试协议能力非常强大几乎能实现任何浏览器功能。但强大意味着复杂。举个例子如果 Agent 想“点击页面上标题为‘提交’的按钮”用 CDP 的话得先执行一段Runtime.evaluate的 JavaScript 代码自己写 DOM 查询和事件触发逻辑。用 BrowserSkill 的话桥服务已经把这层逻辑封装好了Agent 只需要传入一个选择器加动作类型。还有个更实际的问题CDP 远程调试端口一旦打开任何本地进程都能连上来发指令没有任何鉴权机制。BrowserSkill 至少在桥服务层做了一层 Token 校验和操作白名单安全边界清晰得多。6.3 真正的优势对“编码 Agent”语义友好BrowserSkill 的界面设计更像一组“原子工具”快照、点击、输入、滚动、监听控制台每个动作都对应 Agent Tool 的一个函数。你不需要教 Agent 如何写 DOM 选择器、如何处理异步渲染只需要告诉它页面里有哪些可交互元素它就能基于这些信息做决策。这种“语义友好”的价值在编码 Agent 的场景里被放得很大。因为 Agent 的上下文窗口有限你希望它把精力花在“改代码”上而不是花在“如何定位元素”的技术细节上。BrowserSkill 的快照接口直接返回语义化 JSON页面结构、按钮文字、输入框 placeholder 都一目了然Agent 可以基于这些信息快速做出下一步动作的决策。6.4 什么时候还是得回到 Playwright当然BrowserSkill 不是万能钥匙。如果要做大规模并行测试、跨浏览器兼容性测试、或者需要模拟不同设备尺寸的响应式布局Playwright 依然是更合适的选择。它可以在多台机器上并行跑多个独立环境这是基于用户真实浏览器的方案做不到的。所以我的结论是两者不是替代关系而是互补关系。BrowserSkill 适合接在编码 Agent 上做“真实验证”Playwright 适合放进 CI 里做“自动化测试”。如果你正在做 Agent 工具链建设这两者搭配使用效果比单一方案好得多。7. 实测中的经验教训与下一步扩展想法最后分享几条我在使用 BrowserSkill 过程中的真实心得以及我认为这个项目后续值得继续延伸的方向。7.1 授权粒度比自动化能力更值得调优我刚开始接入时让所有操作都自动放行觉得这样省事。后来发现Agent 偶尔会因为指令理解偏差执行一些意料之外的操作。比如我让它“看一下页面上有哪些按钮”它看完之后顺手把其中一个按钮点了。虽然不是高危操作但也让人一惊。后来我把操作分成三类只读操作放行、表单操作部分确认、危险操作强制确认。这样调优之后Agent 的自主性虽然没之前那么激进但整个流程的容错性好了很多。我自己在使用中总结了一个原则自动化率要服从稳定性稳定压倒一切。7.2 多会话与多账号的支持会越来越重要现在 BrowserSkill 默认只桥接一个浏览器会话但实际工作流里我经常需要同时开两个身份日常开发用一个账号测试环境用另一个账号。下一步我特别希望桥服务能支持多实例通过会话 ID 区分不同的浏览器窗口让 Agent 可以同时操作两个不同身份的登录态。我在本地已经尝试过用 Chrome 的多个 Profile 目录分别装扩展然后为每个 Profile 启动一个独立的桥服务端口再在 Agent 的 Tool 里通过端口号区分会话。这个方法可行但编排起来比较繁琐希望后续项目能把这个能力做成原生功能。7.3 给 Agent 一份“浏览器使用守则”非常有用接入 BrowserSkill 之后我还在 Agent 的系统提示词里加了一段“浏览器操作规范”内容大致包括不要操作地址栏不要点击个人资料相关的链接不要提交任何需要支付的订单遇到验证码立即停止。这段规范可以说救了我不止一次强烈建议所有把 Agent 接到真实浏览器上的人都做这一步。配置好这个方法以后我这边整个工作流的形态变得非常简单顺手Agent 负责写代码、读资料、做决策我负责保持浏览器登录态、处理验证码、守住安全边界。两边配合下来效率提升非常明显而且整个过程都在自己掌控之中不用担心有第三方服务碰到敏感数据。如果你也在折腾编码 Agent并且经常被“登录态”卡住不妨试试搭一座本地桥。我认为 BrowserSkill 给这个方向开了一个好头。