Agent 卡在登录态？腾讯开源 BrowserSkill：借用你已登录的浏览器
大家好，我是珂抖屁。
一人公司用 Agent 干活，最常见的卡点不是「模型不够聪明」，而是——
它进不去你已经登录好的后台。
云文档、管理后台、带 SSO 的内部系统、要扫码的控制台……你人在浏览器里一切正常；Agent 一上手，要么是空白浏览器，要么是过期 cookie，要么卡在验证码。于是你开始复制粘贴、开始截图口述、开始怀疑「自动化是不是不适合真实工作」。
腾讯开源的 BrowserSkill（GitHub：Tencent/BrowserSkill，中文说明见仓库 README.zh-CN）盯的就是这层摩擦：多数工具给你一个干净浏览器；它选择借用你已登录浏览器里的标签页。登录态已经在；验证码和确认可以弹回给人；入口是 CLI（bsk），不是又一个 MCP 服务器绑死某一家。
下面按工作流拆解：它解决什么、和无头浏览器 / 普通浏览器 MCP 差在哪、一人公司哪些场景值得装、边界怎么守。
先把问题说清楚：Agent 卡的是「身份」，不是「点击」
自动化教程喜欢教：打开页面 → 填表 → 点按钮。真实工作里，第一步常常就已经挂了——你没有第二个「全权限测试号」，也不想把主账号密码写进 Agent 配置。
于是出现三种凑合：
•让 Agent 在无头浏览器里从头登录（验证码、二次验证、风控，直接劝退）
•导出 cookie / 复制请求头（脆、危险、过期快）
•人肉操作，Agent 只负责写总结（自动化名存实亡）
BrowserSkill 的路径不同：你的登录态留在日常浏览器里；Agent 通过本机桥接，在需要时显式借用某个标签；用完归还；其余窗口尽量不打扰你继续干活。
BrowserSkill 是什么（人话版）
按官方叙事，它是 Agent 运行时和浏览器之间的本地桥接层：
•一边是 Cursor、Claude Code、Codex、Pi 等能调 Shell 的 Agent
•中间是 bsk CLI + 本机 daemon
•另一边是浏览器扩展（Chrome / Edge 等 Chromium 系）
Agent 不直接「接管你的整台浏览器」。它发的是 bsk … 命令；daemon 转到扩展；扩展在独立的 Agent Window 里执行。需要动你已经打开的标签时，必须走借用；遇到验证码、登录、确认弹窗，可以请求你接管——这就是内置的 human-in-the-loop。
许可证是 MIT，组件本地跑。装法官方推荐「一句话让 Agent 按 AGENT_INSTALL.md 安装」，也可以手动：curl …/install.sh | sh 装 CLI，再装商店扩展，然后 bsk install-skill 把 skill 装进你的 harness。
验证用 bsk doctor。版本上 CLI 与扩展尽量对齐；长截图一类能力对版本匹配更敏感。
和「无头浏览器 / 普通 MCP」差在哪
我自己用一张对照表记：
无头 / 干净浏览器自动化
强项：可重复、好放 CI
代价：没有你的登录态；验证码与风控敌对
适合：公开页、测试环境、有专用测试号
浏览器 MCP（常见形态）
强项：和某 Agent 产品集成深
代价：常绑特定协议与运行时；未必复用你日常已登录的 profile
适合：产品生态内一键开箱
BrowserSkill（CLI 桥接 + 扩展）
强项：复用真实登录态；不绑死单一 Agent；确认与求助可回给人
代价：本机要装 CLI + 扩展；权限与隐私边界要你自己守
适合：一人公司真实后台、SSO、必须人审的卡点
关键句：它是 CLI，不是 MCP。 只要 Agent 能跑 Shell，就能接；Cursor / Claude Code / Codex / Pi 等都在官方点名支持里。你不必先加入某一家的 MCP 市场，才有资格操作浏览器。
一人公司：哪些场景值得立刻试
我按「值不值得装」排序：
1. 已登录后台的只读巡检 例如：打开控制台看用量、导出昨天账单页、核对工单状态。人不用把密码交给模型，只要在借用确认里点头。
2. SSO / 企业门户里的重复点击 真·痛苦来源。测试号申请慢，主号又不能随意填进自动化配置。借用已登录 tab，比「再做一套 RPA 账号体系」现实。
3. 必须人审的卡点 支付确认、权限变更、删除、对外发送——让 Agent 跑到弹窗前，request-help 把控制权交还你。人点完，Agent 再继续。这比「全自动到出事」健康。
4. 长页截图与现场留证 官方支持会话内长截图（注意超时与版本）。一人公司写复盘、交差、存证时，比一截一截拼图省事。
不适合当银弹的：纯 CI 里无界面环境、完全无人值守且你还关了所有确认、以及任何你不愿意让本机 Agent 看见的页面。
安装与借用：最小可用路径
官方推荐给 Agent 的一句话（以仓库为准）：
按照 https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md 的说明，在本机安装并配置 browser-skill手动时记住四步：装 bsk → 装浏览器扩展 → bsk install-skill → bsk doctor。
第一次真用，先做最小验证：让 Agent 打开公开页并总结，再试借用一个低风险已登录页。不要一上来就把网银、主邮箱、生产删除页借出去。
边界：隐私、确认开关、别乱关
官方从 0.3.0 起把关键策略收束到扩展里的设置（以你浏览器里保存的为准），大致是两件事：
•借用标签页前确认
•允许请求人工协助
两边都开：最稳，适合日常。关掉借用确认：Agent 少打断你，但也更接近「它能静默借走 tab」。关掉人工协助：遇到验证码可能直接返回 disabled，技能会引导模型改走「观察已有页面、在授权内尽力」，而不是假装你已经点过。
我的建议很朴素：
•默认两开关都开
•无人值守只放在你明确接受风险的机器与账号 profile
•不要用过时的 --unattended / tab borrow --no-confirm 幻想「能覆盖插件开关」——新版本里它们不能压过你在扩展里的选择
•客户数据页、支付页、权限后台：能不借就不借；要借就留操作日志与人工确认
另外：本机 daemon、扩展、Agent 同机，意味着浏览器里你能看到的，桥接层在授权后也可能看到。这不是云端神秘上传的借口，而是提醒你——权限模型是「本机可信 Agent」，不是「把密码贴进提示词」。
和「我自己点」怎么分工（现场口径）
一人公司最怕两种极端：要么全手动，Agent 只聊天；要么全自动，出事了才知道。
我现在的分工更像这样：
•Agent 负责：导航到已授权页面、读取可见信息、整理表格、起草下一步操作清单、长截图留证
•人负责：借用确认、验证码、支付/删除/权限变更、对外发送前的最后一眼
•明确不交给 Agent：主密码输入、生产环境不可逆操作、客户明文密钥的复制粘贴到不可控上下文
如果你用的是 Cursor / Claude Code / Codex / Pi，装好 skill 之后，优先用「打开公开页 → 总结」验证链路，再升级到「借用一个低风险已登录 tab」。链路通了，再谈复杂工作流。沙盒会杀后台进程的 Agent，要按官方 sandboxed-agents.md 在宿主侧保活 daemon——这点不事先看，会表现为「doctor 偶发挂、扩展连不上」。
写在最后
Agent 时代，一人公司缺的往往不是又一个「能点按钮的模型」，而是能安全地站在你已有登录态旁边干活的桥。
BrowserSkill 的取舍很清楚：不给你假的空白世界，而是借用真实浏览器；不绑死 MCP 一家，而是 CLI；不把验证码硬刚到底，而是可以弹回给人。
若你最近也在被「请先登录」反复打断，今晚不必先上复杂多智能体。先装扩展与 bsk，跑通一次 doctor，再用一个低风险已登录页试借用。
登录态在你这边，确认开关也在你这边——这才像能长期用的工作流。
（依据：Tencent/BrowserSkill 仓库与 README.zh-CN；安装与开关以官方文档当前版本为准。）
延伸阅读
Tencent/BrowserSkill · https://github.com/Tencent/BrowserSkill