【开源评测】dots：自带浏览器的 Web AI Agent------C++ 级反检测路径的工程取舍与争议
专栏系列：Valhalla‑SafeNet 本周GitHub最热Top10独立评测 \#07
评测溯源 ：取证Commit 2ff9848c1c8a80460d89242d97beacf23dff05ca｜合规浅克隆静态取证，无运行实测、无线上业务验证
项目基础信息：feder-cr/dots｜Fork 435｜MIT商用友好｜主语言Python
作者：Valhalla Matrix治理实验室
摘要：dots 是 2026 年 9 月底快速蹿升的 Web AI Agent 项目，3 天斩获 2.4K Star。它的核心卖点并非模型能力，而是对"浏览器层"的深度改造------一条 C++ 引擎级反检测的技术路径。本文基于 commit 2ff9848 的静态取证，从技术架构、竞品对标、争议辨析、合规边界四个维度展开分析，给出可落地的选型建议。
@toc
一、Web Agent 的核心瓶颈：被忽视的浏览器层
当我们在讨论 AI Agent 的能力边界时，注意力往往集中在模型侧------推理能力、工具调用、上下文窗口。但真实场景中，一个 Web Agent 任务失败的原因，大概率与模型无关。
页面没有加载完成。验证码弹了出来。登录态失效了。点击没有落在目标元素上。 这些问题全部发生在浏览器层，在模型获得"思考"机会之前就已经决定了任务的成败。
更隐蔽的问题在于：现代反爬系统早已不再依赖单一的 navigator.webdriver 标志位。TLS ClientHello 指纹、CDP（Chrome DevTools Protocol）协议泄露、AudioContext 指纹、WebGL 渲染器信息------这些信号组合起来，可以在毫秒级内判定一个浏览器会话是否来自自动化工具。
dots 的解题思路就是从这个被长期忽视的层面切入的。
二、dots 技术深潜：C++ 引擎级反检测的实现路径
2.1 核心机制：在引擎层伪造指纹，而非 JS 注入
当前绝大多数 stealth 浏览器方案（如 playwright-stealth、puppeteer-extra-plugin-stealth）采用的手段是 JS 注入 ：在页面脚本执行之前，通过注入一段 JavaScript 覆盖 navigator 对象上的关键属性。
这种方法有一个根本性缺陷：JS 补丁本身可以被检测 。页面的反爬脚本可以通过 Function.prototype.toString() 检查函数是否被改写，通过属性描述符（descriptor）检查 getter/setter 是否原生，甚至通过 Object.getOwnPropertyNames() 枚举多余的全局变量。
dots 的技术底座------invisible-playwright-mcp（上游项目）------采用的是完全不同的路径：对 Firefox 引擎的 C++ 源码进行补丁，使指纹在引擎层面就已确定，而非在页面层被"涂改"。
具体来说，这个被 C++ 补丁的 Firefox 引擎实现了以下能力：
- 指纹由引擎生成：屏幕分辨率、字体列表、GPU 信息、时区、语言等参数在 C++ 层被设置，页面无法通过 JS 检测到"伪造痕迹"
- 零 WebDriver 标志：不暴露 DevTools 协议，页面中不存在任何自动化相关的全局变量
- 种子驱动的身份一致性 ：通过
--seed参数，每次运行可以复现同一套指纹组合，确保多次访问呈现"同一个人" - 人类行为模拟：指针移动轨迹逼近真实用户，键盘事件逐字符触发，页面接收到的是"可信事件"而非批量注入
- 持久化身份 ：
--profile-dir保留登录态和 Cookie，--proxy使时区和语言跟随出口 IP
2.2 架构分层与运行时
text
┌─────────────────────────────────────────────┐
│ dots CLI (wrapper) │ ← 20 行 cli.py
├─────────────────────────────────────────────┤
│ invisible-playwright-mcp (MCP Server) │ ← Web UI + Agent Loop
├─────────────────────────────────────────────┤
│ invisible_playwright (Python API) │ ← Playwright 替代层
├─────────────────────────────────────────────┤
│ firefox_antidetect_patch (C++ Binary) │ ← 核心：补丁 Firefox 引擎
└─────────────────────────────────────────────┘项目采用 Python 3.11+ 构建，通过 uv 管理依赖。安装方式简洁：
bash
# Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env
uvx --from git+https://github.com/feder-cr/dots dots --openrouter-key sk-or-...
# 启动后访问 http://127.0.0.1:8765
# 左侧对话，右侧实时浏览器视图模型侧支持 OpenRouter 上的任意模型，通过 --model 标志切换，默认使用 z-ai/glm-5.3-flash。
平台兼容性方面 ：当前支持 Windows x86_64 和 Linux x86_64/arm64，但 macOS 自 2026 年 8 月下旬起不再支持。这对 Mac 用户是一个硬性限制。
三、争议与真相：dots 到底是什么
3.1 一个被包装的入口
对 dots 仓库进行静态取证后，一个关键事实浮出水面：dots 本身不是一个独立项目。
该仓库的实际内容是一个约 20 行的 cli.py 和一个 pyproject.toml，后者以大写字母明确声明："THE WHOLE PRODUCT IS THIS LINE"------唯一有效的依赖是 invisible-playwright-mcp==0.70.2。整个 cli.py 的功能是转发 ui 子命令。
python
# src/dots/cli.py 核心逻辑（完整）
"""dots is invisible-playwright-mcp ui, and nothing else."""
import sys
SUBCOMMAND = "ui"浏览器引擎、Agent 循环、Web UI 和 MCP Server 全部位于同作者的兄弟仓库 feder-cr/invisible_playwright_mcp 中，该仓库本身是 2024 年病毒式传播的 LinkedIn 求职机器人 AIHawk 的改名重写版本。
3.2 时间节点的巧合
dots 仓库的首次推送时间为 2026 年 9 月 29 日 23:06 UTC，恰好在 OpenAI 同日 DevDay 发布同名 "dots" 产品之后。README 最后一行写着 "Not affiliated with OpenAI"，但这更像是刻意回应而非免责声明。
一个高度依赖上游包、仅提供 20 行包装的仓库，能够 3 天获得 2.4K Star，这个数字本身值得审慎看待。
3.3 如何理性评估
尽管存在上述争议，底层的 stealth 浏览器技术本身是当前开源社区对"Agent 频繁被验证码拦截"问题最严肃的回答之一。争议在于入口层的包装策略，不在于技术本身的价值。
理性路径是：直接使用上游 invisible-playwright-mcp，跳过 dots 这层包装。
四、横向对比：Web Agent 反检测方案选型矩阵
当前 Web Agent 浏览器自动化领域，反检测能力是核心竞争力之一。下表从反检测路径、开源模式、平台支持等维度进行横向对比：
| 维度 | dots / invisible-playwright | browser-use | Camoufox | Playwright + stealth |
|---|---|---|---|---|
| 反检测路径 | Firefox C++ 引擎补丁 | 云端 stealth + CDP 替代 | Firefox C++ 引擎级伪装 | JS 注入补丁 |
| 指纹一致性 | Seed 驱动，引擎级一致 | 依赖云浏览器 | 引擎级 | JS 覆盖，可被检测 |
| WebDriver 标志 | 无 | 云端方案无 | 无 | 需插件抹除 |
| 开源许可 | MIT | 开源 + 商业云服务 | 开源 | Apache 2.0 |
| 平台支持 | Windows / Linux | 全平台（云） | 全平台 | 全平台 |
| LLM 集成 | OpenRouter 任意模型 | OpenAI / 自研 BU2 | 需自行集成 | 需自行集成 |
| MCP 支持 | ✅ 原生 | 部分 | 通过 camofox-browser | 否 |
关键差异：browser-use 走的是"云端 stealth 浏览器 + 商业 API"路线，提供 $0.02/浏览器小时的云浏览器服务，集成了 CAPTCHA 破解和住宅代理。它的优势是开箱即用、全平台兼容，代价是依赖云服务。dots/invisible-playwright 则是纯本地、自托管的方案，强在指纹深度和一致性，但平台支持受限且需要自行维护。
对于 WebVoyager 等基准测试，browser-use 云端方案报告了 81%-93% 的 stealth 通过率（不同反爬系统下）。dots 未公开基准测试数据，建议在隔离环境中自行验证。
五、合规红线与落地建议
5.1 合规边界
浏览器自动化是一个法律敏感领域。以下红线需要明确：
- 目标站点 ToS 与 robots.txt：C++ 级反检测能力的本质是"不被检测"，但这不等于"可以无视规则"。任何自动化行为都应遵守目标站点的服务条款
- 高频抓取风险：反检测能力不应被用于大规模数据爬取，否则可能触发法律风险
- 敏感操作限制：登录、支付、个人信息提交等操作，必须在人工确认的前提下执行
- 许可合规：dots 为 MIT 许可，但 2026-09-02 之前的上游发布使用 AGPL-3.0 许可，商用前需确认具体版本
5.2 落地路径
第一步：验证技术可行性 在隔离环境（推荐 Docker 或专用 VM）中按 README 跑通核心流程。注意本文为静态取证报告，未经运行时实测。由于 macOS 不受支持，Mac 用户需通过 Linux 虚拟机运行。
第二步：评估替代方案 如果仅需要 MCP 集成，可直接使用 invisible-playwright-mcp，省去 dots 包装层。如果追求开箱即用和全平台支持，browser-use 云端方案更务实。
第三步：最小化权限 生产环境中，应限制 Agent 可访问的域名范围，敏感操作（登录/支付）强制人工确认，并建立操作日志审计机制。
六、趋势定位与总结
dots 的热度反映了一个更大的趋势：2026 年，AI Agent 的竞争重心正在从"模型能力"向"环境交互能力"转移。Google 在 Chrome 中集成 WebMCP 和 Auto Browse 功能，微软发布 Fara1.5 浏览器智能体，OpenAI 推出自己的 dots 产品------浏览器层的 Agent 化已是巨头共识。
在这个背景下，dots 的技术价值在于验证了 C++ 引擎级反检测 这条路径的可行性。它的争议在于包装策略，但底层 invisible-playwright-mcp 在 stealth 浏览器工程上确实提供了当前开源社区中较为深入的一种实现。对于需要在自托管环境中运行 Web Agent 且面临反爬挑战的团队，上游仓库值得关注和评估。
合规声明 ：本文结论基于 repos/dots @ 2ff9848 的浅克隆关键文件证据（
git clone --depth 1 --filter=blob:none --no-checkout --no-tags），经 Valhalla-SafeNet-Accelerator 合规审计。批次账本链头：df786ff13f801cb406becd20f0d58b27bb64e0d08c48a09f8e4c39b1a509e93a。未经运行时实测，建议读者在隔离环境中自行验证。
标签 ：#AI Agent #浏览器自动化 #开源评测 #反检测 #MCP