截至 2026 年 10 月，网站识别 AI 浏览器 Agent 的方式有三种，分别对应三类 Agent。公开声明身份的爬虫和用户触发的抓取器，靠 User-Agent 字符串、公开的 IP 列表以及越来越普及的加密签名就能识别。驱动真实 Chromium 的 Agent 浏览器（agentic browser）则棘手得多：它们带着正常的 Chrome 指纹，所以主要只能从行为上识别——光标瞬间跳到目标而不是移动过去，文本是粘贴的而不是逐字输入的，滚动是一段一段跳的。Web Bot Auth 是一种自愿采用的解决方案：Agent 对自己的请求签名，网站无需猜测就能认出它。
网站如何检测 AI 浏览器 Agent：三类 Agent，三种方法
“AI 机器人”并不是一个单一类别。要检测 AI 浏览器 Agent，首先得判断眼前是哪一类，因为每一类表明身份的方式不同，暴露它的信号也不同。
- 训练爬虫和搜索爬虫。它们批量抓取页面，没有用户在等结果：GPTBot、OAI-SearchBot、ClaudeBot、Claude-SearchBot、PerplexityBot。它们声明 User-Agent 标识、公开 IP 段，并且按厂商自己的说法遵守 robots.txt。
- 用户触发的抓取器。用户向助手提问，助手当场抓取页面：
ChatGPT-User、Claude-User、Perplexity-User、Google-Agent。它们仍会声明身份，但有几家厂商表示 robots.txt 可能不适用，因为请求是由人发起的。 - Agent 浏览器。一个真实的 Chromium 实例替用户点击、输入和滚动，要么运行在用户自己的电脑上（Perplexity Comet、Claude in Chrome 扩展、开源的 browser-use），要么运行在厂商的云端（ChatGPT agent、Manus）。它们看起来像浏览器，因为它们本来就是浏览器。
Cloudflare 在 2026 年 7 月 1 日发布的分类法按行为划分同样的流量：Search、Agent（“实时地、代表某个人”行事）和 Training。其 Agent 类明确同时包括“聊天抓取机器人（如 ChatGPT-User）和 browser-use 类 Agent（如 Gemini 或 Claude 驱动 Chrome）”。第 2 类和第 3 类在策略上归为同一类，但检测方法完全不同。
公开声明的 Agent：User-Agent 标识与公开 IP（2026 年 10 月核实）
对第 1、2 类来说，检测基本就是查文档。各大厂商都公开了自己的标识和 IP 列表，可以拿请求去比对。UA 匹配加上 IP 匹配是可靠的；只有 UA 匹配则不可靠，因为谁都能发送这个字符串。
| 厂商 | 爬虫 / 搜索 | 用户触发 | 用户触发抓取器与 robots.txt | IP 列表 |
|---|---|---|---|---|
| OpenAI | GPTBot, OAI-SearchBot | ChatGPT-User | “可能不适用” | 每个机器人各一个 JSON 文件 |
| Anthropic | ClaudeBot, Claude-SearchBot | Claude-User | 称其机器人遵守 robots.txt；可以禁止 Claude-User | claude.com/crawling/bots.json |
| Perplexity | PerplexityBot | Perplexity-User | “通常忽略 robots.txt” | perplexity-user.json |
| Googlebot（AI 训练用途由 robots.txt 中的 Google-Extended 标识控制） | Google-Agent | “通常忽略 robots.txt” | user-triggered-agents.json |
声明只有在厂商守规矩时才管用。2025 年 8 月，Cloudflare 报告称，在网站屏蔽 Perplexity 的已声明机器人之后，它观察到一批未声明的请求：使用通用的 macOS 版 Chrome User-Agent，来自 Perplexity 公开 IP 段之外的地址，并且不断轮换 ASN。Cloudflare 表示它通过“机器学习与网络信号的结合”识别出了这些流量，并把 Perplexity 移出了已验证机器人列表。Perplexity 对此说法提出异议。无论谁对，站长都该记住：UA 和 IP 规则只能拦住诚实的流量，拦不住决意不表明身份的流量。
Agent 浏览器为什么能绕过 UA 和 IP 规则
运行在用户笔记本上的 Agent 浏览器，发出的是该用户的 Chrome User-Agent、Chrome 的 TLS 和 HTTP/2 指纹，以及用户的家庭 IP。请求里没有任何东西可供 UA 或 IP 规则匹配。云端托管的 Agent 只是稍好识别一些：它们的 IP 属于云服务商，但 VPN 用户、企业代理以及你本来就放行的自动化工具也是如此。
FP-Agent 论文（Wang、Shafiq 和 Vekaria，arXiv 2605.01247，2026 年 5 月）直接测量了这一点。研究让七个 Agent（OpenAI 的 Atlas 浏览器和 ChatGPT agent、Claude for Chrome、Perplexity Comet、Manus、Browser Use 和 Skyvern）与人类参与者一同完成订机票、购物和论坛任务。在其 Cloudflare 案例研究中，“只有 Manus 被 Cloudflare 完全拦截，其余六个浏览 Agent 都顺利完成了任务”。仅靠浏览器指纹区分这些类别，F1 达到 0.7969。作者发现指纹“与其底层运行环境相关”：本地 Agent 直接继承了宿主机的指纹。
如果你参考的是 2025 年的资料，有一处需要更正：OpenAI 已于 2026 年 8 月 9 日关停 Atlas 浏览器，把 Agent 浏览功能并入了桌面应用。论文中关于 Atlas 的结果仍有参考价值，因为它描述的本地 Agent 模式在其他产品上同样存在。
仍能识别 Agent 浏览器的信号
对 Agent 浏览器而言，暴露它们的主要是行为，而不是运行环境。FP-Agent 分类器结合行为特征和浏览器特征，在论文数据集上的 F1 达到 1.0000。这是基于七个 Agent、三项任务的实验室结果，并非生产环境中的检测率，但方向与各厂商的报告一致。
光标轨迹与输入节奏
论文中最干净的信号是：“浏览 Agent 没有任何鼠标移动，而是直接瞬移到点击位置。”打字同样有辨识度。Atlas、ChatGPT agent 和 Comet 是粘贴文本，ChatGPT agent 的 Ctrl+V 表现出“较高的按键保持延迟……平均 66.58ms”。Browser Use、Skyvern 和 Manus 确实是逐键输入，平均按键间隔分别为 5.31 ms、9.52 ms 和 1.39 ms，而人类表现出“高得多的按键间隔……且方差大得多”。滚动则呈现为“离散的跳跃”，而不是连续的滚轮动作。
Cloudflare 的 Precursor（2026 年 7 月 13 日面向 Enterprise Bot Management 发布，在年内正式上线前免费推出）就是同一思路的生产级实现。它注入客户端 JavaScript，收集“指针移动、键盘活动、焦点变化和可见性”，并按会话累积，因此机器人无法通过刷新页面或重新开始一次验证来重置自己的行为记录。它的出发点是：“难以复制的，是长时间内一致的人类行为。”
自动化与扩展残留痕迹
有些 Agent 会在页面本身留下痕迹。CHEQ 在 2026 年 2 月对 Claude Chrome 扩展的拆解中发现，它通过 chrome.debugger API 操控页面，因此其合成的点击会被视为可信事件。不过在运行期间，它会注入 id 为 claude-agent-stop-container、claude-agent-animation-styles 之类的 DOM 元素，而且样式元素往往在 Agent 停止后仍然留着。HUMAN Security 对 Atlas 和 Comet 的研究同样报告了 Comet 内置扩展留下的 DOM 痕迹，并指出 Comet“不提供逐请求、可验证的身份信号”。
不要把策略建立在单个痕迹上。Castle 记录了一个被广泛使用的 CDP 检测技巧（在 Error.stack 上设置 getter，自动化客户端启用 Runtime 域时会触发）如何在 2025 年 5 月 V8 改动后悄无声息地失效。厂商在一次发版里就能改掉一个 DOM id。痕迹只能作为行为模型权衡的辅助证据，绝不能作为全部结论。
环境一致性与出口
云端托管的 Agent 更容易暴露运行位置。论文观察到 ChatGPT agent 交替报告“Linux x86_64 和 MacIntel”两种平台。Simon Willison 公开的一次抓包请求也显示了同样的问题：macOS 版 Chrome 的 User-Agent 却带着 Sec-Ch-Ua-Platform: "Linux"。Manus 则固定为“Linux x86_64”，并且是“4GB 内存和 6 个 CPU 核心”。UA 与 Client Hints 不一致加上云厂商 ASN，单独看都不算证据，但合在一起就是很强的先验。我们的浏览器指纹详解介绍了这类一致性检查是如何构建的。
Web Bot Auth：靠签名确认 Agent，而不是靠猜
Web Bot Auth 让 Agent 能够证明自己的运营方。它用 HTTP Message Signatures（RFC 9421）对每个请求签名，并在一个 well-known URL 上公开公钥，这样网站就能以密码学方式验证运营方，而不必从 UA、IP 或行为去推断。IETF 的工作仍处于草案阶段：webbotauth 工作组已将其协议文档采纳为 draft-ietf-webbotauth-httpsig-protocol（-00 版，日期 2026 年 9 月 1 日，作者来自 Cloudflare 和 Google）。生产部署已经走在了标准前面。
解读一个真实的签名请求
下面是 Simon Willison 在 2025 年 8 月抓到的 ChatGPT agent 请求中的签名头（此处 nonce 已截断）：
Signature-Agent: "https://chatgpt.com"
Signature-Input: sig1=("@authority" "@method" "@path" "signature-agent");created=1754340838;keyid="otMqcjr17mGyruktGvJU8oojQTSMHlVm7uO-lrcqbdg";expires=1754344438;nonce="_8jbGwfL…";tag="web-bot-auth";alg="ed25519"
Signature: sig1=:…:Signature-Agent指明由谁为该请求担保。验证方会去获取https://chatgpt.com/.well-known/http-message-signatures-directory拿到公钥。- 被覆盖的组件（
@authority、@method、@path、signature-agent）把签名绑定到这个主机、方法和路径上。在一个网站上截获的签名无法重放到另一个网站。 expires − created = 3600：签名有效期为一小时，nonce让验证方可以在这个窗口内拒绝完全相同的重放。tag="web-bot-auth"和alg="ed25519"符合 Cloudflare 的要求：Ed25519 密钥、web-bot-auth标签，并且至少覆盖@authority和signature-agent。keyid是该密钥的 JWK thumbprint。
同一请求中的 UA 就是普通的桌面版 Chrome。不验证签名的话，这个请求和其他浏览器请求毫无区别。
目前到底谁在签名
我们在 2026 年 10 月 3 日请求了各主要 Agent 厂商域名上的 /.well-known/http-message-signatures-directory。chatgpt.com 返回了一个 Ed25519 密钥，带有 "signature_agent":"https://chatgpt.com"，其 keyid 与 2025 年抓包中的不同，说明密钥已经轮换。agent.bot.goog 返回了 Ed25519 密钥；Google 文档称其正在为 Google-Agent“试验 Web Bot Auth 协议，使用 https://agent.bot.goog 身份”。browserbase.com 同样返回了密钥（Browserbase 在 2025 年 8 月与 ChatGPT agent、Block 的 Goose 和 Anchor Browser 一起，入选了 Cloudflare 首批签名 Agent）。而 claude.ai、claude.com、anthropic.com、perplexity.ai 和 browser-use.com 在该路径上返回 404 或一个 HTML 页面。该路径下没有文件，并不能证明厂商从不签名任何东西，但这些厂商都没有在那里公开目录，也没有在其机器人说明页面上记录签名。
在验证方这边，Cloudflare 在边缘验证签名。自 2026 年 7 月 1 日起，它已把签名 Agent 并入 Verified bots，并新增了 Direct 与 Intermediary 字段，记录机器人是由单一运营方运行，还是由众多终端用户驱动。DataDome 的 Agent Trust 把 Web Bot Auth、官方 IP 列表和反向 DNS 与意图模型结合起来。两者都把签名视为身份证明，而不是善意证明。
Agent 类型 → 身份标识 → 检测方式 → 常见策略
| Agent 类型 | 如何表明身份 | 如何被检测 | 常见网站策略（2026 年 10 月） |
|---|---|---|---|
| 训练爬虫（GPTBot、ClaudeBot） | 声明的 UA 标识 + 公开 IP | UA + IP 匹配，反向 DNS | 通过 robots.txt 放行或屏蔽。对于 2026 年 9 月 15 日以后接入的广告支持型域名，Cloudflare 的预设是 Disallow AI Training：robots.txt 中声明不允许训练，并在边缘拦截纯训练爬虫。 |
| 搜索爬虫（OAI-SearchBot、Claude-SearchBot、PerplexityBot） | 声明的 UA + IP | UA + IP 匹配 | 通常放行：它会带来引荐流量。 |
| 用户触发的抓取器（ChatGPT-User、Claude-User、Perplexity-User、Google-Agent） | 声明的 UA + IP；Google-Agent 正在试验签名 | UA + IP 匹配，有签名时验证签名 | 做法不一。Cloudflare 对新域名的默认设置会在广告页面上拦截 Agent 类。很多发布方为了被引用而放行。 |
| 签名的云端 Agent（ChatGPT agent、Browserbase 会话） | Chrome UA + Web Bot Auth 签名 | 签名验证；靠行为判断意图 | 内容页放行。在结账、登录和注册账户环节限速或加强验证。 |
| 未签名的云端 Agent（如 Manus） | 看起来像来自云厂商 ASN 的 Chrome | 云出口 + 指纹不一致 + 行为 | 验证或拦截。FP-Agent 研究中 Manus 被完全拦截。 |
| 本地 Agent 浏览器/扩展（Comet、Claude in Chrome、browser-use） | 用户自己的 Chrome 和 IP；无签名 | 行为（光标瞬移、粘贴输入、跳跃滚动）、DOM/扩展痕迹 | 最难的情况。在敏感流程上做行为评分，在交易环节加强身份验证。 |
对站长意味着什么
按类别、按端点分别决策，而不是对“AI”一刀切。在公开文章页上没问题的访问，放到登录表单上未必没问题。
- 先验证，再决定。对已声明的机器人，用 IP 列表核对 UA；对签名 Agent，验证签名。自称 GPTBot 却未经验证的流量，只不过是伪造了 UA 的流量。
- 放行、屏蔽或收费。Cloudflare 的控制项在所有套餐中都可按类别设置。Pay per crawl 会对未付费的爬虫返回 HTTP 402，但截至撰稿时仍处于封闭测试阶段。
- 保护操作，而不是页面。本地 Agent 浏览器的真正风险在于它们在已登录会话中做了什么。在结账、账户变更和表单提交上加行为评分和加强验证。我们的 Turnstile 内部机制解析讲解了验证评分在其中的位置。
- 两个方向的误判都要预料到。无障碍辅助工具同样会粘贴文本、不用鼠标切换焦点。不能仅凭“没有鼠标移动”就拦截一个会话。
对构建 Agent 的工程师意味着什么
诚实地表明身份，能签名就签名；使用代理是为了地理位置和负载分散，而不是为了冒充人类。检测正朝着“验证签名的，其余按行为打分”的方向发展。伪装 Agent 的成本越来越高，保持诚实的成本越来越低。
- 表明身份。服务端抓取器使用带联系 URL 的描述性 UA 标识。如果你运营 Agent 服务，就公开密钥目录并对请求签名。Cloudflare 的文档和开源的
web-bot-auth库涵盖了 Ed25519 的配置方法。 - 凡不是由用户直接触发的访问，都要遵守 robots.txt 和各网站的 Agent 规则，并把请求频率控制在合理范围。两者都是通过 Cloudflare 验证的条件。
- 出于正确的理由使用代理。住宅出口能给出正确的国家级结果，也能避免一整批 Agent 挤在同一个云 IP 上。但它们无法让 Agent 在行为模型面前隐身；用它们绕过已经屏蔽 Agent 的网站，正是 Cloudflare 把 Perplexity 移出已验证列表时所指出的行为。我们的 AI Agent 代理配置实战指南介绍了具体配置，AI Agent 最佳代理一文比较了适合这类工作负载的 IP 类型。
- 遇到验证就停下。当 Agent 碰到 CAPTCHA 或机器人管理厂商返回的 403 时，说明网站已经做出了决定。把它交给人处理，而不是反复重试。
Web Bot Auth 解决不了什么
签名证明的是谁在运营这个 Agent，而不是用户让它做了什么。正如 Castle 在关于 Operator 签名的讲解中所说，验证能确认来源，但“不能证明用户意图”。签名的 Agent 照样可以被用于撞库、抢购倒卖或被提示注入诱导的购买。这就是为什么 Cloudflare 的 Intermediary 标签和 DataDome 的信任评分仍要在身份之上叠加行为判断。对最难的情况——本地 Agent 浏览器——签名也毫无帮助，因为它们目前根本不发送任何可供验证的东西。在这些产品开始签名之前，网站只能依赖光标轨迹和时序，对它们的检测始终是概率判断，而不是确证。
