实测 AI 访问：浏览器智能体难辨人机

AI 代理替人打开网站后，流量统计还能认出它吗？Privatrak 团队把 23 种 AI 代理、聊天机器人和开发工具送进同一个测试站，发现多数浏览器代理会被当成普通访客：Chrome 标识正常，不报告自动化，有些甚至直接使用用户家里的 IP。

这次实验最有用的发现，是点击前的鼠标轨迹比点击速度更能区分代理和人。但它也留下一个边界：不点击、直接读完页面的代理，依然可能被统计成「打开就走」的人。

为什么普通 Chrome 和家庭 IP 都靠不住

作者在 2026 年 10 月 26 日完成测试，记录了 49 次运行，覆盖 23 种 AI 代理、聊天机器人和工具，以及 8 种真人操作配置。真人侧共运行 10 次，包括鼠标、触控板、手机和两种 macOS 辅助操作工具。

测试站是一个虚构笔记应用，只有首页、套餐页和联系页。任务统一：查 Team 套餐月费、是否包含 SSO，再查看联系表单要求填写什么，不提交。SSO 答案藏在默认折叠的比较表里。每次运行使用独立地址，服务器记录请求，页面脚本记录浏览器特征和点击过程，不读取表单输入。

常见识别方法会检查 navigator.webdriver、User-Agent 和数据中心 IP。这三项在许多代理身上都失效了。

ChatGPT Work 在作者 Mac 上运行 Chrome 156，报告 webdriver: false，使用正常 Chrome 标识、当地时区、显卡信息和家庭 IP。窗口只有 319 像素宽，整次访问耗时 11 至 21 秒，但 Google Analytics 和 Privatrak 都把它算成人。

Claude in Chrome 更直接：它操作的就是用户自己的浏览器，版本、扩展和 IP 都一样。Comet 在本地运行时使用 Chrome 145，也不声明 Perplexity 身份。普通 Playwright 脚本会报告 webdriver: true，Playwright MCP 却关闭了这个标识；Browser Use 同样看起来像普通 Chrome。

家庭 IP 只能说明请求从哪里出来，不能说明是谁在操作。

Comet 还展示了另一层不确定性：同一任务运行 6 次，3 次使用本地浏览器，3 次使用云端浏览器。两项任务同时启动时，第一项走本地，第二项走云端。产品自己解释的调度规则与实际记录并不吻合，作者没有确认真正原因。

明确声明身份的产品也有。Claude Cowork 使用 HeadlessChrome/153，报告自动化并从 Anthropic 服务器访问；agent-browser 和 Chrome DevTools MCP 也报告 webdriver: true。Manus 则在 User-Agent 中加入 Manus-User/1.0，并发送 Signature-Agent: "https://api.manus.im" 和密码学签名，采用仍属 IETF 草案的 Web Bot Auth。它是测试中唯一签署页面请求的代理。

没有点击，为什么不等于没有读完

对流量分析来说，需要先分清两条访问路径。

一条是浏览器访问。页面脚本会执行，统计工具能够收到访问记录，但代理可以不进行任何可见交互。

Grok 直接输入套餐页和联系页地址，读取了屏幕上仍然折叠的表格，没有点击、滚动或鼠标移动。Manus 也在 21 秒内通过输入地址访问了三个页面，全程没有这些交互。

对统计系统来说，这像是一个匆匆离开的访客；对用户来说，查询任务可能已经完成。

这里原文有一处需要保留疑问：作者先说所有完成任务的代理都回答每月 €9、不含 SSO，后面却说 Grok 自行算出了月费 €10.80。原文没有解释差异，不能替它认定两者都正确。

另一条路径是服务器抓取。多数聊天机器人收到链接后，只从服务器获取页面，不运行脚本。因此，前端统计看不到它们，服务器日志却能看到，且通常能从 User-Agent 识别身份。作者建议关注 ChatGPT-User、Claude-User 和 MistralAI-User 等请求。

但「读取服务」也不一定只下载 HTML。Jina Reader 使用数据中心里的无头 Chrome，执行了页面脚本；DeepSeek 使用 Linux 上的 Firefox 149，从香港 Huawei Cloud 地址访问，语言为中文、时区为香港，不到 3 秒便离开，也没有声明机器人身份。两者都会成为统计里的单页无交互访问。

反过来，有些工具甚至没有成功访问指定内容。Perplexity 的 PerplexityBot/1.0 两次读取 robots.txt 后去了空白起始页；另一次声称页面没有可读内容，服务器却没收到任何请求。

因此，代理回答「打不开」，也不一定代表你的页面真的无法读取。

鼠标轨迹为何比点击速度更有用

作者最初测量按钮从按下到松开的时间，希望找到自动化特征，但这个指标没有覆盖所有代理。

Browser Use 和本地 Comet 会像人一样按下、等待、松开；云端 Comet 则只保持 10 至 13 毫秒。同一个产品，换个执行环境，行为就不同。

真正覆盖测试中全部 13 类点击代理的，是点击前的指针移动方式。真人点击前通常有连续的小幅移动，最后一步为 0 至 2 像素；代理往往让指针一次跳跃 200 至 840 像素，直接落到目标上，或者指针第一次出现就在目标位置，其他时间几乎不动。

这也覆盖了 Claude computer use。它通过截图理解屏幕，再经操作系统点击，测试环境是 Docker 中的 Linux 桌面，使用 xdotool，并非只依赖 Chrome 远程控制。

但不能把「大幅跳跃」单独当判据。作者用触控板快速划动，也产生过一次 701 像素位移。可疑之处是跳跃恰好落在随后点击的目标上，并且整页缺少其他移动。

其他信号同样有反例：点击正中心可能来自真人；ChatGPT Work 和 Comet 的点击压力为 0，Playwright 工具却报告鼠标常见的 0.5；检测远程控制的控制台技巧，在此次覆盖的 Chrome 136 至 156 中都没有生效。

辅助工具更能说明误判风险。macOS Voice Control 的点击精确落在中心，按压不足 1 毫秒，压力为 0，没有鼠标移动；Dwell 的按压时间只有 0 至 3 毫秒，但指针由人移动，并在目标上停留约 3 秒。

只按「快、准、没有移动」过滤，可能先过滤掉依赖辅助工具的人。

Privatrak 因而准备采用组合规则：页面上的每次鼠标点击都由单次跳跃抵达目标，且几乎没有其他移动，才标记自动化。浏览器只上报是否自动化，不上传轨迹。回放现有记录时，这条规则识别了全部点击代理，也没有标记真人；不点击的代理仍然无法覆盖。

我的判断

这篇最可靠的价值，是用同站、同任务的记录，证明「代理访问」不能只看 User-Agent，也不能只看前端埋点。对维护文档站、产品官网和套餐页的团队，这比再加一条 IP 黑名单更有参考意义。

不过，它验证的是一组样本里的区分效果。一个站点、一天测试、每种代理 1 至 6 次，真人操作又大多来自作者团队，远不足以证明鼠标规则在真实流量中具有稳定准确率。作者没给生产环境误报率，也没给其他检测方案的对照数据，暂时只能把它视为有记录支持的经验规则。

规避门槛也很明确：代理只要沿路径分步移动指针，就可能更像人。作者承认此次没有代理这样做，不能推导出以后也不会。

相比持续猜测行为，我更认可 Manus 这种主动声明并提供可验证签名的方向。不过，签名能验证声明的来源，未签名的请求仍然需要其他判断。原文还提到，2025 年有人观察到 ChatGPT agent 签名，而此次 ChatGPT Work 没有，不能把不同产品形态的行为混为一谈。

最后，自动化访问不等于无价值访问。作者选择保留记录，让使用者决定是否排除，这比直接删除数据更合理。读完套餐、获得答案后离开，可能恰好是一次成功的信息服务。

能拿来做什么

• 给 Node 服务或网站网关增加已知聊天机器人 User-Agent 的分类统计，并与前端访问量分开展示。服务器日志能补上脚本埋点看不到的抓取，但不能据此覆盖全部代理。
• 分析文档页和套餐页时，先把「无点击、停留短」当作行为描述。代理可能直接读取折叠内容，单凭这些指标无法判断内容是否被有效使用。
• 如果准备加入自动化识别，先做独立标签和样本复核，并覆盖 Voice Control、Dwell 等辅助操作。此次结果支持尝试组合轨迹规则，不支持直接把短按压或中心点击作为拦截条件。
• 用 Claude Code、Playwright MCP 或 Browser Use 验证站点时，同时查看服务器请求和浏览器记录。工具能否回答、是否执行脚本、是否真的操作页面，是三件需要分别确认的事。