网络正在为"良性"机器人构建证明身份的方式。下面讲清 Web Bot Auth 如何运作、谁支持，以及每个抓取者和智能体开发者都需理解的关键陷阱。
Web Bot Auth 让 AI 智能体用 Ed25519 密钥与 HTTP 消息签名（RFC 9421）签名请求，网站据此验证是哪个智能体在调用。 Cloudflare 与 Google 支持，IETF 已于 2026 年初成立工作组。陷阱在于：它只在已采用该方案且选择放行你的站点上换取访问。 在网络的其余部分——几乎全部——被识别的机器人只会被轻易屏蔽，所以你仍需移动代理带来的 IP 信誉。
机制刻意做得"无聊"，这对标准是好兆头。你的智能体持有私钥。每次请求时，它对选定的请求头（方法、路径、主机、时间戳，有时还有正文摘要）附加签名。 网站读取两个请求头——大致是描述签名内容的 Signature-Input 与携带 Ed25519 签名的 Signature——并用你发布的公钥核验。
由于签名与请求绑定，它无法像泄露的 API key 或 User-Agent 字符串那样被重放或窃用。网站得以确认一件以前无法信任的事：该请求确实来自它所声称的智能体。至于放行、限速、收费还是记录，完全取决于网站策略。
Cloudflare 提供对签名智能体的验证并与其机器人管控结合；Google 为其爬虫发布了兼容的 Web Bot Auth 方案；IETF 工作组意味着格式应趋同而非分裂。这覆盖了相当一部分高流量基础设施。
但"Cloudflare 能验证签名"并不等于"网站放你进去"。采用是逐站点可选的，被加入白名单通常意味着某种关系——你是已知搜索引擎、获批的 AI 爬虫，或合作伙伴。对一个抓取随机电商站点的匿名自动化智能体而言，根本没有白名单可加入，签名只会暴露你的匿名性。
Web Bot Auth 是一项新兴标准，让自动化客户端（机器人或 AI 智能体）用加密方式签名其 HTTP 请求，使网站能验证是哪个智能体在发起请求。它基于 HTTP 消息签名（RFC 9421）并使用 Ed25519 密钥，正通过 2026 年初成立的 IETF 工作组进行标准化。Cloudflare 与 Google 均支持兼容方案。
不会。Web Bot Auth 只在已采用它并决定放行你的特定智能体的站点上有用。绝大多数网站没有签名白名单，在那里签名请求只会让你的机器人极易被识别并屏蔽。对这些站点，真实移动代理带来的 IP 信誉仍是可靠的进入方式。
大致如此——签名是机制，验证是结果。支持 Web Bot Auth 的网站会用已知公钥（或目录）核对你的签名；若信任该智能体，便将其视为已验证机器人：放行、限速，或与匿名流量区别对待。