浏览器自动化与网页登录
这是 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 的对比详见 README 部署模式说明。
操作步骤（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 过期需要人工重新登录 |
真实案例走读（方法论）
浏览器场景的 demo 不单独拎出来走一遍，而是融在其他场景里：
- 告警研判（见 alert-triage）：TDP / NDR 没有 API 时，Rex 登陆页面抓告警
- 主机巡检：某些云厂商控制台没开 SSH，纯 Web 终端——Rex 可以操纵 Web 终端做只读巡检
- 威胁情报（见 threat-intel）：情报平台网页版有 API 没有的标签 / 关联信息时，浏览器补数
- 资产测绘（见 asset-discovery）：某些资产平台只提供 Web，浏览器直接用
一个实用判断标准
新来一个"能不能接入 XXX"的需求，按以下顺序自问：
- 有没有 API？ 有 → 走 内网安全产品接入
- 有没有日志推送 / 消息队列 / 定期导出？ 有 → 从汇聚层捞
- 能不能和对方要 API 文档？ 能 → 先谈 API，别上来就上浏览器
- 以上都不成立 → 才上浏览器
顺序反过来是最常见的误用。
前置条件
| 依赖项 | 要求 |
|---|---|
| 部署方式 | 需要人工登录 → 必须本机安装；纯后台 → Docker 也行 |
| 浏览器工具 | 已启用浏览器 MCP / 浏览器工具 |
| 登录能力 | 用户能在部署节点或其转发的显示层上完成一次手动登录 |
| 稳定网络 | 浏览器对网络波动敏感，远端主机不建议 |
边界与常见问题
| 问题 | 处理 |
|---|---|
| Docker 部署怎么让人登录 | 老实用本机部署；或先在本机登录导出 Cookie 再导入 Docker 环境 |
| Rex 一直卡在登录页 | 多半是验证码 / 风控，Rex 不可能自己过，交人 |
| 页面结构改版后跑不了 | 在 Skill 里更新选择器；或回到"让 Rex 重新探索页面"的方式 |
| 同一浏览器多会话冲突 | 给不同任务分别用独立浏览器上下文 / profile |
| 反爬很严 | 别硬刚，要么降速、要么走 API、要么放弃 |
| 数据量大跑很慢 | 浏览器就是慢；需要规模化一定考虑抓后端 XHR 然后固化成 API 工具 |
| 生产环境要留审计 | 在 Skill 里要求 Rex 每一步都写操作日志，并把日志落盘 |
何时从"浏览器方案"升级到"API 工具"
一旦你发现某个浏览器任务：
- 被定时化（每天 / 每小时跑一次）
- 跑了一段时间稳定
- 后端接口清晰稳定
就该让 Rex 把它重构成 API 工具：
「把这个浏览器流程中实际调用的后端接口抽出来，生成一个独立的 API 工具，以后不走浏览器了」
这是让 Flocks 方案长期持续运行的关键。浏览器应该是进入的桥，不是终点。
相关：场景总览 · 内网安全产品接入 · 威胁情报与 IOC 研判 · 互联网资产测绘 · 部署模式选择