浏览器自动化

为什么我一开始死磕“本地模式”却连浏览器都打不开？ 上周三下午三点十七分，我盯着 VS Code 里第 17 次报错的终端窗口，手边咖啡凉透，心里只剩一个念头：这破 puppeteer-core 怎么连 localhost 都连不上？ Error: net::ERR_CONNECTION_REFUSED at http://localhost:9222/json at navigate (/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Frame.js:138:25) 我翻遍 Puppeteer 文档、Chrome 启动参数、Docker 网络配置，甚至重装了 Chromium……直到凌晨一点，偶然在 Claude Code 的 MCP 插件设置页底部发现一行小字： ⚠️ MCP Server 默认禁用本地进程 spawn（出于安全策略），需手动启用 mcp.allowLocalProcess=true ——原来不是 Chrome 没起来，是 MCP 根本没让它起！puppeteer-core 在等一个永远不会出现的调试端口。 那一刻我顿悟：MCP 的三种模式，根本不是“技术选型”，而是权限与上下文的分层契约。 “谁在调”？是 IDE 插件、CI 脚本，还是用户点击的按钮？ “在哪调”？是开发机、K8s Pod，还是客户浏览器里的 Web Worker？ “以谁的身份调”？是 root、普通用户、还是被 seccomp 锁死的 sandbox 用户？ 这才是真正的设计原点。 下面这张对比表，是我贴在工位显示器边框上的速查便签（手写体，带咖啡渍）： 场景 推荐模式 关键约束 我的便签原文 调试前端组件（如 Storybook 快照） ✅ 本地模式 仅限本机，无网络访问权 本地=快但受限 批量爬取公开电商页面（含 JS 渲染） ✅ 远程模式 需自维 Grid/Selenium，证书自己管 远程=自由但要管证书 渲染用户上传的 HTML 报表模板 ✅ 沙箱模式 DOM 可操作，但 fetch/open/print 全受白名单控制 沙箱=安全但没 DOM 操作权 ...

引言：为什么“AI接管浏览器”不再是科幻命题？ 过去十年，浏览器自动化始终困在一条狭窄的路径上：Selenium 写 XPath，Puppeteer 注入 document.querySelector，Playwright 等待 page.waitForSelector('.loading:visible')……这些工具强大却疲惫——它们不理解“登录”，只认识“点击按钮#login-btn”；它们无法应对验证码刷新后 DOM ID 变更，更难以从一个弹窗跳转、一次 token 重定向、一段动态渲染的 React 列表中自主恢复流程。我们投入大量人力维护脚本：当京东把 .btn-login 改为 [data-qa="auth-submit"]，当 Cloudflare 更新挑战 JS 版本，当 Vue 页面用 <Suspense> 延迟加载关键数据——自动化就集体“失明”。 这暴露了传统方案的三大结构性瓶颈： 🔹 人类脚本维护成本高：每处 UI 变更都需人工定位、重写选择器、更新等待逻辑； 🔹 语义理解弱：无法将“输入手机号并获取验证码”映射到真实页面中的输入框+按钮组合，依赖硬编码定位； 🔹 异常恢复差：遇到网络抖动、MFA 弹窗、403 重定向等非预期状态，多数脚本直接抛出 TimeoutError 或静默失败。 而 Claude Code 的出现，标志着范式跃迁：它不再执行“指令”，而是追求“目标”。当你输入 “帮我登录知乎，进入我的收藏夹，截图前3条含‘大模型’关键词的回答，并记录页面加载性能”，Claude Code 不解析为 7 行 Puppeteer 代码，而是启动一个闭环推理系统——理解“知乎登录”在视觉与 DOM 中的多模态表征，推断当前处于哪一认证阶段，动态生成动作序列，并在环境变化时自主降级或重试。 这种转变的背后，是三项关键技术的协同突破： ✅ 多模态推理：联合处理网页截图（视觉token）与 DOM 树结构（语义token）； ✅ 浏览器 DOM 语义理解：将 <button class="LoginButton">登录</button> 映射为向量空间中与“用户认证入口”高度对齐的节点； ✅ 运行时环境感知：实时监听 mutationObserver、performance.navigation、beforeunload 等事件流，构建动态上下文图谱。 下表对比了四类典型任务中，传统方案与 Claude Code 的实测表现（基于 500 次跨站点重复测试）： ...

🌟 为什么我决定扔掉 Selenium？——一个被 selector 失败、隐式等待和 CI 崩溃折磨三年的自白 凌晨2:47，手机震了第七次。 钉钉弹出告警：“【大促价格监控】任务 #JD-HEADPHONES-03 —— FAILED（StaleElementReferenceException）”。我抓了把头发，盯着终端里那行熟悉的红字：Message: stale element reference: element is not attached to the page document。再往下翻，是另一个幽灵：TimeoutException: Message: timeout: Timed out receiving message from renderer。 这不是演习。这是双十一大促前夜的真实战况。我们用 Selenium 写的 12 个核心电商页面价格巡检脚本，在 Chrome v125 升级后的首波流量高峰中集体“诈尸”——不是全挂，而是间歇性抽风：有时能跑通，有时卡在搜索框输入后不点搜索按钮，有时点了却把“加入购物车”误点成页脚的“联系我们”。排查三天，发现根源竟是：某平台首页悄悄把 <button class="btn-buy"> 改成了 <div class="action-btn js-buy-btn">，而我们的 WebDriverWait(driver, 10).until(EC.element_to_be_clickable((By.CLASS_NAME, "btn-buy"))) 直接哑火。 不是 Selenium 不好。它稳、成熟、生态全。但我的需求变了。老板甩来一句话：“帮我点开京东首页→搜‘无线耳机’→拉到第3个商品→截图价格”，我却要花 42 行代码： 启动 ChromeOptions 加一堆规避检测参数 等首页加载完再等搜索框可点击 输入后显式等搜索按钮出现再 click 解析商品列表时得用 XPath 定位“第3个含‘自营’且非广告”的节点 滚动到该元素再截图…… 直到公司内部 Hackathon 上，隔壁组小哥用 Claude Code + Chrome MCP，10 分钟做完同一件事。更魔幻的是——产品同学现场语音说：“把刚才脚本改成去小红书搜‘降噪耳机测评’，只取笔记标题和点赞数”，他敲了三行指令，回车，跑通。页面结构早因灰度改版变了个样，但脚本没崩，因为 LLM 理解了“标题”和“点赞数”的语义，而不是死磕 class="note-title"。那一刻我关掉了 PyCharm，打开了终端。 ...