Detail agent stealth Cloudflare fix
This commit is contained in:
leeguooooo
@@ -0,0 +1,189 @@
|
||||
# 从「能跑」到「长期稳定」：agent-browser-stealth 的攻防工程实践
|
||||
|
||||
高风控站点对自动化会话的判断，通常不是单一规则命中，而是多信号打分。
|
||||
要点不在“补一个 patch”，而在“让整组信号在同一会话内自洽”。
|
||||
|
||||
项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
|
||||
|
||||
---
|
||||
|
||||
## 检测系统如何做判断
|
||||
|
||||
大多数检测系统会同时看三类问题：
|
||||
|
||||
1. **一致性**：UA、语言、时区、渲染能力是否互相匹配
|
||||
2. **稀有性**：是否出现低频但高度可疑的组合（如某些 headless 特征并存）
|
||||
3. **时序性**：输入、点击、等待、重试是否呈现机械节奏
|
||||
|
||||
评估通常是累积分值而非二元判断。
|
||||
同一个会话里的轻微异常可以被容忍，但跨维度冲突叠加后，容易触发挑战页或高频二次验证。
|
||||
|
||||
```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["执行时序"]
|
||||
C --> F
|
||||
D --> F
|
||||
E --> F
|
||||
```
|
||||
|
||||
### 输入节奏
|
||||
|
||||
固定字符延迟（例如全程 100ms）很容易形成可分辨模式。
|
||||
更稳妥的做法是“基线 + 抖动 + 语义停顿”：
|
||||
|
||||
- 基线延迟围绕输入场景变化
|
||||
- 每字符有扰动，不保持等间隔
|
||||
- 词边界、字段切换处出现较长停顿
|
||||
|
||||
### 鼠标轨迹
|
||||
|
||||
坐标瞬移与恒速直线是高风险模式。
|
||||
轨迹应包含：
|
||||
|
||||
- 曲线路径
|
||||
- 中间采样点
|
||||
- 速度变化（起步、调整、收敛）
|
||||
|
||||
### 等待与思考时间
|
||||
|
||||
固定等待常量会形成明显周期。
|
||||
建议使用区间采样，让同类操作在时间上有自然波动。
|
||||
|
||||
### 重试退避
|
||||
|
||||
命中风险后继续等间隔重试，通常会放大风险分值。
|
||||
退避策略应具备：
|
||||
|
||||
- 间隔递增
|
||||
- 抖动扰动
|
||||
- 次数上限
|
||||
|
||||
### 行为反模式
|
||||
|
||||
- 全链路固定输入延迟
|
||||
- 点击前无移动直接命中目标
|
||||
- 所有等待都是同一个常量
|
||||
- 重试间隔完全一致
|
||||
- 所有站点使用同一动作模板
|
||||
|
||||
---
|
||||
|
||||
## 2026-03 实战更新：Cloudflare 验证页恢复策略
|
||||
|
||||
在真实使用中，`dash.cloudflare.com` 一类站点常见 `Just a moment... / Performing security verification` 挑战页。
|
||||
关键问题不只是“被识别”，还包括“客户端过早刷新把挑战流程重置”，导致长期卡在验证中。
|
||||
|
||||
本次修复的关键点：
|
||||
|
||||
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. **挑战窗口友好化**：减少过早刷新导致的挑战重置
|
||||
让验证流程有足够时间自动完成，降低反复卡住的概率。
|
||||
|
||||
---
|
||||
|
||||
## 结语
|
||||
|
||||
指纹治理的重点是跨维度一致性。
|
||||
行为治理的重点是时间分布去机械化。
|
||||
把这两部分统一治理，通常能显著降低攻防波动。
|
||||
|
||||
项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
|
||||
@@ -0,0 +1,105 @@
|
||||
# 使用 agent-browser-stealth 代替 agent-browser
|
||||
|
||||
很多人已经把 AI Agent 接入了浏览器自动化，但上线后会遇到同一个问题：
|
||||
|
||||
同样流程在不同网站表现不一致；流程写完了，关键站点还是过不去。
|
||||
|
||||
问题通常不在“会不会自动化”，而在“能不能在真实网站里稳定自动化”。
|
||||
|
||||
这就是为什么要从 `agent-browser` 升级到 `agent-browser-stealth`。
|
||||
|
||||
项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
|
||||
|
||||
---
|
||||
|
||||
## 为什么要替换
|
||||
|
||||
### 1) 让 AI 真正可以使用浏览器
|
||||
|
||||
很多网站已经有反爬和自动化检测策略。
|
||||
在这些场景里，传统自动化链路会出现高频验证、中断、重试失败，最终让 AI 任务卡在关键步骤。
|
||||
|
||||
`agent-browser-stealth` 的目标很明确：让 AI 在真实网站环境中保持更高可用性。
|
||||
|
||||
### 2) 应对“限制 AI 浏览器”的站点策略
|
||||
|
||||
部分站点会对自动化浏览器做额外限制，包括：
|
||||
|
||||
- 触发挑战页
|
||||
- 关键页面二次验证
|
||||
- 会话中途降权或限流
|
||||
|
||||
`agent-browser-stealth` 提供更完整的防识别能力，降低这类限制对任务成功率的影响。
|
||||
|
||||
### 3) 让 Agent 和用户共享同一个浏览器
|
||||
|
||||
很多自动化失败发生在“登录前后状态切换”环节。
|
||||
`agent-browser-stealth` 支持 Agent 复用用户正在使用的浏览器会话，直接继承已登录状态，减少重复登录和验证码干扰。
|
||||
|
||||
对业务流程的价值是直接的：
|
||||
|
||||
- 缩短执行路径
|
||||
- 降低登录步骤失败率
|
||||
- 提升整体成功率与执行速度
|
||||
|
||||
---
|
||||
|
||||
## 典型站点效果（示例）
|
||||
|
||||
以亚马逊这类高风控电商站点为例，很多 AI 浏览器流程过去常见的问题是：
|
||||
|
||||
- 能打开首页，但关键操作前触发验证
|
||||
- 搜索、跳转、加购这类连续动作中途被打断
|
||||
- 会话偶发失效，任务难以完整执行
|
||||
|
||||
切换到 `agent-browser-stealth` 后，可显著提升这类流程的可执行性，常见可完成动作包括：
|
||||
|
||||
- 商品搜索与详情浏览
|
||||
- 购物车相关操作
|
||||
- 已登录状态下的页面导航与信息读取
|
||||
|
||||
除了电商站点，下面两类场景也常见明显改善：
|
||||
|
||||
- 社媒/内容平台：多步骤跳转流程更稳定
|
||||
- SaaS 后台系统：登录后连续操作中断率降低
|
||||
|
||||
说明：不同账号状态、网络环境、站点实时策略会影响最终效果。
|
||||
|
||||
---
|
||||
|
||||
## 适合哪些场景
|
||||
|
||||
- AI 客服或运营 Agent 需要在多站点执行后台操作
|
||||
- 自动化流程经常卡在登录、验证、跳转环节
|
||||
- 需要“人机协同”：用户和 Agent 共用一个会话处理复杂任务
|
||||
- 对稳定性要求高的生产任务（不是 Demo）
|
||||
|
||||
---
|
||||
|
||||
## 迁移成本高吗
|
||||
|
||||
迁移成本通常很低，命令习惯可以保持一致。
|
||||
多数场景可以先做“无侵入替换”，再按业务流程逐步优化。
|
||||
|
||||
---
|
||||
|
||||
## 一张表看差异
|
||||
|
||||
| 维度 | agent-browser | agent-browser-stealth |
|
||||
| --- | --- | --- |
|
||||
| 目标 | 标准自动化能力 | 面向真实风控环境的稳定自动化 |
|
||||
| 站点兼容性 | 普通站点可用 | 高风控站点可用性更高 |
|
||||
| AI 执行稳定性 | 受验证页影响明显 | 对验证/限制策略更稳 |
|
||||
| 登录链路 | 常需重复处理登录步骤 | 支持复用用户浏览器状态，减少登录干扰 |
|
||||
| 生产可用性 | 适合基础自动化 | 更适合生产级 AI 浏览器任务 |
|
||||
|
||||
---
|
||||
|
||||
## 结论
|
||||
|
||||
如果目标是“让 AI 在真实网站里稳定完成任务”，`agent-browser-stealth` 是更合适的选择。
|
||||
如果目标只是“脚本在理想环境跑通”，`agent-browser` 已经足够。
|
||||
|
||||
在生产环境里，真正的差异通常体现在四个字：**可用与稳定**。
|
||||
|
||||
项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
|
||||
@@ -50,6 +50,8 @@ export AGENT_BROWSER_SESSION_NAME=twitter
|
||||
agent-browser open twitter.com
|
||||
```
|
||||
|
||||
If `--session-name` is omitted, it defaults to `--session` (or `default`).
|
||||
|
||||
State files are stored in `~/.agent-browser/sessions/` and automatically loaded on daemon start.
|
||||
|
||||
### Session name rules
|
||||
|
||||
Reference in New Issue
Block a user