chore: 更新 Cloudflare 及浏览器自动化攻防文章并补发 blog 链接

This commit is contained in:
leeguooooo
2026-03-04 09:39:38 +09:00
parent d32a1d046a
commit c07eb7ee52
16 changed files with 1324 additions and 248 deletions
+272
View File
@@ -0,0 +1,272 @@
# PRD: CLI Web 数据采集体验优化(以小红书场景为例)
- 文档版本: v0.1
- 状态: Draft
- 作者: Codex
- 日期: 2026-03-04
## 1. 背景与问题
在使用 `agent-browser` CLI 执行「小红书宠物博主采集(100 条)」时,当前流程可完成任务,但存在明显的可用性与稳定性痛点:
1. 网络层可观测性不足,响应体抓取不稳定,需注入脚本劫持。
2. 分页采集依赖手工 `scroll down + wait`,重复劳动且易漏数据。
3. 结构化导出缺少一站式命令,需要 `eval` 二次解析。
4. 页面交互依赖文本选择,页面文案变动后脆弱。
5. 反爬失败时缺少可解释的自动回退策略。
6. 用户对“可抓字段”预期不清(例如搜索接口无联系方式)。
7. 长会话缺少快照与断点续抓机制。
## 2. 目标与非目标
## 2.1 目标
1. 将常见采集链路从“脚本拼接”降为“CLI 原生命令组合”。
2. 让关键动作具备可观测性(日志)和可恢复性(快照/续跑)。
3. 降低站点轻微改版、反爬限制带来的失败率。
## 2.2 非目标
1. 不承诺绕过平台强风控或登录体系。
2. 不在本期实现完整通用爬虫 DSL。
3. 不默认抓取平台未公开展示的隐私字段。
## 3. 目标用户与核心场景
1. 增长/运营: 按关键词采集账号基础数据并导出 CSV。
2. 测试/研发: 复现抓取问题,定位请求失败原因。
3. AI Agent 工作流: 在 CLI 内稳定执行“搜索 -> 翻页 -> 提取 -> 导出”。
## 4. 需求范围与优先级
## 4.1 P0
1. `network capture` 增强模式(可过滤、可落盘 response body)。
2. `scroll-collect` 自动滚动采集(按页数或直到无新增)。
3. `extract` / `extract-to` 结构化导出(JSON/CSV)。
## 4.2 P1
1. 语义选择器与 fallback 链(role/aria/data/text)。
2. 401/403/406 智能回退(页面触发 + 回包监听)。
3. 可抓字段矩阵与二段式采集文档提示。
## 4.3 P2
1. `session snapshot` + `crawl resume` 断点续抓。
## 5. CLI 方案设计
## 5.1 网络捕获增强
命令草案:
```bash
agent-browser network capture --match '/api/sns/web/v1/search/usersearch' --save ./out.ndjson
agent-browser network capture --domain edith.xiaohongshu.com --method POST --save ./xhs_usersearch.ndjson
```
参数:
- `--match <regex>`: 按 URL 正则过滤。
- `--domain <host>`: 按域名过滤。
- `--method <GET|POST|...>`: 按方法过滤。
- `--status <code|range>`: 按状态过滤。
- `--save <path>`: NDJSON 输出文件。
- `--include-body <request|response|both>`: 控制 body 输出范围。
- `--max-body-bytes <n>`: 单条 body 截断阈值。
NDJSON 记录结构:
```json
{
"ts": "2026-03-04T10:00:00.123Z",
"session_id": "sess_abc",
"request_id": "req_123",
"method": "POST",
"url": "https://edith.xiaohongshu.com/api/sns/web/v1/search/usersearch",
"status": 200,
"duration_ms": 312,
"request_headers": {"content-type": "application/json"},
"request_body": "{...}",
"response_headers": {"content-type": "application/json"},
"response_body": "{...}",
"truncated": false
}
```
## 5.2 自动滚动采集
命令草案:
```bash
agent-browser scroll-collect --until no-new-items --max-steps 200 --idle-rounds 3
agent-browser scroll-collect --pages 20 --wait-ms 1200
```
行为:
1. 每轮执行滚动与等待。
2. 基于 DOM 项数量或网络新增请求判断“是否有新增”。
3. 达到停止条件后输出结束原因。
输出示例:
```text
step=1 new_items=15 total_items=15
step=2 new_items=15 total_items=30
...
stop_reason=no-new-items idle_rounds=3 total_items=135
```
## 5.3 结构化提取与导出
命令草案:
```bash
agent-browser extract --from network --match usersearch --fields 'name,fans,note_count,red_id'
agent-browser extract-to --from network --match usersearch --fields 'name,fans,note_count,red_id,url' --format csv --out ./users.csv
```
参数:
- `--from <network|dom|eval>`: 数据源。
- `--match <pattern>`: 来源过滤(URL/事件名)。
- `--query <JMESPath|JSONPath>`: 自定义提取表达式。
- `--fields <a,b,c>`: 字段映射快捷写法。
- `--dedupe-by <field>`: 去重键。
- `--limit <n>`: 限制条数。
- `--format <json|ndjson|csv>`: 输出格式。
- `--out <path>`: 文件输出路径。
## 5.4 语义选择器与回退链
命令草案:
```bash
agent-browser click --selector 'role=tab[name="用户"]' --fallback 'aria=用户,text=用户'
agent-browser find --selector 'data-testid=user-tab' --fallback 'role=tab[name="用户"],text=用户'
```
策略:
1. 主选择器失败后按 fallback 顺序重试。
2. 日志打印每次尝试与失败原因。
## 5.5 反爬失败自动回退
命令草案:
```bash
agent-browser request replay --on-status 401,403,406 --fallback page-action
```
策略:
1. 直接请求失败后自动回退到页面行为触发。
2. 自动复用 UA/Referer/Cookie Jar。
3. 捕获最终有效响应并给出“回退成功/失败”日志。
## 5.6 会话快照与断点续抓
命令草案:
```bash
agent-browser session snapshot save ./snapshots/xhs-20260304.json
agent-browser crawl resume --snapshot ./snapshots/xhs-20260304.json --out ./users.csv
```
快照最小字段:
- 当前 URL
- 关键词/筛选参数
- 已抓 user_id 集合摘要(可哈希分片)
- 分页进度(page/scroll step
- 导出配置(fields/format/out
## 6. 错误码设计(草案)
- `AB_NET_CAPTURE_BODY_UNAVAILABLE` (1001): 响应体不可用(被浏览器策略阻断或已释放)。
- `AB_SCROLL_TIMEOUT_NO_PROGRESS` (1101): 滚动超时且无新增。
- `AB_EXTRACT_QUERY_INVALID` (1201): 提取表达式语法错误。
- `AB_EXTRACT_OUTPUT_FAILED` (1202): 导出失败(权限/路径不可写)。
- `AB_SELECTOR_NOT_FOUND` (1301): 主选择器与 fallback 全部失败。
- `AB_REQUEST_BLOCKED_406` (1406): 请求被风控拦截,且回退链路失败。
- `AB_RESUME_SNAPSHOT_INVALID` (1501): 快照损坏或版本不兼容。
要求:
1. CLI 退出码与错误码可映射。
2. 错误输出提供 `hint`(下一步建议命令)。
## 7. 日志与可观测性
默认人类可读,开启 `--log-format json` 输出结构化日志。
JSON 日志字段:
- `ts`
- `level`
- `session_id`
- `command`
- `event`
- `step`
- `url`
- `status`
- `error_code`
- `message`
- `hint`
示例:
```json
{"ts":"2026-03-04T10:11:22.123Z","level":"INFO","command":"scroll-collect","event":"step","step":12,"new_items":15,"total_items":180}
{"ts":"2026-03-04T10:13:01.001Z","level":"WARN","command":"request replay","event":"fallback","status":406,"message":"direct request blocked, fallback to page-action"}
```
## 8. 文档与帮助信息更新要求
当功能落地时,需要同步更新以下位置(按仓库规范):
1. `cli/src/output.rs``--help`、示例、环境变量)
2. `README.md`(命令选项、样例)
3. `skills/agent-browser/SKILL.md`Agent 工作流)
4. `docs/src/app/`(新增/更新 MDX 页面,表格使用 HTML `<table>`
5. 对应源码内联注释
## 9. 验收用例(首批)
1. `network capture` 能稳定保存目标接口完整 request/response body。
2. 设置 `--max-body-bytes` 后被截断记录带 `truncated=true`
3. `scroll-collect --pages 5` 精确执行 5 轮并退出。
4. `scroll-collect --until no-new-items` 在连续空增量 N 轮后退出。
5. `extract-to ... --format csv` 产出可打开 CSV 且列名正确。
6. `extract --dedupe-by user_id` 去重结果稳定。
7. selector 主规则失败时,fallback 生效并成功点击。
8. 对 406 场景触发自动回退并成功捕获有效响应。
9. 回退失败时返回 `AB_REQUEST_BLOCKED_406` 且提供 hint。
10. `session snapshot save/load` 前后任务可恢复。
11. `crawl resume` 不重复导出已抓 ID。
12. `--log-format json` 日志字段完整,便于机器消费。
## 10. 里程碑建议
1. M11 周): `network capture` + `scroll-collect`
2. M21 周): `extract-to` + selector fallback。
3. M3(1 周): 406 回退链路 + 文档补全。
4. M41 周): snapshot/resume + 稳定性打磨。
## 11. 风险与缓解
1. 平台策略变化导致规则失效。
缓解: 增加站点适配层与策略开关,保留回退日志。
2. 响应体过大带来内存与 IO 压力。
缓解: 流式写入 NDJSON + 截断阈值。
3. 通用提取表达式学习成本高。
缓解: 提供字段模板与场景 presets。
## 12. 开放问题
1. `extract` 表达式标准优先 JSONPath 还是 JMESPath
2. `session snapshot` 是否需要加密(含 cookie 元信息)?
3. 是否提供站点模板(如 `preset xiaohongshu-user-search`)以降低上手成本?
@@ -1,189 +1,192 @@
# 从「能跑」到「长期稳定」:agent-browser-stealth 的攻防工程实践
# 浏览器自动化攻防方案设计:检测模型与分层控制面
高风控站点对自动化会话的判断,通常不是单一规则命中,而是多信号打分。
要点不在“补一个 patch”,而在“让整组信号在同一会话内自洽”。
本文聚焦浏览器自动化的攻防方案设计,按两个部分组织:
项目地址:[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
1. **原理**:风险评分系统如何形成结论
2. **控制面**:如何用分层设计降低风险与波动
本文不包含命令行操作与工程实现步骤。
Turnstile 专题内容见:
[Cloudflare Turnstile 攻防方案设计:系统原理与控制面](https://blog.misonote.com/zh/posts/cloudflare-turnstile-stability-principles/)
---
## 检测系统如何做判断
## 一、原理
大多数检测系统会同时看三类问题:
### 1.1 风险评分不是单点命中
1. **一致性**:UA、语言、时区、渲染能力是否互相匹配
2. **稀有性**:是否出现低频但高度可疑的组合(如某些 headless 特征并存)
3. **时序性**:输入、点击、等待、重试是否呈现机械节奏
高风控站点的“是否挑战/是否降权”通常来自多维评分,而不是某一条规则的二元判断。
评估通常是累积分值而非二元判断。
同一个会话里的轻微异常可以被容忍,但跨维度冲突叠加后,容易触发挑战页或高频二次验证。
主要输入维度:
1. **一致性**:同一身份在不同表面是否互相矛盾
2. **稀有性**:低频异常组合是否出现
3. **时序性**:行为时间序列是否呈机械统计特征
4. **执行完整性**:关键链路(挑战脚本、跨域资源、worker)是否被破坏
```mermaid
flowchart LR
A["采集信号"] --> B["一致性检查"]
A --> C["稀有性评"]
A --> D["时序行为评估"]
B --> E["风险分值"]
C --> E
D --> E
E --> F{"超过阈值?"}
F -->|否| G["继续放行"]
F -->|是| H["挑战/验证/限流"]
```
这个模型对应的治理原则很直接:
- 优先消除跨维度冲突
- 再处理低频高危特征
- 最后处理行为时序的机械性
---
## 指纹治理:从“补点”改成“信号闭环”
指纹治理按 `launch -> CDP -> init script` 三层执行。
核心目标是把“可见信号”变成一张一致的画像,而不是局部拟真。
```mermaid
flowchart LR
A["Launch 层"] --> B["CDP 层"]
B --> C["Init Script 层"]
C --> D["统一画像"]
D --> E["降低冲突分值"]
```
### Launch 层(本地启动时的基础面)
Launch 层处理“浏览器刚启动就暴露”的特征面:
- `--disable-blink-features=AutomationControlled`
- `--use-gl=angle`
- `--use-angle=default`
- 默认 UA 清洗(未自定义 UA 时去掉 `HeadlessChrome`
原理:这层不追求“真实用户画像”,而是先消除明显自动化标识,避免会话在首屏前就进入高风险。
### CDP 层(运行时协议面)
CDP 层治理的是“同一身份在不同字段里的自我矛盾”:
- 同步覆盖 `userAgent``acceptLanguage``userAgentMetadata`
- 覆盖应持续作用于新旧 target
- 设置不透明背景,降低透明渲染特征
典型冲突示例:
- `userAgent` 显示某平台版本,但 `userAgentMetadata` brand/version 不对应
- 语言首选项与请求头不一致
这类冲突往往比“是否 headless”更早触发评分上升。
### Init Script 层(页面脚本前)
Init 层治理页面 JS 可直接探测的运行时表面。
重点不是数量,而是覆盖高频检查路径。
高频治理面:
- Runtime 身份:`navigator.webdriver``chrome.runtime``cdc_`
- Navigator 能力:`languages/plugins/mimeTypes/permissions/userAgentData`
- 渲染能力:WebGL vendor/renderer
- 窗口屏幕:`outer*` / `screen*` / `avail*`
- 能力暴露:`share/contacts/contentIndex/mediaDevices/pdfViewerEnabled`
- 边缘特征:`connection/hardwareConcurrency/performance.memory`
### 指纹排障优先级
| 优先级 | 信号面 | 常见现象 | 先做什么 |
| --- | --- | --- | --- |
| P0 | UA + metadata + language | 首屏挑战页 | 先统一三者,再看其它项 |
| P1 | webdriver/runtime 痕迹 | 关键动作前即拦截 | 验证 init 注入是否在页面脚本前生效 |
| P2 | WebGL/screen | 间歇性二次验证 | 对齐渲染与窗口参数 |
| P3 | connection/memory 等边缘面 | 长链路后段异常 | 增量修复并对照回归 |
---
## 行为治理:让时序分布接近真实交互
行为检测通常不关心单次点击,而关注一段时间序列。
真正会被命中的,是“低方差、强周期、强同步”的机器节奏。
```mermaid
flowchart TD
A["动作计划"] --> B["输入节奏分布"]
A --> C["鼠标轨迹分布"]
A --> D["等待/思考时间分布"]
A --> E["重试退避分布"]
B --> F["执行时序"]
A["环境与行为"] --> B["一致性评分"]
A --> C["稀有性评"]
A --> D["时序评分"]
A --> E["执行完整性评分"]
B --> F["综合风险"]
C --> F
D --> F
E --> F
F --> G{"放行/挑战/限流"}
```
### 输入节奏
### 1.2 一致性:约束集合而非单点修饰
固定字符延迟(例如全程 100ms)很容易形成可分辨模式。
更稳妥的做法是“基线 + 抖动 + 语义停顿”:
一致性问题的本质是“同一身份在多个观测面上的约束必须同时成立”。
- 基线延迟围绕输入场景变化
- 每字符有扰动,不保持等间隔
- 词边界、字段切换处出现较长停顿
#### 1.2.1 约束集合示意
### 鼠标轨迹
可以把身份一致性建模为“约束图”:
坐标瞬移与恒速直线是高风险模式。
轨迹应包含:
```mermaid
flowchart TD
UA["UA 字符串"] --> UACH["UA-CH / userAgentMetadata"]
UA --> LangH["Accept-Language"]
LangH --> LangJS["navigator.language(s)"]
LangJS --> Intl["Intl locale/timeZone"]
Plat["platform"] --> Rend["渲染能力/WebGL"]
Rend --> Win["窗口/屏幕参数"]
UACH --> Plat
```
- 曲线路径
- 中间采样点
- 速度变化(起步、调整、收敛)
图中每条边表示“两个表面必须相互一致”,否则会形成冲突分值。
### 等待与思考时间
#### 1.2.2 典型冲突类型
固定等待常量会形成明显周期。
建议使用区间采样,让同类操作在时间上有自然波动。
- UA 显示平台/版本与 UA-CH 不一致
- `Accept-Language``navigator.languages` 不一致
- `Intl` 时区与偏移/地区推断不一致
- 设备声明与渲染能力组合异常
### 重试退避
工程含义:
命中风险后继续等间隔重试,通常会放大风险分值。
退避策略应具备:
- 修一个点可能打破另一个点
- 设计顺序应是“先定约束集合,再决定每个表面如何满足约束”
- 间隔递增
- 抖动扰动
- 次数上限
### 1.3 稀有性:组合风险而非单值风险
### 行为反模式
稀有性来自“低频组合”,其危险性来自共现而非单项。
- 全链路固定输入延迟
- 点击前无移动直接命中目标
- 所有等待都是同一个常量
- 重试间隔完全一致
- 所有站点使用同一动作模板
可以将稀有性理解为“联合分布”偏离:
- 单项偏离:可被容忍
- 多项共现偏离:风险迅速累积
工程含义:
- 目标是减少低频组合在同一会话内叠加
- 目标不是拟合某个固定画像
### 1.4 时序性:统计特征而非行为语义
行为检测通常关注统计分布特征:
- 低方差:动作间隔过于稳定
- 强周期:间隔呈固定节奏
- 强同步:不同类型动作间隔一致
工程含义:
- 行为治理的目标是“分布塑形”(variance/jitter/backoff
- 行为治理不是“添加更多动作”
### 1.5 执行完整性:上游条件
执行完整性属于“系统是否能正确运行”的前置条件。
- challenge 脚本、跨域 iframe、跨域 worker 的语义被破坏时,失败率会显著上升
- 此类失败可能与“是否被识别”为不同类别的问题
工程原则:
> 执行链路保护优先于信号修饰。
---
## 2026-03 实战更新:Cloudflare 验证页恢复策略
## 二、控制面(分层设计)
在真实使用中,`dash.cloudflare.com` 一类站点常见 `Just a moment... / Performing security verification` 挑战页。
关键问题不只是“被识别”,还包括“客户端过早刷新把挑战流程重置”,导致长期卡在验证中。
### 2.1 控制面总览
本次修复的关键点
攻防方案可以拆为四层控制面
1. **风险信号增强**:从 `URL + Title` 扩展为 `URL + Title + PageText`
覆盖 `Performing security verification``This website uses a security service...` 等文本证据。
2. **恢复策略调整**`risk-mode=warn` 先等待挑战自动放行,再进入重试
避免“重试即刷新”打断 Cloudflare 的挑战倒计时。
3. **会话稳定化**:未显式传 `--session-name` 时,默认跟随 `--session`
降低会话漂移造成的重复挑战概率。
4. **挑战窗口友好化**:减少过早刷新导致的挑战重置
让验证流程有足够时间自动完成,降低反复卡住的概率。
1. **启动控制**:治理启动早期显式风险
2. **协议控制**:治理协议层身份一致性
3. **运行时控制**:治理页面脚本可观测表面
4. **行为与会话控制**:治理时序分布与上下文漂移
```mermaid
flowchart LR
A["启动控制"] --> B["协议控制"]
B --> C["运行时控制"]
C --> D["行为与会话控制"]
D --> E["一致性与稳定性"]
```
### 2.2 启动控制
目标:降低会话早期显式风险。
设计约束:
- 只处理高置信度自动化标识
- 避免引入与协议层/运行时层不一致的改动
### 2.3 协议控制
目标:将身份约束集合落实到协议层输出。
设计要点:
- 将 UA 与 UA-CH 视为同一约束集合的不同投影
- 覆盖范围需要与目标(页面/worker/子目标)一致
### 2.4 运行时控制
目标:覆盖高频探测面,同时保证不破坏执行语义。
设计要点:
- 优先治理高频、可解释的探测路径
- 对跨域挑战链路对象设置严格注入边界
### 2.5 行为与会话控制
目标:塑形时间分布,减少上下文漂移。
设计要点:
- 行为治理以统计分布为目标(variance/jitter/backoff
- 会话治理以一致上下文为目标(避免身份漂移)
### 2.6 挑战场景控制面摘要(Turnstile)
Turnstile 场景下的关键控制面可抽象为:
1. 能力令牌语义:服务端验证、有限时效、单次消费
2. 作用域收缩:`hostname/action/cdata` 收缩滥用空间
3. 执行链路保护:跨域脚本/iframe/worker 语义保护
4. 摩擦与安全分离:clearance 属于体验层,不替代安全决策层
该摘要用于将 Turnstile 纳入统一控制面框架;细节见专题文章。
---
## 结语
## 三、方案设计优先级
指纹治理的重点是跨维度一致性。
行为治理的重点是时间分布去机械化。
把这两部分统一治理,通常能显著降低攻防波动。
控制面设计通常按以下优先级推进:
项目地址:[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
1. 执行完整性(保证链路可运行)
2. 一致性约束集合(消除跨表面矛盾)
3. 稀有性控制(避免低频组合叠加)
4. 时序分布塑形(降低机械统计特征)
5. 体验优化(降低重复挑战摩擦)
该顺序的含义是先保证“系统正确性”,再优化“稳定性与摩擦”。
@@ -0,0 +1,250 @@
# Cloudflare Turnstile 攻防方案设计:系统原理与控制面
本文聚焦 Turnstile 的攻防方案设计:
1. **系统原理**:token 的安全语义、挑战执行链路、风险评分的输入输出
2. **控制面设计**:在不同攻击面下,哪些约束是必要的、哪些约束容易引入副作用
本文不包含命令行操作与工程实现步骤。
---
## 一、系统原理
### 1.1 Turnstile 是“能力令牌”系统
Turnstile 的本质是签发一个短生命周期、单次消费的能力令牌(capability token)。
- **签发端**:浏览器端完成挑战执行后获得 token
- **消费端**:业务服务端通过 Siteverify 验证 token 并决定是否放行
```mermaid
flowchart LR
A["浏览器端挑战执行"] --> B["token"]
B --> C["业务服务端"]
C --> D["Siteverify"]
D --> E{"放行/拒绝"}
```
关键含义:
- 前端任何“通过”状态都不是业务放行条件
- 业务放行条件是“token 被正确消费”
### 1.2 Token 的三条安全语义
token 的安全语义可以抽象为三条约束:
1. **必须服务端验证**:不允许仅以前端回调作为依据
2. **有限时效**token 超过时效窗口即失效
3. **单次消费**:同一 token 重复消费应失败
这三条语义分别封装了三个常见攻击目标:
- 伪通过:绕过服务端验证
- 延迟提交:绕过时效窗口
- 重放/并发:绕过单次消费
### 1.3 挑战执行链路是“跨域执行系统”
Turnstile 的 token 产生依赖多组件协作,且跨域链路占主导:
- `api.js` 脚本
- challenge iframe
- challenge worker
- 跨域资源请求
```mermaid
flowchart TD
A["加载 api.js"] --> B["创建 iframe"]
B --> C["执行 worker"]
C --> D["收集信号 + 风险评估"]
D --> E["签发 token"]
```
该链路的工程含义:
- 任何对跨域脚本/iframe/worker 的语义改写,都可能导致 token 生成失败或质量下降
- token 失败不一定意味着“被识别”,也可能是“链路被破坏”
### 1.4 风险评分:输入不是“真假”,而是“自洽程度”
挑战执行阶段会收集环境与行为信号,形成风险评分。
- **信号输入**:环境一致性(UA/UA-CH、语言/时区、渲染能力、能力暴露)
- **行为输入**:时序分布(方差、周期性、同步性)
风险评分的关键不是“拟合某种固定画像”,而是“同一身份在多表面是否自洽”。
### 1.5 作用域绑定:hostname / action / cdata
服务端校验时提供用于绑定业务语义的字段:
- `hostname`token 允许的站点作用域
- `action`token 允许的动作作用域
- `cdata`token 允许的上下文作用域
这些字段的作用是“收缩 token 可被滥用的范围”,而不是“提高通过率”。
```mermaid
flowchart LR
A["token"] --> B["hostname 作用域"]
A --> C["action 作用域"]
A --> D["cdata 作用域"]
B --> E["降低站外盗用收益"]
C --> F["降低动作错配收益"]
D --> G["降低跨流程重放收益"]
```
### 1.6 Token 状态机(能力令牌视角)
从能力令牌视角,token 生命周期可抽象为:
```mermaid
stateDiagram-v2
[*] --> Issued: challenge ok
Issued --> Consumed: siteverify ok
Issued --> Expired: time window
Issued --> Rejected: binding mismatch
Issued --> Replayed: reused
Replayed --> Rejected
Expired --> Rejected
Consumed --> [*]
```
设计目标是让“非法路径”快速失败,并且失败类型可被服务端语义区分。
### 1.7 攻击树(高层)
Turnstile 的主要攻击目标可以抽象为:
```mermaid
flowchart TD
A["绕过业务动作门禁"] --> B["伪造或跳过服务端验证"]
A --> C["重放 token"]
A --> D["扩大 token 作用域"]
A --> E["破坏挑战执行以制造降级路径"]
C --> C1["并发提交"]
C --> C2["延迟提交"]
D --> D1["Any Hostname"]
D --> D2["action/cdata 缺失"]
```
该攻击树强调设计重点:
- 安全决策必须在服务端闭环
- token 必须被作用域收缩并按语义消费
---
## 二、控制面设计(攻防视角)
### 2.1 控制面分层
Turnstile 防线可以分为四层控制面:
1. **挑战执行控制**:保证脚本/iframe/worker 跨域链路完整
2. **服务端消费控制**:保证 token 的语义被正确消费
3. **作用域控制**:收缩 `hostname/action/cdata` 的可用范围
4. **摩擦控制**:clearance 用于降低挑战摩擦(不作为安全决策依据)
```mermaid
flowchart LR
A["挑战执行控制"] --> E["token 可生成"]
A --> F["token 质量"]
B["服务端消费控制"] --> G["安全决策闭环"]
C["作用域控制"] --> H["滥用收益收缩"]
D["摩擦控制"] --> I["挑战频率下降"]
```
### 2.2 挑战执行控制:跨域语义保护优先
挑战执行链路对跨域执行语义高度敏感。
原则:
- 跨域脚本/iframe/worker 避免语义改写
- 所有指纹修饰必须先满足“不破坏挑战执行”这一硬约束
该原则的工程含义:
- “执行完整性”是上游条件
- “信号修饰”是下游优化
### 2.3 服务端消费控制:把 token 当作能力消费
服务端消费控制的设计关键在于“放行条件定义”,而不是“接口调用细节”。
放行条件应体现三类约束:
- 真实性:校验 `success`
- 作用域:校验 `hostname`
- 语义绑定:校验 `action/cdata`
并且必须贯彻 token 的两个安全语义:
- 时效性:过期拒绝
- 单次性:重放拒绝
从攻防角度,该层解决的是“绕过与重放”。
### 2.4 作用域控制:Hostname Management 与 Any Hostname
Hostname 管理解决“站外盗用”的攻击面。
- 启用 Hostname Management:收缩 token 可用站点范围
- 启用 Any Hostname:扩大 token 可用站点范围
设计结论:
- Any Hostname 不是“更灵活”,而是“扩大攻击面”,必须用更强的服务端约束做补偿控制(来源域白名单 + 业务绑定)。
### 2.5 摩擦控制:Pre-clearance 与 cf_clearance 的边界
Pre-clearance 通过后可产生 clearance,用于后续 WAF 挑战联动。
边界定义:
- clearance 用于体验层(降低重复挑战摩擦)
- Siteverify 用于安全决策层(业务放行依据)
将两者混用会引入“体验信号替代安全信号”的设计缺陷。
### 2.6 高对抗场景:代理池与设备关联
在代理池与分布式滥用场景中,单一 IP 维度约束容易失效。
设计方向是引入更稳定的关联维度(例如设备级 ephemeral id),用于聚类与阈值策略。
该层属于平台能力与业务风控的交界:
- 平台提供关联信号
- 业务定义动作分层、阈值与处置策略
---
## 三、方案设计优先级
Turnstile 攻防设计通常按以下优先级推进:
1. 服务端消费语义闭环(真实性 + 作用域 + 绑定 + 单次性 + 时效性)
2. 挑战执行链路完整性(跨域语义保护)
3. 信号一致性(减少跨字段矛盾)
4. 行为时序(降低机械分布)
5. 体验优化(clearance 等摩擦控制)
该顺序的含义是先定义“正确的安全决策”,再优化“挑战摩擦与通过率波动”。
---
## 官方参考(概念与配置)
- Widgets: <https://developers.cloudflare.com/turnstile/concepts/widget/>
- Widget configurations: <https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/widget-configurations/>
- Server-side validation: <https://developers.cloudflare.com/turnstile/get-started/server-side-validation/>
- CSP: <https://developers.cloudflare.com/turnstile/reference/content-security-policy/>
- Hostname management: <https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/>
- Any Hostname: <https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/any-hostname/>
- Pre-clearance: <https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/pre-clearance/>
- Cloudflare clearance: <https://developers.cloudflare.com/cloudflare-challenges/concepts/clearance/>
- Ephemeral IDs: <https://developers.cloudflare.com/turnstile/additional-configuration/ephemeral-id/>
@@ -1,105 +1,97 @@
# 使用 agent-browser-stealth 代替 agent-browser
# agent-browser agent-browser-stealth:能力差异与选型
很多人已经把 AI Agent 接入了浏览器自动化,但上线后会遇到同一个问题:
同样流程在不同网站表现不一致;流程写完了,关键站点还是过不去。
问题通常不在“会不会自动化”,而在“能不能在真实网站里稳定自动化”。
这就是为什么要从 `agent-browser` 升级到 `agent-browser-stealth`
本文给出 `agent-browser``agent-browser-stealth` 的技术差异、适用场景和升级验证步骤。
项目地址:[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
---
## 为什么要替换
## 1. 定位差异
### 1) 让 AI 真正可以使用浏览器
很多网站已经有反爬和自动化检测策略。
在这些场景里,传统自动化链路会出现高频验证、中断、重试失败,最终让 AI 任务卡在关键步骤。
`agent-browser-stealth` 的目标很明确:让 AI 在真实网站环境中保持更高可用性。
### 2) 应对“限制 AI 浏览器”的站点策略
部分站点会对自动化浏览器做额外限制,包括:
- 触发挑战页
- 关键页面二次验证
- 会话中途降权或限流
`agent-browser-stealth` 提供更完整的防识别能力,降低这类限制对任务成功率的影响。
### 3) 让 Agent 和用户共享同一个浏览器
很多自动化失败发生在“登录前后状态切换”环节。
`agent-browser-stealth` 支持 Agent 复用用户正在使用的浏览器会话,直接继承已登录状态,减少重复登录和验证码干扰。
对业务流程的价值是直接的:
- 缩短执行路径
- 降低登录步骤失败率
- 提升整体成功率与执行速度
- `agent-browser`:标准浏览器自动化能力
- `agent-browser-stealth`:在标准自动化能力基础上,增加反检测与高风控场景稳定性能力
---
## 典型站点效果(示例)
以亚马逊这类高风控电商站点为例,很多 AI 浏览器流程过去常见的问题是:
- 能打开首页,但关键操作前触发验证
- 搜索、跳转、加购这类连续动作中途被打断
- 会话偶发失效,任务难以完整执行
切换到 `agent-browser-stealth` 后,可显著提升这类流程的可执行性,常见可完成动作包括:
- 商品搜索与详情浏览
- 购物车相关操作
- 已登录状态下的页面导航与信息读取
除了电商站点,下面两类场景也常见明显改善:
- 社媒/内容平台:多步骤跳转流程更稳定
- SaaS 后台系统:登录后连续操作中断率降低
说明:不同账号状态、网络环境、站点实时策略会影响最终效果。
---
## 适合哪些场景
- AI 客服或运营 Agent 需要在多站点执行后台操作
- 自动化流程经常卡在登录、验证、跳转环节
- 需要“人机协同”:用户和 Agent 共用一个会话处理复杂任务
- 对稳定性要求高的生产任务(不是 Demo)
---
## 迁移成本高吗
迁移成本通常很低,命令习惯可以保持一致。
多数场景可以先做“无侵入替换”,再按业务流程逐步优化。
---
## 一张表看差异
## 2. 核心能力对比
| 维度 | agent-browser | agent-browser-stealth |
| --- | --- | --- |
| 目标 | 标准自动化能力 | 面向真实风控环境的稳定自动化 |
| 站点兼容性 | 普通站点可用 | 高风控站点可用性更高 |
| AI 执行稳定性 | 受验证页影响明显 | 对验证/限制策略更稳 |
| 登录链路 | 常需重复处理登录步骤 | 支持复用用户浏览器状态,减少登录干扰 |
| 生产可用性 | 适合基础自动化 | 更适合生产级 AI 浏览器任务 |
| 自动化基础能力 | 支持 | 支持 |
| 指纹一致性治理 | 基础 | 多层(launch/CDP/init-script |
| 高风控站点稳定性 | 一般 | 更高 |
| 会话连续性(附着现有浏览器) | 支持 | 支持,默认附着策略更明确 |
| Cloudflare/Turnstile 回归工具 | 无专用脚本 | `check:turnstile-testkey` |
---
## 结论
## 3. Cloudflare/Turnstile 相关能力(v0.15.2-fork.2+
如果目标是“让 AI 在真实网站里稳定完成任务”,`agent-browser-stealth` 是更合适的选择。
如果目标只是“脚本在理想环境跑通”,`agent-browser` 已经足够。
### 3.1 挑战链路保护
在生产环境里,真正的差异通常体现在四个字:**可用与稳定**。
- 同源 worker 注入保留
- 跨域 challenge worker 不做注入改写
- 降低 challenge worker 执行异常概率
### 3.2 导航等待策略
`open/navigate` 支持:
- `--wait-until load`
- `--wait-until domcontentloaded`
- `--wait-until networkidle`
挑战页建议优先 `domcontentloaded`,减少 `load` 阶段超时误判。
### 3.3 确定性回归
提供官方 test key 回归脚本:
```bash
pnpm run check:turnstile-testkey
```
通过特征:输出 `XXXX.DUMMY.TOKEN.XXXX`
---
## 4. 适用场景
优先使用 `agent-browser-stealth` 的场景:
1. 目标站点存在挑战页/验证码/限流
2. 自动化链路对稳定性要求高
3. 需要长期回归验证与版本门禁
使用 `agent-browser` 的场景:
1. 低风控站点
2. 以基础自动化能力验证为主
---
## 5. 升级验证步骤
```bash
# 1) 检查版本
agent-browser -V
# 2) 关闭旧 daemon,避免版本漂移
agent-browser --session default close
# 3) 运行确定性回归
pnpm run check:turnstile-testkey
# 4) 可选:真实站点回归
agent-browser --wait-until domcontentloaded open https://www.anyviewer.com/cloudflare.html
```
如果启用域名白名单(`AGENT_BROWSER_ALLOWED_DOMAINS`),需包含 `challenges.cloudflare.com`
---
## 6. 结论
`agent-browser-stealth` 适用于高风控与稳定性敏感场景;`agent-browser` 适用于标准自动化场景。
选型建议按目标站点风控强度与回归要求决定。
项目地址:[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
+4 -2
View File
@@ -33,7 +33,7 @@ agent-browser pdf <path> # Save page as PDF
agent-browser snapshot # Accessibility tree with refs
agent-browser eval <js> # Run JavaScript
agent-browser connect <port|url> # Connect to browser via CDP
agent-browser doctor # Diagnose CDP + tab-group plugin health
agent-browser doctor # Diagnose CDP + sourceURL + tab-group plugin health
agent-browser --version # Show CLI version
agent-browser close # Close browser (aliases: quit, exit)
```
@@ -253,7 +253,8 @@ agent-browser console --clear # Clear console log
agent-browser errors # View page errors
agent-browser errors --clear # Clear error log
agent-browser highlight <sel> # Highlight element
agent-browser doctor # Diagnose CDP + plugin handshake status
agent-browser doctor # Diagnose CDP + sourceURL + plugin handshake status
pnpm run check:turnstile-testkey # Deterministic Turnstile smoke check (official test key)
```
## State management
@@ -310,6 +311,7 @@ agent-browser reload # Reload page
--auto-connect # Auto-discover and connect to running Chrome
--tab-group <name> # Base title for agent tab groups (CDP plugin mode)
--tab-group-plugin-id <id> # Expected extension ID for tab-group handshake
--wait-until <mode> # Navigation wait strategy for open/navigate (load, domcontentloaded, networkidle)
--debug # Debug output (includes stealth connection type + capabilities)
```