my-agent-browser开源：给Agent一个不抽风的浏览器

又一个解决「Agent操作浏览器」痛点的方案，这次走的是包装路线

6月22日前后，一个名叫 my-agent-browser 的项目在 linux.do 社区放出，作者是国内开发者 briqt。定位很直接——不重新造轮子，而是在 Google 官方的 chrome-devtools-mcp 之上做了一层增强包装，做成 MCP + Skill 的组合形式，专门解决多 Agent 并存时浏览器实例的混乱问题。

这事不大，但戳中了一个非常具体的痛点：你同时在用 Claude Code、Codex，再加上自研的 Hermes，每个 Agent 都想开自己的浏览器，结果就是端口冲突、cookie 各自为政、登录态反复失效，调试时屏幕上飘着三四个 Chrome 窗口，分不清哪个属于哪个进程。这是任何一个深度用 Agent 的人都会遇到的场景。

为什么作者不直接用现有方案

作者在帖子里把现状盘了一遍，结论是「没有一个完美满足需求」。我们顺着这个思路看：

• Agent 自带浏览器能力：每家实现都不一样，Claude Code、Codex、Cursor 各有各的私有协议，没法横向复用 session 和数据目录。
• chrome-devtools-mcp：Google 官方出品，能力够，但它本质是个原始 MCP server，没有进程管理，崩了就崩了，更不会自动复用现有 Chrome。
• Playwright CLI：偏自动化测试场景，每次起一个全新 profile，指纹和正常用户差异巨大，反爬机制一抓一个准。
• 云端浏览器（Browserbase、Browserless、agent-browser 之类）：Vercel Labs 那个 agent-browser 现在 star 已经 3.6 万了，路线确实漂亮——Rust CLI + 结构化快照 + 无头运行，但它跑在云端或者无头模式，看不到界面、用不了你日常浏览器的登录态，对国内开发者来说还有网络层的麻烦。

作者要的是另一个组合：数据目录持久化 + 能看到 UI + 浏览器指纹和日常浏览器几乎一致 + 所有 Agent 共享同一个实例。这四条同时满足的方案，市面上确实没有。

它做了什么

核心逻辑只有一句话：复用你本地那个真实的 Chrome，所有 Agent 都接到同一个实例上。

相对于裸跑的 chrome-devtools-mcp，my-agent-browser 干了这么几件事：

1. 浏览器实例自动发现

这是最关键的设计。Agent 调用工具时，它不会粗暴地 spawn 一个新 Chrome，而是先扫一遍系统里现有的浏览器进程，看看有没有开着 --remote-debugging-port 的实例。有就接上去，没有就按配置启动一个。这样三个 Agent 同时启动，它们看到的是同一个 Chrome、同一组 tab、同一份登录态。

这个设计对调试体验的提升是颠覆性的。以前你想看看 Agent 现在卡在哪个页面，得截图、得 dump DOM；现在直接切到那个 Chrome 窗口，眼睛看就行了。

2. 进程生命周期管理与崩溃恢复

chrome-devtools-mcp 的一个老问题是：DevTools 协议连接断了就完了，Agent 那边只会拿到一堆超时报错，根本不知道该怎么恢复。my-agent-browser 在中间层做了状态机，监测到连接断开、Chrome 进程退出、tab 崩溃这些情况会自动尝试重连或重启，并把发生了什么以 Agent 能理解的语言反馈回去——比如「目标 tab 已崩溃，已在新 tab 重开，请重试操作」，而不是抛一个 ECONNRESET。

对 Agent 的容错链路来说，把异常翻译成可决策的自然语言提示，比给它一个 stack trace 重要得多。

3. 配置驱动的反爬指纹降低

这条比较克制——作者用的词是「降低」，而不是「绕过」。本质是因为接的就是你日常浏览器实例，UA、字体、插件、WebGL fingerprint 全是真实的，加上持久化的 cookie 和 localStorage，识别难度比 Playwright 那种「全新 profile + 自动化标志位」的环境低一个量级。这里没有什么黑科技，单纯是路径选对了。

4. 面向 Agent 的使用提示

这是 Skill 部分的价值。安装后 Agent 不是直接拿到一组工具就开干，而是先读 SKILL.md，了解「我现在面对的是一个可能已经登录、有历史 tab 的真实浏览器，操作前应该先 list tabs」这种上下文。等于把 prompt engineering 的活儿前置到工具层做掉了。

安装和接入

一行命令：

npx skills add briqt/my-agent-browser -g -y

装完之后，让你的 Agent 读 skill 即可：

阅读 my-agent-browser skill 并引导我完成配置

Agent 会按 SKILL.md 的描述自动完成 MCP 注册和配置。这种把「让 Agent 读说明书」当成标准接入流程的做法，是过去半年才慢慢成型的范式——比手写 mcp 配置 json 的体验好不少。

和 Vercel 的 agent-browser 横向看一眼

名字撞了一半，但路线完全不同。

| 维度 | my-agent-browser | agent-browser (Vercel) | | --- | --- | --- | | 底层 | chrome-devtools-mcp 包装 | 自研 Rust CLI + Chrome | | 运行环境 | 本地真实 Chrome 实例 | 独立 Chrome 进程，可云端 | | UI 可见性 | 有界面，可肉眼调试 | 偏 headless | | 多 Agent 共享 | 是核心卖点 | 不是设计目标 | | 输出格式 | 沿用 chrome-devtools-mcp 原生能力 | 结构化 snapshot + ref，token 优化 | | 用户画像 | 国内重度 Agent 用户、需要持久登录态 | 团队/平台场景、批量自动化 |

Vercel 那套更像是为 SaaS 形态的 Agent 平台准备的基础设施，强调 token 效率和确定性；briqt 这个则是单兵作战时的瑞士军刀，把日常浏览器变成 Agent 的延伸。两个方向都对，看你处于哪个场景。

一点判断

这类「在已有 MCP 上做包装」的项目今年会越来越多。chrome-devtools-mcp、playwright-mcp、filesystem-mcp 这些官方 server 提供的是最小可用能力，但离生产可用还差一截——少的就是进程管理、状态恢复、上下文引导这些「胶水活」。

my-agent-browser 的价值在于它把这些胶水活做扎实了，而且选了一个聪明的切入点：复用真实浏览器。这件事在云端方案盛行的当下反而稀缺。云浏览器在企业级场景有它的道理，但作为个人开发者，你的 GitHub 登录、Notion session、各种内网系统的认证状态，没人愿意为了「让 Agent 操作」就在云端浏览器里全部重新登一遍。

不足也有：项目高度依赖 chrome-devtools-mcp 上游，CDP 协议变动会传导下来；目前主要在作者自己的 Hermes、Claude Code、Codex 上验证过，更冷门的 Agent 兼容性还得跑一跑。但对于「我就想让 Claude Code 操作我自己的浏览器」这个最普遍的需求，它的成熟度已经够日常使用。

顺带提一句，OpenAI Hub 这边一个 Key 就能跑 Claude、GPT、Gemini、DeepSeek 全家桶，配合 my-agent-browser 这种本地 Agent 工具链，搭一套带浏览器能力的多模型工作流的门槛比一年前低了不止一个数量级。

参考来源

• my-agent-browser 项目首发帖（linux.do） — 作者 briqt 在 linux.do 社区发布的项目介绍与开源声明
• vercel-labs/agent-browser（GitHub） — Vercel Labs 出品的另一条路线方案，可对照阅读
• Github Weekly 第九期：AI Agent 与效率工具精选（知乎） — 对 agent-browser 设计思路的中文解析