你花3小时调好一个AI Agent，让它自动刷GitHub Trending、帮你跟X粉丝互动。30秒后，被封了。
或者更烦的：Agent每次重启，上次辛苦登录的X账号又没了。一查日志，Token消耗比预期多了10倍——因为底层传回来的是整页HTML，95%是噪声。
不是Agent不够聪明，是浏览器方案选错了。
[divider:1]
先说背景
2026年6月Cloudflare Radar数据：全球网页请求中机器人流量占比57.5%，首次超过人类的42.5%。
网站反爬在加速进化，今天能过的检测三个月后可能就封了。你的Agent能不能活下来，取决于浏览器方案在哪个层级做对抗。
Agent用浏览器，到底在解决什么问题
传统浏览器自动化——爬虫、E2E测试——人在写代码，目标明确，跑一次就完。Agent不一样，任务模糊、要自主决策、一个任务跑十几分钟、每步都烧Token。
所以Agent的浏览器方案必须回答5个问题：
- ==信息密度==——喂给LLM的页面里有多少噪声？Token烧不烧得起？
- ==检测对抗==——能不能过反爬？活3秒还是3小时？
- ==身份一致性==——能不能保持登录？明天再跑还是同一个身份吗？
- 可观测性——Agent知道自己看到了什么吗？
- 任务粒度——一次能跑多少步？成本可控吗？
下面先看4种主流路线怎么做的，再说我的选择。
[divider:2]
4条路线，各有利弊
| 路线 | 代表 | 思路 | 致命短板 |
|---|---|---|---|
| MCP Browser | Playwright MCP | AI通过协议调浏览器 | 底层裸Chromium，零反检测，无持久化 |
| Agent框架内置 | Browser Use、Devin | 浏览器是核心 | 还是Chromium那套，指纹问题照旧 |
| Computer Use | Claude、OpenAI Operator | 截屏+鼠标键盘模拟人 | 慢且贵，精度差，Token消耗5-10倍 |
| 自建浏览器服务 | Steel.dev、CamoFox | REST API自行集成 | 基础设施负担大 |
路线A（MCP）——Cursor里让AI查个文档，够用。想让AI自动操作X/Twitter这种重活，Playwright MCP在严格平台撑不过几秒。Browserbase、Stagehand也是Chromium，只是把"在哪跑"云化了，根本问题没解决。
路线B（Agent框架内置）——Browser Use（97.7K Stars）的DOM索引做得好，但底子还是Playwright。反爬系统看的是"这是不是Chrome 144 + HeadlessChrome + webdriver=true"——走Chromium的路子都很难绕开。
路线C（Computer Use）——截屏+坐标点的思路天然像人，反检测独一档。但一次操作至少一张截图+一次LLM推理，Token烧得是DOM方案的5-10倍，长任务经常中途漂移。OpenAI Operator至今没开放API，原因之一就是跑起来太贵。
路线D（自建）——用Camoufox库或Steel.dev自己搭。代价是基础设施负担大，好处是自己说了算。
[divider:3]
核心差距一：Token烧不烧得起
不同方案喂给LLM的内容，信息密度差距多大（同一Wikipedia页面实测）：
| 方案 | 大小 | 信息密度 |
|---|---|---|
| 裸 HTML | ~16K chars / ~4K tokens | ~5% |
| Browser Use DOM 索引 | ~3.5K chars / ~900 tokens | ~28% |
| Playwright 输出 | ~5K chars / ~1.3K tokens | ~18% |
| ==CamoFox Accessibility Snapshot== | ==~1.6K chars / ~400 tokens== | ==~70%== |
CamoFox返回的是无障碍树——只有语义化标签和文本，没有CSS/JS噪声。屏幕阅读器读什么，LLM就读什么。
一个30步的任务，HTML方案要12万Token，CamoFox只要1.2万。按Claude 3.5 Sonnet算，==单次任务从3.6美元降到0.36美元==。
说实话这个差距挺吓人的，长期跑下来成本差别非常大。
[divider:4]
核心差距二：能不能过反爬
大多数人第一次接触反检测，都是JS层补丁——puppeteer-extra-plugin-stealth。能过60%基础检测。
但JS补丁只改了值，没改关系。浏览器指纹有16+个维度（Canvas、WebGL、AudioContext、WebRTC、字体、时区……），关键是所有维度必须内部一致。你声称Windows但字体列表全是macOS的，一条就给你封了。
==JS改得了值，改不了C++引擎的指纹。== Chromium编译时就把这些信息写死了。
Camoufox的做法比较狠：直接fork Firefox源码，在C++层动手脚。初始化时注入，JS跑之前就生效，检测脚本根本找不到破绽。代价是编译一次30多分钟，几GB的C++ patch——JS层想做到这个，没门。
Cloudflare实测数据：
- Playwright + stealth插件：~5%
- Playwright + 高端代理：~25%
- Multilogin等商业方案：~70%
- ==Camoufox默认配置：~85%==
- ==Camoufox + 住宅代理：~95%==
说实话裸Playwright 5%的过检率基本等于不能用。
[divider:5]
核心差距三：能不能记住登录
这个才是让Agent无法真正商用的坎。
Cloudflare的clearance cookie只有30分钟有效期，而且绑定浏览器指纹。指纹变了，cookie立即失效。X/Twitter也一样——指纹变化=异常登录=封号。
Playwright的storageState只保存cookies和localStorage到JSON，不保存IndexedDB、WebGL状态。你存了cookie，下次换个指纹的浏览器加载，Cloudflare一样拦你。
CamoFox的做法：==每个Profile对应一个完整的Firefox用户数据目录==，cookies、localStorage、IndexedDB全部持久保存，指纹也绑着Profile——同一个Profile每次启动用的是同一套指纹，WebGL厂商、分辨率、时区全部一致。
多Profile=多身份，互相不搭界。没有这个能力，Agent每次操作认证网站都是一场赌博。
综合对比
| 方案 | 信息密度 | 检测对抗 | 身份一致性 | 可观测性 | 任务粒度 |
|---|---|---|---|---|---|
| Playwright MCP | ⭐⭐ | ⭐ | ⭐ | ⭐⭐ | ⭐ |
| Browser Use | ⭐⭐⭐ | ⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| Computer Use | ⭐ | ⭐⭐⭐ | ⭐ | ⭐ | ⭐ |
| CamoFox | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
说明一下，这表是基于我自己项目经验的判断，不构成客观评测。Browser Use的DOM索引在简单页面上比CamoFox还紧凑；Computer Use在反检测维度上独一档。CamoFox最核心的优势是==5个问题没明显短板==——生产环境里，Agent崩溃的代价远大于"某个维度没做到第一"。
[divider:6]
诚实说缺点
-
还在早期阶段——Camoufox 9K Stars，CamoFox 6.5K Stars（截至2026年6月），社区规模跟Playwright差距大，遇到问题大概率自己改源码。
-
交互式Cloudflare挑战仍是硬限制——非交互式能过，但Turnstile（要人机验证的）所有自动化方案都力不从心，主流做法是接打码平台。
-
Firefox兼容性——少数网站只测Chrome，Firefox下可能异常。消费级网站大致OK，企业内网系统要小心。
为什么我选了CamoFox
我的场景：长期任务的AI Agent，严格反爬网站，多账号，Token成本可控。CamoFox在这个场景里5个问题都没有明显短板。
跟Browser Use不在同一赛道——Browser Use解决"理解层"，CamoFox解决"生存层"，可以组合使用。
适合需要长期稳定运行的Agent。不适合一次性demo、企业内网、纯视觉驱动。
试CamoFox成本不高：
pip install camoufox
或者Docker一键跑：
docker run -p 9377:9377 camofox-browser
你被封过几次？用了什么方案？评论区说说，我帮你分析。
我是程序员零一，关注我了解最新AI动态和开源项目资源