Camofox 反检测浏览器会话

问题：Agent 浏览器任务总被拦截

当你让 Agent 去操作一个被 Cloudflare、PerimeterX 或类似反机器人系统保护的网站时，问题通常不在模型的推理能力，而在浏览器层：

• 普通 Headless Chrome 缺少真实浏览器指纹，TLS/JA3 特征与用户代理不一致，触发风控。
• navigator.webdriver、HeadlessChrome UA、最小化的 WebGL 与字体列表都是常见检测点。
• 页面结构一旦变化，基于 selector 的自动化脚本立刻失稳；每次新会话 Cookie 与存储全丢，行为历史无法延续。

结果就是：任务跑到一半被 403 或 JS challenge 拦截，或者元素定位在 DOM 变动后静默失效。

这个技能做什么

它把 Agent 的浏览器任务路由到 Camofox Browser——一个反检测浏览器服务端，而不是直接驱动裸的 Puppeteer/Playwright。核心机制有三层：

1. 稳定的元素引用（stable element refs）：不依赖容易失效的 CSS/XPath 选择器，改用服务端维护的引用标识，快照（snapshot）后按引用操作元素，降低因 DOM 微调导致的定位漂移。
2. 会话状态持久化：Cookie、localStorage 等随会话保留，同一站点多次访问之间可以延续登录态与浏览历史，符合真实用户的访问模式。
3. 代理与会话隔离：每个会话绑定独立代理与浏览器上下文，避免多任务之间共享指纹、IP 或存储造成关联。

典型流程是：Agent 发起浏览器任务 → 请求经 Camofox 服务端 → 服务端以反检测浏览器执行 → 返回结构化快照（含稳定引用）→ Agent 基于快照决定下一步动作。

可选的 yt-dlp 依赖用于从视频页面提取字幕/转写内容，适合需要从 YouTube 等站点抓文本的任务。

适用边界与注意点

• 反检测能力取决于 Camofox 服务端本身的指纹质量与更新频率，技术侧无法保证绕过所有风控策略；高风险站点可能仍然返回 challenge 或直接拒绝。
• 需要预先准备 Camofox Browser server（自建或托管），以及 Node.js 或 Docker 运行环境；本技能只解决"如何通过反检测会话跑任务"，不包含服务端的搭建细节。
• 快照驱动的模式意味着 Agent 看到的是某一时刻的页面快照，对高度动态、依赖 WebSocket 实时渲染的页面，引用有效性需要额外验证。
• 代理质量直接影响会话的可信度：共享或低信誉代理会抵消会话隔离的效果。
• 使用反检测浏览器访问站点时，仍需遵守目标站点的条款与当地法规；技术能力不等于访问授权。