828 星小项目，给浏览器装上一个不被拦截的AI代理

先说结论

feder/dots 想做的事情很直白：给AI代理配一个专属浏览器，让它去读网页、点按钮、填表单时，不会被网站当成机器人一脚踢开。一周 828 颗星，说明这件事戳中了一批做自动化、做爬虫、做 Agent 的人的真实痛点。

但它不是万能钥匙。它解决的是“浏览器层面的指纹和检测”，不解决“验证码背后的业务规则”。该拦你的，照样拦你。

真正的问题

网上做浏览器自动化的人，这两年最头疼的不是“能不能点”，而是“点两下就被识别”。Cloudflare 的质询、Akamai 的拦截、各家风控的指纹比对，统统针对的是 headless 浏览器和自动化脚本。

普通的 Playwright、Selenium 跑起来确实方便，可一旦访问频率上来，或者目标站点风控紧，几分钟就返回 403。要么换代理 IP，要么改指纹，要么干脆上 stealth 插件，改来改去还是被动。

dots 想把这套活儿封装成一个开箱即用的方案：自带的浏览器、AI代理可以直接接管、自然语言描述任务就行。它把“反检测”和“代理执行”绑在一起卖。

怎么做更省力

如果决定上手 dots，思路要分三步走，避免一上来就跑复杂流程。

第一，先在本地或容器里把基础环境跑通。Python 装好，依赖补齐，能打开一个示例页面就算成功。这一步是确认“它在我的机器上能起来”，而不是“它能不能干我的活”。

第二，挑一个低风险的目标做实验，比如公开的商品列表、公开的招聘信息、可匿名访问的文档站点。先别碰登录态、别碰验证码、别碰高频请求。观察 dots 在普通反爬下的表现，记录哪些页面成功、哪些页面失败，失败时报错长什么样。

第三，再把任务接入AI代理流程。dots 的设计初衷是让代理用自然语言描述需求，再由浏览器去执行。这一步要控制变量：先固定一个站点、固定一种操作、固定一种输出，别一次性跑十种业务。

整个过程，重点不是“能不能跑”，而是“失败时你能不能看见原因”。日志、截图、请求链路，必须留痕。

哪些坑要避开

一是把它当爬虫用。dots 主打的是 Agent 场景，AI代理需要“看页面、思考、下一步”。单纯高速抓取，用它反而绕远，性能和稳定性都不如专门的数据采集方案。

二是忽略合规和边界。开源不等于可以随便爬。目标站点的 robots.txt、用户协议、当地法规，照样要遵守。一旦涉及登录态、个人数据、付费内容，风险会迅速放大。

三是迷信“永远不被封”。反检测是攻防战，今天有效不代表明天有效。Cloudflare、Akamai 这些厂商也在持续升级。dots 当前能跑通的页面，下次更新可能就拦你。

四是用在错误的场景。它适合“需要AI理解页面 + 操作浏览器”的任务，例如自动填表、跨站点流程串联、辅助研究。如果只是抓静态 HTML，自己写脚本更直接。

现在就能动手

先想清楚自己的目标：是要做AI Agent 工作流，还是单纯要抓数据。如果是前者，dots 这种自带反检测的浏览器代理值得花半天试一下；如果是后者，老老实实用 requests 或 Playwright 基础版。

动手前，先把测试页面、测试动作、成功判定写下来。例如“访问某公开页，提取标题列表，连续 5 次成功率 80% 以上”。不要“跑一下看看”，那是给自己挖坑。

跑通后，再决定要不要纳入长期方案。这一周 828 颗星说明社区在关注，但 GitHub 星数和项目能不能稳定维护是两件事。先用小任务验证，再逐步扩大范围，比一上来就 All in 稳妥得多。