【开源评测】dots：自带浏览器的 Web AI Agent——C++ 级反检测路径的工程取舍与争议

TunerT_TQ
0 阅读6分钟

【开源评测】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 架构分层与运行时

┌─────────────────────────────────────────────┐
│              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 管理依赖。安装方式简洁：

# 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 子命令。

# 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-playwrightbrowser-useCamoufoxPlaywright + 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

avatar
文章
阅读
粉丝