Chrome 扩展浏览器自动化

问题：为什么 AI 代理不该再开一个浏览器

大多数浏览器自动化方案会启动独立的 Chromium 实例，用模拟点击、填表、截图的方式完成任务。但这带来两个具体痛点：

• 登录态无法复用：自动化浏览器没有 SSO 会话、没有已保存的密码，遇到企业内网或需要二次验证的站点只能卡住
• 数据与上下文割裂：书签、历史记录、已打开的标签页都留在真实浏览器里，代理拿不到

当 Agent 需要操作真实环境——比如处理工单系统的待办，或从内部工具拉数据——重开一个浏览器往往意味着重新认证一遍，或者干脆做不到。

工作原理

Chrome MCP Server 的思路是不另起炉灶：通过 Chrome 扩展与本地桥接（local bridge），把日常使用的浏览器直接暴露给 MCP 兼容的代理。

核心能力：

• 真实标签页复用：代理操作的就是你当前打开的标签页，不需要 --headless 或新开窗口
• 登录状态继承：复用 Chrome 中已有的 Cookie 与 session，SSO 一次登录长期有效
• 浏览器数据访问：历史记录、书签、下载目录都可通过本地桥接读取
• 原生 Chrome API：直接调用浏览器自身的能力，而非模拟 DOM 操作

关键步骤：

1. 本地运行桥接服务，连接 Chrome 扩展
2. 扩展将浏览器状态与 API 注册为 MCP 工具
3. 代理通过标准 MCP 协议调用这些工具，直接作用于真实浏览器

适用边界与注意点

• 需要 Node.js ≥ 20，以及 Chrome/Chromium 浏览器与对应扩展
• 敏感工作流前必须审查上游源码：此技能基于源代码分发，无法自动提取安装说明，使用前请仔细阅读仓库
• 它解决的是「复用现有浏览器」的问题，不是通用自动化编排器；如果场景不需要真实登录态，传统 Playwright/Puppeteer 方案可能更轻量
• 上游项目：https://github.com/1991513ccie-png/skills