浏览器自动化与网页登录
浏览器自动化是 Flocks 中识别度较高、也较容易被误用的一类能力。核心思路是：当系统没有 API，或 API 覆盖不足时，Rex 可以像分析员一样打开网页、登录、点击并提取数据。
但浏览器自动化不是通用替代方案。本页重点说明两件事：
- 它最适合的任务形态
- 它明确不该碰的场景
场景简介
真实企业里一定存在这样的系统：
- 有 Web 控制台但没有开放 API
- 有 API 但只覆盖基础功能，关键数据还是得登录后台看
- 旧系统，API 文档遗失
- 外网第三方平台，只允许交互式登录
对这些系统，传统做法通常依赖人工截图、复制粘贴或定期导出 Excel。Flocks 的浏览器工具可以自动化这一层交互，但它始终是兜底方案，不是首选路径。
最适合的任务形态
| 场景 | 举例 |
|---|---|
| 只能网页取数 | 某家云控制台只提供 Web，没开 API |
| 一次性调研 | 快速看一眼某个平台的某个页面数据 |
| 登录后长驻使用 | 人工扫码 / 密码登录一次后，Rex 在这会话里接着做后续所有操作 |
| 发现后端接口 | 让 Rex 开着浏览器跑一遍，观察 XHR 请求，再把这些请求固化成稳定 API 工具 |
最后一条是该场景的关键：Flocks 提倡"浏览器突破 → 工具沉淀"的闭环。浏览器是进入系统的手段，不是最终状态。
明确不该用的场景
下列场景请回到 API / 日志路径（见 内网安全产品接入）：
| 场景 | 原因 |
|---|---|
| 设备本身提供成熟 API | 浏览器方案稳定性不如 API |
| 任务要每天定时跑、长期运行 | 网页结构、登录态、反爬策略都会变，维护成本高 |
| 部署在远程 / 无 GUI 的云主机 | 没有方便的人机交互环境做登录 |
| 数据量大、频率高 | 浏览器是逐页渲染，吞吐远低于 API |
| 合规敏感、必须留痕 | API 调用记录比浏览器行为更容易审计 |
本机安装 vs Docker
Flocks 的部署方式会直接决定浏览器场景可不可用：
| 部署方式 | Headed 交互式登录 | Headless 后台跑 | 推荐场景 |
|---|---|---|---|
| 本机安装 | ✅ 支持 | ✅ 支持 | 需要人工登录、扫码、短信验证码的场景 |
| Docker 部署 | ❌ 不适合 | ✅ 支持 | 纯后台运行、API 拉取、无头自动化 |
| 远程云主机 | ❌ 不适合 | ✅ 支持 | 定时任务、批量处理 |
如果需要人工完成扫码、短信验证码或密码登录，再由 Flocks 继续操作，应优先采用本机安装。
本机安装和 Docker 的对比详见 快速开始的安装方式说明。
操作步骤（WebUI）
步骤 1：新建会话，说明目标 + 交互方式
「打开 https://某云安全控制台.com，我完成登录后，请进入『告警』页面抓取最近 24 小时的所有告警」
Rex 会意识到这是一个需要人工介入的浏览器任务：
- 打开浏览器 → 导航到目标 URL
- 出现登录页后停下来，提示用户接管
- 用户完成扫码 / 输密码 / 过验证码
- Rex 重新接管，继续后续动作
步骤 2：观察 Rex 如何取数
Rex 会分步：
- 找到「告警」入口（读页面结构 / aria 标签 / 文字）
- 应用时间过滤 = "最近 24 小时"
- 翻页 / 滚动 / 导出
- 提取结构化数据
在本机部署下，用户可以在 WebUI 侧栏看到浏览器实时画面。
步骤 3：检查 Rex 是否发现可固化的后端接口
在复杂场景里，页面往往是 SPA，数据来自 XHR。Rex 可以：
- 读 Network 面板里的 XHR / Fetch 列表
- 识别哪个接口是真正的数据源
- 提取请求方法、URL、Headers、Body
- 把这个接口固化成一个 API 工具，后续不再走浏览器
这就是前面所说的"浏览器突破 → 工具沉淀"。一旦固化完成，下次执行同类任务即可直接使用 API 工具，稳定性和效率都会更高。
步骤 4：登录态管理
登录态（Cookie / Session / Token）会随会话保留一段时间。典型策略：
| 策略 | 适合场景 |
|---|---|
| 每次人工登录 | 高敏感场景，不留持久凭证 |
| 复用登录态跑一段时间 | 一天内要连着做多件事 |
| 让 Rex 把 Cookie 固化到工具里 | 明确授权的长期自动化；Cookie 过期需要人工重新登录 |
真实案例走读（方法论）
浏览器场景通常与其他场景组合出现：
- 告警研判（见 alert-triage）：TDP / NDR 没有 API 时，Rex 登陆页面抓告警
- 主机巡检：某些云厂商控制台没开 SSH，纯 Web 终端——Rex 可以操纵 Web 终端做只读巡检
- 威胁情报（见 threat-intel）：情报平台网页版有 API 没有的标签 / 关联信息时，浏览器补数
- 资产测绘（见 asset-discovery）：某些资产平台只提供 Web，浏览器直接用
一个实用判断标准
遇到"能否接入某系统"的需求时，建议按以下顺序判断：
- 有没有 API？ 有 → 走 内网安全产品接入
- 有没有日志推送 / 消息队列 / 定期导出？ 有 → 从汇聚层捞
- 能否获得 API 文档？ 能 → 优先推进 API 接入
- 以上都不成立 → 再考虑浏览器方案
直接优先选择浏览器方案，是该能力最常见的误用方式。
前置条件
| 依赖项 | 要求 |
|---|---|
| 部署方式 | 需要人工登录 → 必须本机安装；纯后台 → Docker 也行 |
| 浏览器工具 | 已启用浏览器 MCP / 浏览器工具 |
| 登录能力 | 用户能在部署节点或其转发的显示层上完成一次手动登录 |
| 稳定网络 | 浏览器对网络波动敏感，远端主机不建议 |
边界与常见问题
| 问题 | 处理 |
|---|---|
| Docker 部署如何完成交互式登录 | 建议使用本机部署；或先在本机登录并在授权范围内导出 Cookie，再导入 Docker 环境 |
| Rex 一直停留在登录页 | 通常是验证码或风控导致，需要人工完成登录 |
| 页面结构改版后跑不了 | 在 Skill 里更新选择器；或回到"让 Rex 重新探索页面"的方式 |
| 同一浏览器多会话冲突 | 给不同任务分别用独立浏览器上下文 / profile |
| 反爬策略严格 | 不建议强行绕过，应考虑降速、改用 API，或放弃自动化 |
| 数据量大导致运行缓慢 | 浏览器吞吐较低；如需规模化，应抓取后端 XHR 并固化为 API 工具 |
| 生产环境要留审计 | 在 Skill 里要求 Rex 每一步都写操作日志，并把日志落盘 |
何时从"浏览器方案"升级到"API 工具"
一旦你发现某个浏览器任务：
- 被定时化（每天 / 每小时跑一次）
- 跑了一段时间稳定
- 后端接口清晰稳定
就应考虑让 Rex 将其重构成 API 工具：
「把这个浏览器流程中实际调用的后端接口抽出来，生成一个独立的 API 工具，以后不走浏览器了」
这是让 Flocks 方案长期稳定运行的关键。浏览器应作为接入桥梁，而不是最终形态。
相关：场景总览 · 内网安全产品接入 · 威胁情报与 IOC 研判 · 互联网资产测绘 · 安装方式说明