你的 Agent 每次操作浏览器都从零开始——有人造了把钥匙，直接开你正在用的那扇门

104,401 Star。这是 browser-use 在 GitHub 上的数字——AI 浏览器自动化赛道里最亮的那颗星。

但有个问题几乎没人提：**这些工具操作的都是"别人的浏览器"**。

每次启动，Agent 都要重新开一个干净的浏览器实例——重新登录、重新加载、重新定位页面。你已经在 Chrome 里打开的小红书后台、CSDN 编辑器、企业管理系统，Agent 全都看不见。它和你的真实工作环境之间，始终隔着一道墙。

CDP Bridge MCP 就是来拆这道墙的。272 Star，MIT 协议，核心思路一句话：让 Agent 直接操作你正在用的浏览器。

架构：三段桥接，不是重新造浏览器

CDP Bridge MCP 不是又一个浏览器自动化框架。它不启动浏览器，不管理浏览器生命周期，甚至不渲染页面。它只做一件事：桥接。

LLM / Agent
    │ stdio 或 streamable-http
    ▼
CDP Bridge MCP 服务（中间层）
    │ WebSocket / HTTP
    ▼
Chromium 浏览器扩展（你正在用的 Chrome）
    ▼
用户正在浏览的网页

三层架构，每层职责清晰：

• MCP 服务端：接收 Agent 的工具调用，转发给浏览器扩展
• 浏览器扩展：在真实页面中执行操作，遇到 CSP 限制自动降级为 CDP Runtime.evaluate
• Token 隔离：streamable-http 模式下，不同用户用不同 token，服务端按 token 隔离会话空间

这意味着：你已经在 Chrome 里登录的小红书、后台管理系统、客服工作台——Agent 可以直接读取和操作，不需要重新登录，不需要搬 Cookie 到云端。

实测数据：快在哪，慢在哪

项目方做了 V2 对比测评，相同模型、相同任务、相同工具调用循环：

关键发现：CDP Bridge 不是万能的。当任务不需要读取用户当前页面上下文时（比如简单查个标签页），Playwright 反而更快——因为它不需要经过扩展桥接的额外链路。

CDP Bridge 的优势集中在"复用已有上下文"的场景：已经登录的网站、已经加载的页面、已经渲染好的前端内容。这些场景下，Playwright 要重新启动浏览器→登录→导航→等待渲染，CDP Bridge 直接从当前状态开始。

竞品横评：浏览器 Agent 赛道全景

2026 年，"browser harness"已经成为一个独立品类——介于 Agent 框架和云浏览器之间的工具层。Notte 的分类法把赛道划得很清楚：

赛道分三个生态位：

1. 干净浏览器自动化（Playwright MCP、browser-use）：启动独立实例，适合测试和批量任务
2. 云浏览器服务（Stagehand、Browserbase）：托管浏览器，按会话计费，适合生产部署
3. 真实浏览器桥接（CDP Bridge、Webfuse、mcp-chrome）：连接用户正在用的浏览器，适合协作场景

CDP Bridge 在第三个生态位里，目前 Star 最少但思路最清晰。

Token 经济学：省的不只是时间

Playwright MCP 的典型浏览器自动化任务消耗约 114,000 tokens。Playwright CLI（快照存磁盘模式）只需要约 27,000 tokens——省 76%。这是 Microsoft 自己测的数据。

CDP Bridge 的省 token 逻辑不同：它不是减少返回给模型的信息量，而是减少模型需要走的弯路。

Playwright 的典型流程：启动浏览器→导航→等待加载→截图/获取无障碍树→解析→点击→等待→再截图→再解析……每一步都是一次工具调用，每次调用都带完整的页面快照进上下文。

CDP Bridge 的流程：扫描当前页面（browser_scan 已简化 HTML）→执行操作→返回结果。少了启动和导航的步骤，少了等待加载的轮次，自然少了 token。

NumPy 教程场景的 10,315 vs 18,647 tokens 差距，主要来自这里。

10 个工具：够用，但不算多

对比 Playwright MCP 的 23 个工具，CDP Bridge 的工具集偏精简。没有 click、type、fill 这些高级交互工具——需要交互时，得用 browser_execute_js 手写选择器和事件触发。这对 Agent 的 JS 能力有要求，也意味着更难调试。

代价清醒

源文章是项目方自述。三黄工作室就是 CDP Bridge MCP 的开发团队。源文章的测评数据来自"单次示例运行"，不是多轮统计检验。56% 的耗时节省和 45% 的 token 节省，是特定场景下的单次结果，不是普遍结论。源文章末尾也承认了这一点。

Token 爆炸是已知问题。Issue #6 标题就是"Token 爆炸啦"。browser_scan 返回的简化 HTML 在复杂页面上仍然可能很大——一个电商首页的简化 DOM 轻松超过 50K 字符。如果 Agent 需要多次 scan 同一页面，token 消耗会快速累积。

CSP 限制是硬伤。Issue #11 报告进入 Google Stadia（现 stich）会被拦截。虽然扩展有 CDP Runtime.evaluate 降级机制，但不是所有 CSP 策略都能绕过。金融、医疗等高安全网站的 CSP 通常更严格。

安全模型需要信任。CDP Bridge 让 Agent 操作你正在用的真实浏览器——这意味着操作你的真实账号。如果 Agent 误操作（点错按钮、提交错误表单、删除数据），后果是真实的，不是沙箱里的。源文章提到"执行有风险的动作前等待确认"，但这依赖 Agent 的判断力，不是技术硬保障。

巴士因子 ≈ 2。Unagi-cq 贡献 54 次，FlowerBirds 贡献 5 次，idonecc 贡献 1 次。核心开发高度集中。

**Playwright 1.59 的 browser.bind()**。Playwright 最新版本已经支持会话共享——任何 MCP 服务器都可以通过 browser.bind() 与测试脚本共享浏览器会话。这模糊了"独立浏览器"和"真实浏览器"的边界，CDP Bridge 的差异化优势可能被侵蚀。

选型决策

不是"Playwright 退休"，是选哪把钥匙开哪扇门：

工具没有绝对优劣，关键在于你的 Agent 到底要操作哪个浏览器——一个干净的测试实例，还是你正在用的那个。

GitHub 地址：https://github.com/Unagi-cq/cdp-bridge-mcp