browser-login-reuselisted

# 浏览器自动化登录态复用（playwright-core + storageState） ## 路由原则（v2.1 新增，先选通道再动手） 「让 AI 操作浏览器」不是一个能力，是「宿主 × 通道」的组合。触发本 skill 后，先按三层路由选通道，**不要默认开浏览器**： 1. **第一层 · 绕开**：任务能走 API/CLI 就不开浏览器。两次实证：站点部署从「浏览器上传」改 `wrangler deploy` 后，浏览器环节整体消失；云服务商绝大多数控制台操作都有对应 CLI/API。先问一句「这事有没有官方命令行」，能省掉登录态这一整个问题域。 2. **第二层 · 借力**：执行环境自带内置浏览器且能导入本机已登录会话的（如 Zcode 内置浏览器，2026-09-01 实证免密回登 Cloudflare 控制台，据其操作记录转引），浏览器任务优先派给该宿主执行——登录态零成本。注意会话存储不跨宿主互通，任务须在该宿主的会话内完成。 3. **第三层 · 兜底**：都没有、或需要脚本化批量抓取/检测的 → 用本 skill（playwright-core + storageState）。登录环节需要用户本人输密码/2FA 的一律回退人工（安全红线）。 ## 何时触发 - 用户需要 AI 操作**需要登录**的网站（控制台查额度、面板配置、表单提交、文件上传等） - 用户明确要求"登录一次之后别反复登录""复用登录态""AI 帮我操作网页" - 用户想让 AI 完成原本需要手动操作浏览器的事务性任务 **不适用的场景**（先判断再动手）： - 只需读静态页面 → 用 WebFetch 更轻 - 调用 API → 用 curl 更直接 - 执行环境有内置浏览器且已导入登录会话 → 直接在该宿主内做，不用本 skill（见上方路由原则第二层） - 支付/银行/资金类站点 → 不交给 AI 会话（安全红线） ## 核心事实（2026-08-11 + 2026-08-15 实测） ### 工具 - **playwright-core**（Node 库，比 playwright-cli 更灵活，支持 storageState API）→ `npm install playwright-core` - **playwright-cli**（CLI 工具，适合简单交互；不支持 storageState）→ `npm install -g @playwright/cli@latest` - **agent-browser**（vercel-labs，评估后不采用）→ 通用浏览器自动化 CLI（daemon 模式）；headed 登录可用但**无 storageState 导出/注入 API**，跨会话复用登录态仍需 playwright-core。已从环境移除（2026-08-15），仅留决策记录 - 均依赖 Node 18+ 和浏览器二进制 - **宿主内置浏览器**（如 Zcode，可导入本机已登录会话）→ 登录态获取成本最低的通道，但会话存储不跨宿主互通；本 skill 与其互不替代，按路由原则分流 ### ⚠️ 结论适用域（2026-09-01 增补） 「headed 窗口登录场景不可用」等历史结论，验证环境均为 **Bash 沙箱类宿主（WorkBuddy）+ 脚本方案**，**不是普适结论**。换宿主（内置浏览器/桌面辅助功能通道）或换通道后需重新评估，不要直接套用本文件结论否定其他方案。 ### 两层方案（202