狸想岛 · AI 实战学习社区

🎯 学 gstack 的 Chrome 浏览器管理：不是手动打开 Chrome 然后登录各个网站，而是自动启动绑定了你的 profile 的 Chrome 实例——保存的密码、Cookie、扩展都在——让自动化能"以你的身份"访问需要登录的页面。 ⏱️ 预计时间：15 分钟

💡 新手提示：无头浏览器是"隐身模式的新窗口"，每次都是全新状态；专用浏览器是"你自己的浏览器"，带着你的登录状态和 Cookie。需要登录才能访问的页面（如后台系统）必须用后者。

[!quote]- 📖 原Skill精要 技能名称：open-gstack-browser 核心功能：启动 GStack 浏览器——AI 控制的 Chromium，内嵌侧边栏扩展。打开可见浏览器窗口，实时观察每个操作。侧边栏显示活动流和聊天。内置反机器人隐身。以真实用户身份（含保存的密码、Cookie、扩展）访问需要登录的页面。 所属体系：gstack 虚拟工程团队 协作关系：为 [[L6-37-浏览器自动化|browse]] 无头模式提供"可见"替代方案，适合需要登录状态的操作

§1 课程概览

open-gstack-browser 是 gstack 的 AI 控制可见浏览器。它与 browse（无头 Playwright）的核心区别：open-gstack-browser 绑定你的专用 Chrome profile——携带保存的密码、Cookie 和扩展——可以访问需要登录的 SaaS 后台和管理面板。无头浏览器的认证困境（每次都是全新 session，无法访问认证页面）通过专用 profile 和 setup-browser-cookies 两种方案解决。Sidebar 集成了三个面板（Terminal/AI 交互 + Inspector/CSS 审查 + Activity/操作审计），通过 WebSocket 与 Agent 双向实时通信。约 100ms/命令。

[!tip] 白话小课堂无头浏览器是"隐身模式的新窗口"，每次都是白纸一张——没有登录状态、没有 Cookie、没有密码。专用浏览器是你的"自己的 Chrome"，带着你所有的登录状态、保存的密码、浏览器扩展。关键区别：访问需要登录的后台系统用专用浏览器（或 setup-browser-cookies 注入 Cookie 后用 $B），自动化测试公开页面用无头浏览器。最有意思的是 Sidebar——在浏览器侧边栏里嵌入一个 AI 终端，你能看到 AI 在浏览器里的每一步操作：导航到哪了、点了什么按钮、截了什么图，全都有审计记录。这节课教你如何启动 AI 控制的浏览器，并理解它与无头浏览器的协作关系。

§2 为什么需要专用浏览器？——无头浏览器的认证困境

无头浏览器 vs 真实浏览器

特性	无头浏览器 ($B / Playwright)	真实浏览器 (open-gstack-browser)
登录状态	无（全新 session）	有（专用 Chrome profile）
Cookie	无	自动加载保存的 Cookie
保存的密码	无	自动填充
浏览器扩展	无	加载专用 profile 的扩展
认证页面	无法访问	可以访问（SaaS 后台、管理面板）
适用场景	公开页面、自动化测试	需要登录的操作、人工交互场景
窗口	不可见	可见（方便观察和审计）

open-gstack-browser 的核心能力

启动 Chrome/Chromium 实例
使用专用 profile（与日常浏览器隔离——双向保护）
自动导航到指定 URL（可选）
支持 MCP（Model Context Protocol）集成
SIDEBAR 扩展——在浏览器侧边栏中嵌入 AI 终端（Terminal + Inspector + Activity）

§3 GStack Browser 的能力详解

专用 Profile 的隔离设计

专用 profile 与日常浏览器完全隔离：

防止自动化操作污染日常浏览器：批量修改不会意外退出你的个人邮箱登录态
防止日常浏览器配置干扰自动化：某个拦截请求的扩展不会影响自动化任务的稳定性
可以单独配置扩展和设置
可以配置专用 Cookie 和登录状态

Terminal 面板：交互式 claude PTY——你输入自然语言指令，AI 将其转化为 $B 命令（goto/click/text/snapshot）。这是你与浏览器的自然语言接口。

Inspector 面板：CSS 审查和修改——当页面元素不按预期显示时（如"审批按钮被遮挡了"），可以实时查看和修改 CSS。设计师和前端开发者的调试工具。

Activity 面板：浏览器事件日志——记录每一步操作（导航、点击、截图、表单提交），作为"谁在什么时候做了什么"的审计追踪。批量操作涉及资金或敏感数据时，Activity 日志是合规的关键。

工具栏按钮：Cleanup（清理页面——移除弹窗、广告、干扰元素）、Send to Code（将当前页面内容发送给 AI 分析）。

WebSocket 实时通信

Sidebar 与 Agent 通过 WebSocket 全双工通信。为什么是 WebSocket 而非 HTTP 轮询或 SSE？

HTTP 轮询（每秒 GET /events）：浪费带宽、延迟 1s——不适合需要实时反馈的浏览器操作
SSE（Server-Sent Events）：只能单向推送（服务器→客户端），但 Sidebar 也需要发送指令给浏览器（如 Cleanup、Send to Code）
WebSocket：全双工、低延迟、持久连接——浏览器事件推流（页面加载完成、新控制台错误、用户手动点击）无需轮询延迟

安全认证：Sec-WebSocket-Protocol token 防止同一台机器上的恶意进程伪装成 Sidebar 控制浏览器，或截获 Agent 发送给浏览器的敏感指令（如密码、API key）。

与 browse 的协作

$B 命令可以通过 open-gstack-browser 打开的浏览器执行（携带登录状态）
或通过独立的 Playwright 实例执行（更轻量、无登录状态）
选择标准：需要登录状态 → open-gstack-browser（或 setup-browser-cookies + $B）；无人值守自动化 → $B（无头 Playwright）

§4 结构拆解

open-gstack-browser AI 浏览器 Skill 结构模板

核心特征

管理对象: 携带用户真实登录状态的 Chrome 实例（非无头模式）
核心原则: 专用 profile 隔离——自动化操作不影响日常浏览器，日常浏览器配置不干扰自动化
关键设计:
- Sidebar 三面板：Terminal（AI 交互终端）+ Inspector（CSS 审查）+ Activity（操作审计日志）
- WebSocket 实时通信：Sidebar ↔ Agent 全双工事件推流
- 反机器人隐身：使用真实浏览器指纹规避检测

通用结构

浏览器层: Chrome/Chromium 实例 + 专用 profile（密码/Cookie/扩展）与日常浏览器完全隔离（双向保护）
Sidebar 层: Chrome 扩展嵌入三面板 Terminal: 交互式 claude PTY（自然语言 → $B 命令转换） Inspector: CSS 审查和修改（设计调试） Activity: 浏览器事件日志（操作审计——导航/点击/截图）
通信层: WebSocket 全双工（Sidebar ↔ Agent）安全认证: Sec-WebSocket-Protocol token 支持实时代码注入和执行
操作层: $B 命令通过专用浏览器或独立 Playwright 实例执行约 100ms/命令
审计层: Activity 面板记录每一步浏览器事件截图留证（批量操作审计——涉及资金或敏感数据的关键合规要求）

§5 电商 Skill 案例：电商后台批量操作自动化——退款审批+库存调整+订单导出

🛒 实战案例：某电商运营团队每天需要在后台执行重复操作——处理待审批退款（日均15-20笔）、调整库存预警商品的补货数量、导出当日订单报表给财务。后台是传统的服务端渲染页面（无API），每次操作需要手动登录→导航→点击→确认→等待，日均消耗运营人员1.5小时。使用open-gstack-browser将这三项操作自动化。

环境准备：/open-gstack-browser https://admin.mega-shop.com→Chrome启动使用专用profile（~/.gstack/chrome-profiles/ops），自动加载保存的登录Cookie→导航到后台首页→Sidebar Terminal就绪。三面板布局——主面板（后台页面）、Terminal面板（执行$B命令）、Activity面板（记录每一步操作事件）。

任务一：退款审批：$B goto https://admin.mega-shop.com/refunds/pending→$B text提取页面文本→识别"待处理退款 15 笔"→循环处理每笔退款——$B click "#approve-refund-12345"→等待确认对话框出现→$B snapshot -o "refund-12345-approval.png"截图留证→Activity面板记录操作事件(操作时间/操作人/退款ID/截图路径)。耗时：15笔退款从手动20分钟→自动化3分钟。

任务二：库存调整：$B goto https://admin.mega-shop.com/inventory/low-stock→$B text提取低库存商品列表（库存<20件的SKU 8个）→对每个SKU执行补货量计算（基于过去7天日均销量×30天安全库存）→$B fill "#sku-${id}-restock-qty" "${qty}"填入建议补货量→$B click "#batch-save"批量保存→Activity记录每笔库存变更（原库存→新库存→操作时间）。

任务三：订单导出：$B goto https://admin.mega-shop.com/orders/export→$B fill "#date-from" "2026-05-04"填入起始日期→$B fill "#date-to" "2026-05-04"→$B click "#export-csv"→等待下载完成→$B snapshot -o "orders-2026-05-04-export.png"截图确认导出成功→将CSV自动归档到共享文件夹。

审计与合规：每次操作的Activity面板生成JSON事件日志（含操作类型/目标URL/点击元素/截图/时间戳），在涉及资金的操作（退款审批）中保留完整审计追踪。运营主管可事后review截图确认"审批的退款是正确的"。合规要点——批量操作审计轨迹满足PCI DSS对支付相关操作的可追溯性要求。

🔑 启示：浏览器自动化的价值不在"快速"（API脚本更快）——而在"无障碍自动化"——后台没有API时也能自动化；截图留证让不可见的操作变得可审计；使用真实浏览器规避反爬虫检测。但它也有明确的边界：不适合大规模高频操作（浏览器资源消耗大）、不适合需要复杂判断的决策（退款审批中异常订单仍需人工判断）、网站UI改版后脚本可能失效（需要定期验证）。选择浏览器自动化 vs API脚本的关键判断不是"哪个更好"——而是"哪个能覆盖这个操作"。

[!info] 参考来源 Chrome extension sidebar 架构参考了 Chrome DevTools Protocol 和 Playwright Chrome extension testing 文档。

§6 掌握检验

Q1：open-gstack-browser（真实浏览器）与 $B/Playwright（无头浏览器）的最本质区别是什么？

A) 真实浏览器速度更快
B) 真实浏览器绑定你的 Chrome profile（保存的密码、Cookie、扩展都在），可以访问需要登录的页面；无头浏览器每次都是全新 session
C) 真实浏览器只能在 macOS 上运行
D) 真实浏览器不需要网络连接

Q2：GStack Browser 的专用 Chrome profile 为什么要与日常浏览器隔离？

A) 为了节省磁盘空间
B) 隔离防止自动化操作污染日常浏览器的 Cookie/扩展/登录状态，同时防止日常浏览器的配置影响自动化任务的可靠性
C) Chrome 要求每个用户只能有一个 profile
D) 专用 profile 可以绕过网站的反机器人检测

Q3：GStack Browser 的 Sidebar 集成了三个面板：Terminal、Inspector、Activity。请分别说明每个面板的功能和典型使用场景——在"自动化处理电商后台退款"的任务中，运营人员如何使用这三个面板协作完成工作？

Q4：Sidebar 与 Agent 通过 WebSocket 通信，使用 Sec-WebSocket-Protocol token 进行安全认证。为什么 WebSocket 是这个场景下的正确协议选择（而非 HTTP 轮询或 SSE）？Token 认证防止了什么安全风险？

Q5：open-gstack-browser 和 browse（$B 命令）的关系是什么？在什么场景下应该使用 open-gstack-browser（可见窗口 + 真实 profile），在什么场景下应该使用 $B（无头 Playwright）？如果两个都可以完成同一个任务，选择哪一个的判断标准是什么？

Q6：电商后台的批量操作（审核退款、更新库存、导出报表）使用 open-gstack-browser 的优势是什么？与"维护 API token 然后用脚本直接调 API"的方案相比，浏览器自动化方案的优势和劣势分别是什么？在什么情况下浏览器自动化是更好的选择？

§7 答案

点击查看答案

Q1：B —— 真实浏览器绑定专用 Chrome profile（保存的密码、Cookie、扩展），以真实用户身份访问需要登录的页面。无头浏览器每次都是全新 session——这是核心差异，决定了使用场景。

Q2：B —— 隔离的双向保护：①防止自动化操作意外影响你的日常浏览数据（如退出个人邮箱登录态）；②防止日常浏览器的配置（如某个扩展拦截了请求）干扰自动化任务的稳定性。

Q3：Terminal：交互式 claude PTY——运营人员输入"处理退款 #12345"，AI 转为 $B 操作。Inspector：CSS 审查——当按钮被遮挡时实时查看和修改 CSS。Activity：浏览器事件日志——记录每一步操作作为审计追踪。协作流程：Terminal 发指令 → AI 导航点击 → Activity 记录 → Inspector 确认视觉反馈 → Terminal 汇报结果。

Q4：WebSocket 提供全双工、低延迟、持久连接——浏览器事件推流无需轮询延迟。HTTP 轮询浪费带宽且延迟 1s；SSE 只能单向推送但 Sidebar 也需要发送指令。Token 认证防止：同一机器上恶意进程伪装 Sidebar 控制浏览器，或截获 Agent 发送的敏感指令（密码、API key）。

Q5：open-gstack-browser：需要登录状态（后台/管理面板）→ 真实 profile + Cookie；需要人工交互（运营看着操作）→ 可见窗口；需要审计截图 → Activity 日志。$B：公开页面验证 → 不需要登录；CI/CD 无人值守 → 无头模式；性能监控 → 轻量快速。判断标准：需要登录状态 → open-gstack-browser；无人值守 → $B；需人工观察 → open-gstack-browser。

Q6：优势：不需要 API token（后台可能根本没 API）、不需要学 API 文档、截图留证（审计）、规避反爬。劣势：速度比 API 慢、UI 改版后脚本脆弱、不适合大规模批量。最佳场景：系统没有 API / API 文档不全 / 操作频率低（每天几十次）/ 需要审计追踪（涉及资金）。

（5/6 通过）

L6-38：AI浏览器控制台 —— 给你的AI一双能看网页的眼睛