让 AI 借你已登录的浏览器一用：Tencent/BrowserSkill 初探 🌐🤖

先说一个几乎所有做过浏览器自动化的人都踩过的坑：你写了一段脚本，让 AI 帮你去某个后台系统查个数据、点个按钮、导个报表。脚本跑起来了，浏览器也打开了——然后停在了登录页。

于是你开始折腾：Cookie 怎么导、扫码怎么绕、二次验证怎么办、会话过期了怎么续。折腾两小时，脚本本身写了十分钟。更别提那些"只有你本人登录才看得到"的页面——内网系统、付费后台、需要实名的服务。对 AI 来说，那道登录墙比任何反爬策略都高。

今天 GitHub Trending 上出现了腾讯开源的 Tencent/BrowserSkill，它的项目描述只有一句话，却正好戳在这个痛点上：

Let AI agents use your real, logged-in browser without interrupting your work. CLI + extension for browser automation across any shell-capable AI agent.

翻译成人话就是：别让 AI 自己从头开一个浏览器了，让它直接借用你那个已经登录好的浏览器——而且不能打断你正在做的事。

过去两年，浏览器自动化的主流思路是"给 Agent 一个干净的浏览器"：独立的 Profile、独立的进程、独立的生命周期。好处是隔离、可控、可复现；代价是——它是"新来的"，没有任何历史沉淀，没有登录态，没有你攒了三年的书签和设置。

而人类使用浏览器的方式恰恰相反：我们所有的能力，都挂在那一个"已经登录、已经授权、已经养熟"的浏览器实例上。

BrowserSkill 的思路是对这个默认假设的一次翻转：与其让 AI 复制一个你，不如让 AI 成为你的手。真实浏览器 + 真实登录态 + 真实权限，Agent 只负责决策和操作。

🔍 第一眼：CLI + 扩展，被拆成两半的设计

项目描述里的关键词是 CLI + extension。这两个词放在一起，其实已经把架构的大方向说清楚了：

扩展（extension）：跑在浏览器侧。它是唯一能"合法"待在真实浏览器里的组件，负责和你已经登录的那个实例打交道。
CLI：跑在 shell 侧。它是 Agent 能触达的入口，把"我想点这个按钮"翻译成浏览器能理解的动作。

这个拆法的妙处在于职责边界干净。CLI 不需要知道 Cookie 存在哪、会话怎么维持；扩展不需要知道这次操作是来自 DeepSeek、Claude Code 还是你自己写的小脚本。两边通过一个稳定的接口对话，谁换了都不影响对方。

至于两者之间具体用什么协议通信、扩展支持哪些浏览器、动作集覆盖到什么粒度——这些属于实现细节，建议直接翻仓库的 README 和文档，别靠猜。（顺便说，这也是看开源项目的正确姿势：描述告诉你它想成为什么，代码才告诉你它现在是什么。）

⚡ 为什么是 CLI，而不是又一个 MCP Server

这是我觉得整个项目最值得玩味的一句话：across any shell-capable AI agent。

2026 年做 Agent 工具，默认答案往往是"写个 MCP Server"。MCP 确实优雅，但它有一个隐含前提：你的 Agent 得支持 MCP，你得配置、得装依赖、得处理版本兼容。而 BrowserSkill 选了更古老、也更普适的接口——命令行。

只要一个 Agent 能执行 shell 命令，它就能用这个工具。没有 SDK，没有绑定，没有"仅支持某几家模型"。你可以把它接进一个纯 bash 的定时任务，也可以让一个跑在终端里的编码 Agent 顺手打开某个后台页面填张表。


# 概念示意（伪代码，非真实 API，具体用法请以仓库文档为准）
# 传统做法：新建一个干净的无头浏览器
#   → 站在登录页门口，什么都做不了

# BrowserSkill 的做法：指挥你那个已经登录的浏览器
def run_task(task):
    # 1. Agent 在 shell 里调用 CLI
    # 2. CLI 把意图传给浏览器里的扩展
    # 3. 扩展在你的真实会话中执行动作
    # 4. 结果原路返回给 Agent
    return result

用 CLI 做 Agent 工具接口，还有个被低估的好处：可调试。你可以自己在终端里敲一遍，看看它到底干了什么；可以把它串进管道，和 grep、jq 一起用；出问题的时候，你能一眼看出是 Agent 决策错了，还是工具执行错了。相比之下，一个躲在协议层后面的黑盒要难排查得多。

🙅 "不打断你的工作"这五个字有多重要

我一开始以为 without interrupting your work 只是营销话术，想了一下发现它是产品层面的硬约束。

想象一下：你正在读一份文档，或者正在开视频会议共享屏幕，Agent 突然在你的浏览器窗口里疯狂开标签页、跳转、输入。这体验是灾难性的——你既失去了对浏览器的控制，也失去了对隐私边界的信心。

"不打断"意味着一个很具体的工程目标：Agent 的操作必须和你的注意力共存而不冲突。它可能需要一个独立的标签页或窗口，需要不抢焦点，需要在结束时干净地收场，不给你留下一地鸡毛。

这一点也解释了为什么必须走"扩展 + 真实浏览器"这条路。一个独立的自动化进程天生就是不打扰的，但它也没有登录态；只有一个寄居在你浏览器里的组件，才既拥有你的会话，又能被要求"安静一点"。

顺带一句，这也是安全模型上的一次取舍。真实浏览器意味着真实权限——Agent 拿到的是你本人能做的所有事。所以务实地看：把它用在那些你愿意授权的场景，别在装着一堆敏感会话的浏览器上做无边界实验。

🎯 谁该现在就去看一眼

做企业内部自动化的同学：那些有 SSO、有二次验证、有权限分级的后台系统，最吃这套方案。
终端派 Agent 用户：如果你的工具链是"能跑 shell 就行"，那你不需要等任何生态适配，今天就能接。
被 Cookie 导出折磨过的人：所有想把"我的浏览器"变成"AI 的手"的人。

反过来，如果你的需求是"跑一万次的大规模抓取"，那独立 Profile 的无头方案大概仍然更合适——真实浏览器是给"需要我来在场"的场景准备的。

🌟 小结

BrowserSkill 打动我的地方不在于它做了多少功能，而在于它换了一个提问方式。大家都在问"怎么让 AI 拥有一个浏览器"，它问的是"怎么让 AI 用上我的浏览器"。

再加上 CLI 这个接口选择——不与任何 Agent 生态绑定，谁有 shell 谁能用——整个项目的定位就变得非常克制也非常锋利：不做平台，做一块谁都能插的积木。

项目地址放这里，感兴趣的话直接去看 README：Tencent/BrowserSkill。真正的细节在代码里，不在任何一篇博客里——包括这一篇。😉