在 Claude Code 或者 Cursor 里， GitHub 链接发给 Agent，让它自己装就行。不用你动手。
爬虫任务都交给 Claude Code和豆包
BrowserAct（browseract.ai，官网也叫 browseract.com）一句话概括
它是给 AI Agent 配套的云浏览器运行时（MCP/API 层），专门解决 Claude Code、Hermes、Cursor 这类 AI 代理 “没法稳定操作登录态网站、反爬、验证码” 的问题BrowserAct。
不是大模型，不是代码 Agent；是 AI Agent 的浏览器手脚。
核心定位
普通的 Playwright / Puppeteer / Browserbase 只是浏览器底层；BrowserAct 往上多了一套面向 AI Agent 的Skill（可复用网页任务）、账号隔离、人机接管能力。
- 支持 MCP 协议：Claude Code 可以直接调用它，让 AI 去打开网页、点按钮、填表单、采集数据
- 云托管浏览器实例，自带隐身指纹、住宅代理、自动处理 Cloudflare / Turnstile /reCAPTCHA
- 多账号隔离：每个账号独立浏览器指纹、Cookie、代理，互不串号
- Human Handoff（人工接管）：遇到 2FA、复杂验证时，可以暂停 AI，人远程接手操作，做完交还 AI 继续跑任务BrowserAct
- Skill Forge：把一次性网页操作，打包成可复用的 “Skill”，下次 AI 直接复用这套流程，不用重新推理页面结构
两种使用模式
- MCP/API 接入（开发者模式，适合你现在的场景） 把 BrowserAct 作为工具插件接入 Claude Code，你的 AI 工程 Agent 就拥有网页操作能力：爬取需要登录的后台、网页端数据采集、监控页面、填表。
- 无代码 Bot（BrowserAct Cloud） 自然语言描述要采集什么数据，平台自动生成网页机器人，输出 JSON / CSV，适合快速做网页数据抽取，不用写选择器、脚本BrowserAct。
和你前面关心的 Claude Code 的关系
Claude Code 擅长读代码、改项目，但原生没有稳定的浏览器能力，遇到 Cloudflare、登录态网站很容易失败。 BrowserAct 就是补这一层：Claude Code（大脑） + BrowserAct（浏览器手脚），这也是他们官方主推组合栈BrowserAct。
和同类工具对比（简单区分）
- Playwright：本地代码库，自己写脚本，没有账号隔离、代理、验证码、人工接管，需要自己维护
- Browserless：托管 Headless 浏览器基础设施，偏底层
- BrowserAct：面向 AI Agent 的工作流层，重点是 MCP、Skill、多账号隔离、人机切换
- BrowserUse：开源 Python 框架，本地 / 自建为主
⚠️ 适用边界 & 风险提示
- 主打受保护网站、需要登录、动态页面的数据采集与网页操作；公开静态页面没必要上它
- 本质网页自动化，必须遵守目标网站的用户协议、爬虫法规，不要用于违规批量注册、恶意操作账号
- 海外云服务，国内网络访问会有问题；按会话、代理流量计费
对你（数字孪生 + 数据采集创业）的价值
如果你要做网页端数据源采集（需要登录、反爬网站），可以用 Claude Code + BrowserAct MCP： AI Agent 自主规划网页采集流程，遇到验证自动暂停转人工，采集结果结构化输出，接入你的时序库（TDengine/DuckDB）。 如果只是采集公开 API、静态网页，完全没必要上 BrowserAct。
如果你想，我可以给一段 MCP 配置，让 Claude Code 直接调用 BrowserAct。
网站的风控，封ip
核心痛点：IP 封禁本质就两类
- 单 IP 请求频率过高 → 短期限流、429
- IP 画像差（机房 IP / 数据中心 IP）→ 直接拉黑，Cloudflare/Turnstile 秒弹验证 住宅代理 > 机房代理 > 本机 IP，这是爬虫圈共识。但代理只是其中一环，只换 IP 照样翻车。
几种主流方案对比（结合你之前关注的 BrowserAct / Claude Code 场景）
1. 住宅代理池（BrowserAct 云端自带）
优点：
- 真实家庭宽带 IP，画像干净，对抗 Cloudflare、网站风控效果最好
- BrowserAct 云端模式自动绑定独立 IP，每个任务 / 账号隔离，不会串 Cookie+IP 缺点：
- 成本高，按 GB / 流量计费；不适合大规模长期采集
- 依赖服务商，不能离线；服务商本身也会被网站风控，有失效风险
- 适合：低频、需要登录、带验证码的网页采集（正好是 BrowserAct 擅长场景）
局限：住宅代理不是万能。同一个 IP 短时间大量请求，照样会被封。IP 轮换 + 请求间隔 + 指纹 + Cookie 隔离必须一起上。只换 IP 不换指纹，网站照样识别你是爬虫。
2. 机房代理（Datacenter Proxy）
优点：便宜、带宽大、稳定 缺点：IP 特征非常明显，绝大多数网站直接标记为机房 IP，Cloudflare 基本拦死。适合静态公开页面，带反爬的网站慎选。
3. 自建代理池（例如芝麻、阿布云这类，或者自己一堆 VPS）
优点：可控，不绑定第三方 SaaS 平台，可以和本地 BrowserAct CLI / Playwright MCP 搭配 缺点：
- 维护成本高：IP 存活检测、自动剔除失效 IP、限速策略全部自己写
- VPS 基本都是机房 IP；自建住宅代理门槛极高（很难拿到大量家庭宽带 IP）
4. 本地 IP 轮换（本机多宽带 / 4G/5G 手机卡池）
优点：IP 最真实，风控最难识别 缺点：硬件成本巨大，扩展性差，不适合自动化大规模跑任务
除 IP 之外，容易被忽略的风控维度（爬虫踩坑重灾区）
网站风控是多维指纹，不是只看 IP：
- 浏览器指纹：UserAgent、Canvas、WebGL、字体、插件、屏幕分辨率、时区、语言。同一个 IP，每次指纹完全一样，很容易被标记。
BrowserAct 云端自带指纹随机化；本地 BrowserAct CLI / Playwright 默认指纹固定，必须额外用
playwright-stealth之类插件。
- Cookie & 账号：Cookie 和 IP 不匹配（比如 Cookie 是上海 IP 登录，下一次请求 IP 跳到美国），直接触发验证。这就是为什么要账号、Cookie、IP 三者绑定隔离。
- 请求行为特征：人浏览网页有停顿、鼠标移动、滚动；无头浏览器请求是瞬间完成，没有人机行为。
- 请求头顺序、TLS 指纹：很多网站会校验 JA3 指纹，Playwright 默认 JA3 指纹很容易识别。
结合你的场景：AI Agent 爬虫（Claude Code + BrowserAct）
- 如果用 BrowserAct 云端：它帮你搞定：住宅 IP、浏览器指纹、Cookie 隔离、验证码、人机行为模拟。代价是流量费 + 依赖外网，不能离线。适合小批量、复杂登录页面采集。
- 如果用 本地 BrowserAct CLI（离线模式，不连 BrowserAct 云）：IP 问题你要自己解决：代理池、指纹插件、IP 轮换策略全部自己开发维护。本地版本不会帮你处理 IP，原生就是本机 IP，高频访问很快封 IP。
工程上的稳妥策略（做数据采集系统可以直接落地）
- 限速：不要无脑并发，每个 IP 设置最大 QPS，增加随机等待；
- 隔离：1 账号 = 1Cookie = 1IP，不要混用；
- 降级：一旦遇到 429 / 验证，立刻暂停，把这个 IP 标记失效，自动切备用 IP；
- 监控：采集失败率、验证码出现率，作为 IP 池健康指标；
- 分层：公开静态页面用低成本机房代理；登录 + 强反爬页面才用住宅代理，节约成本。
取舍提醒
没有一劳永逸的方案。IP 封禁是博弈，不是一个技术点就能彻底解决。网站风控规则会持续迭代。 如果你是做产品化的数据采集（创业项目）：
- 自建代理池 + Playwright / 本地 BrowserAct：前期开发工作量大，长期成本可控；
- BrowserAct 云端：快速验证业务原型，但规模化后流量成本会很高。
