Web Bot Auth 能验证签名身份，却无法单独回答一个更重要的问题：这个机器人现在能不能访问这项资源。机器人访问治理正在形成五层强制执行栈：站点偏好、请求身份、用途声明、名录分类和边缘策略。变化的核心不是多了一种 bot 标签，而是这些信号开始进入同一条决策链。
Cloudflare 在 2026 年陆续发布的控制项把这条链路展示得很完整。站点可以分别管理 Search、Agent 和 Training 流量；BotBase 记录运营方、行为、内容用途和验证方法；Bot Preference Sync 让 robots.txt 与控制台策略保持一致；边缘规则再将证据转成允许或阻断。
组件已经出现，系统仍在磨合。每一层究竟证明什么，决定了这套机制是访问治理基础设施，还是一个更复杂的误判来源。
robots.txt 表达偏好，安全控制负责执行
robots.txt 的优势一直是低成本。站点发布 User-Agent 与路径规则，合作型爬虫主动读取并遵守。RFC 9309 将这套协议标准化，同时明确指出它不构成访问授权。真正需要保护的资源仍要使用 HTTP 认证、WAF 或应用权限。
AI 时代让这个边界更突出。同一家运营方可能同时运行搜索索引、模型训练和用户触发的实时 Agent。公司名相同，不代表用途相同；User-Agent 相同，也无法说明这次请求为了发现内容、训练模型，还是替用户完成操作。
Bot Preference Sync 解决的是配置漂移：站点在控制台选择的 Search、Agent 与 Training 偏好，可以同步到托管的 robots.txt 内容，同时保留原有规则。这里仍有两条路径：robots.txt 对外发布偏好，边缘策略实际处置流量。两者一致会减少争议，二者的安全属性依然不同。
第一层：站点偏好
站点首先要表达自己希望怎样使用内容和流量。一个统一的 Block AI Bots 开关已经不够。
Cloudflare 的三类用途分别回答：
- Search 是否为了日后检索与发现建立索引。
- Agent 是否实时代表某个人完成任务。
- Training 是否把内容用于模型训练或微调。
一个爬虫可以同时命中多类。Search 与 Training 混在同一爬虫里时，完整记录两个用途比挑一个方便的标签更可信。Content Signals 还能进一步表达 reference、full 等内容使用层级。
这一层记录站点希望怎样处理内容，也记录机器人声称怎样使用内容。它属于规范与声明，真实性需要后续证据支持。
第二层：请求身份
身份层只回答一个窄问题：这次请求是否由某个已发布密钥的持有者签名。
当前 IETF Web Bot Auth 工作组草案基于 HTTP Message Signatures，在请求中携带 Signature-Agent，再从 HTTPS 密钥目录获取公钥完成验证。相比可伪造的 User-Agent 和共享云 IP，这种方式能提供更稳定的签名身份。
草案对信任边界写得很清楚。验证成功能够证明：解析后的目录发布了一把密钥，该密钥的持有者签署了被覆盖的消息部分。它没有证明运营方一定诚实，没有证明行为安全，也没有证明请求得到终端用户授权。是否允许仍由站点策略决定。
标准状态也必须带日期。2026 年 9 月 1 日，个人草案被工作组采纳为 draft-ietf-webbotauth-httpsig-protocol-00。它已经是活动工作组文档，仍属于 Internet-Draft，尚未成为 RFC。
标准在收敛，实现仍有版本错位
当前公开文档已经出现线格式分叉。IETF 工作组草案要求新发送方使用字典形式的 Signature-Agent，验证方可以在迁移期兼容旧字符串形式。Google 的实验指南使用字典形式，并提醒只有部分请求带签名。Cloudflare 的实现文档目前仍要求旧字符串形式，还说明后来的字典形式会验证失败。
这些资料证明的是文档层版本错位。双方生产系统是否通过适配层完全互通，官方资料尚未明确。网站上线时应记录协议版本和验证器行为，保留传统 IP、反向 DNS 与 User-Agent 回退，并用实际流量测试兼容性。
一个 signed=true 字段无法承载这些差异。
第三层：用途声明
身份与用途是两个字段。运营方的签名可以保持连续，同一个运营方仍可能运行 Search、Agent、Training、SEO、监控和交易类自动化。
用途声明要经过三类证据校准：
- 运营方提交的用途与公开说明。
- 签名身份、IP、User-Agent 等技术标识。
- 实际访问路径、频率、引流、内容复用和策略遵守情况。
三类证据一致时，用途标签才逐步获得可信度。只靠表单会形成自我声明；只靠签名只能证明密钥；只靠行为分类又可能产生误判。
IETF 工作组特意把用途词汇放在 Web Bot Auth 的范围之外，也不处理终端用户身份。协议负责认证自动客户端，平台与站点继续负责用途分类、信誉、授权和风险判断。这种分工很重要：密码学能提高伪造成本，无法让用途声明自动变真。
第四层：两种目录承担两种职责
Web Bot Auth 的密钥目录与 BotBase 业务名录名称相似，职责完全不同。
密钥目录提供验证请求所需的公钥材料。它回答去哪找密钥、怎样轮换、怎样缓存。BotBase 则连接运营方、机器人名称、行为、内容用途、验证方式、审核状态与检测 ID。BotBase for Operators允许运营方提交、查看审核进度和更新记录，让站点在控制台检索分类并用于安全规则。
BotBase 也不应被当作绝对事实源。它混合了运营方声明、平台审核、技术验证和持续行为观察。理想的记录应标明每个字段来自哪种证据，以及最后核验时间。否则，站点无法区分某项用途是自己申报、人工审核、密码学验证，还是行为模型推断。
目录本身还会成为运行时依赖。IETF 草案建议把验证结果分为 verified、invalid 和 unverified。密钥目录暂时不可用或未知密钥导致证据不足，含义不同于签名校验失败。把两者统一当作恶意，会让目录故障变成大面积误封。
第五层：本地策略与边缘执行
最后一层才负责回答：给定身份、用途、行为、资源和站点偏好，网关采取什么动作。
Cloudflare 为主要 AI 用途提供 Allow、仅广告页阻断和全站阻断三种选项。其产品文档宣布，2026 年 9 月 15 日开始，新接入域名将默认在含广告页面阻断 Training 与 Agent，同时继续允许 Search。截至 9 月 10 日，这仍是五天后生效的计划，只适用于新域名，并允许客户选择其他策略。
这条规则说明默认值也需要版本管理。相同请求可能因为域名接入日期、站点是否退出、页面是否含广告，以及爬虫是否同时属于多类而得到不同结果。
不同平台也会从同一身份信号得到不同默认动作。AWS WAF表示，其托管 Bot Control 会默认允许验证通过的 Web Bot Auth 流量，并提供标签供客户编写更细规则。身份是决策输入，默认动作属于平台与站点政策。
五层证据不能压成一个绿灯
| 层级 | 最强可支持结论 | 仍需补充的判断 |
|---|---|---|
| 站点偏好 | 所有者发布或配置了期望处置 | 爬虫是否遵守，边缘是否执行 |
| Web Bot Auth | 某个已解析标识发布的密钥签署了指定消息部分 | 运营方信誉、用户授权、用途与安全性 |
| 用途声明 | 运营方声称一种或多种用途 | 行为是否符合声明 |
| 业务名录 | 平台关联了标识、审核、分类和行为记录 | 本站最终是否放行 |
| 边缘执行 | 某版策略产生了允许、阻断、挑战、限速或计费 | 策略的经济与业务效果是否合理 |
可信度应逐层累积。验证过一把密钥，不等于获得所有资源的通行证。
一份可执行的决策合同
站点可以用五条规则把复杂度压缩下来。
第一，先划分资源。公开文章、付费档案、账户页、支付流程和删除操作使用不同基线。
第二，保留 verified、invalid、unverified 三种身份状态。Web Bot Auth 仍在早期采用阶段，未签名请求需要单独观察。
第三，多用途爬虫按所有适用标签判断。对于禁止进入训练的数据，Search 加 Training 的组合应采用更严格规则，除非存在可验证的用途隔离。
第四，本地策略拥有最终决定权。Verified 提高来源可信度，不自动授予权限。
第五，记录完整决策元组：
时间
站点策略版本
资源类别
签名协议版本
身份验证结果
业务名录记录版本
声明用途
行为证据
命中规则
最终动作
边缘响应状态
源站响应状态
这些字段能让一次放行或阻断被复现、申诉、审计和安全修改。
日志还要进入对账闭环。定期比较公开的 robots.txt、控制台配置、生成的 WAF 规则、名录记录和测试爬虫拿到的真实响应。策略显示允许，上游规则却返回 403，属于配置漂移，即使每个控制台单独看都显示正常。对账至少同时验证一条正向路径和一条负向路径，例如让已验证搜索爬虫读取公开页面，同时保持同一内容的 Training 阻断。
网站与机器人运营方分别要做什么
网站侧的迁移重点是先观察再执行：让 robots.txt 与真实策略同步；按资源与用途盘点规则；分别统计验证成功、失败和证据不足；测试新旧 Signature-Agent 形式；按生效日期、域名批次和例外状态检查默认值；把最终动作及证据导出到日志，并用真实 HTTP 响应持续对账。
机器人运营方要维护可验证身份：提供稳定的 HTTPS 标识和高可用密钥目录；合理覆盖请求组件，使用短有效期并支持密钥轮换；完整申报所有行为与内容用途；及时更新名录、User-Agent 与验证方式；针对不同验证器执行兼容测试；提供公开联系方式与分类申诉路径。
这套系统的瓶颈已经从有没有某个组件，转向组件之间能否稳定连接。
真正的产品是执行基础设施
Web 不需要一个完美的 bot 标签。它需要少量信号和一条可审计的决策路径。
robots.txt 继续承担低成本偏好接口；Web Bot Auth 提供请求来源证明；用途分类解释自动化为何到访；业务名录把声明、审核与行为连接起来；边缘策略将证据转成本站动作。
系统可靠的前提是每一层保留自己的边界。签名机器人仍可能违反政策，未签名请求也可能无害，名录可能过期，默认值会随日期变化。将这些不确定性显式留在系统中，策略才有机会正确处理它们。
如果关注未知 Agent 的检测和误报问题，可继续阅读浏览器指纹失效之后：行为检测、签名身份与误伤成本。那篇文章讨论行为检测、身份、授权与无障碍风险；本文聚焦身份与用途如何进入平台策略和边缘执行。
FAQ
Web Bot Auth 是什么？
它是 IETF 正在推进的自动 HTTP 客户端认证协议，通过 HTTP Message Signatures 与公钥目录验证请求身份。当前规范是工作组 Internet-Draft，仍未成为 RFC。
robots.txt 能阻断 AI Agent 吗？
robots.txt 发布合作型爬虫应遵守的规则。RFC 9309 明确说明它不属于访问授权。可靠阻断需要 CDN、WAF、源站规则或应用权限。
Web Bot Auth 验证通过是否意味着自动放行？
不意味着。验证结果证明的是被覆盖消息的签名身份。站点仍要判断用途、资源、行为、用户授权和本地政策。
Search、Agent 与 Training 有什么区别？
Search 为日后发现建立索引；Agent 实时代表用户完成任务；Training 把内容用于模型训练或微调。一个爬虫可能同时具备多种用途。
为什么要区分 unverified 与 invalid？
密钥目录不可用、密钥未知或本次请求未签名都会造成证据不足。它们与已经携带签名但密码学校验失败的含义不同。
Google 与 Cloudflare 的 Web Bot Auth 当前是否完全互通？
公开文档尚不能证明完全互通。Google 采用当前字典形式的 Signature-Agent；Cloudflare 目前仍记录旧字符串形式，并说明字典形式会验证失败。IETF 草案提供了迁移兼容方案，生产兼容性仍需实测。
Cloudflare 9 月 15 日会默认阻断所有 Agent 吗？
不会。Cloudflare 宣布的是：从 2026 年 9 月 15 日起，新接入域名默认在含广告页面阻断 Agent 和 Training，同时允许 Search。客户可以修改配置，这也不是 Web 的通用规则。
参考资料
- RFC 9309：Robots Exclusion Protocol
- IETF Web Bot Auth 工作组
- IETF 工作组草案：HTTP Message Signatures for automated traffic
- Cloudflare：New AI traffic options
- Cloudflare：Block AI Bots 文档
- Cloudflare：BotBase for Operators
- Cloudflare：Bot Preference Sync
- Cloudflare：Web Bot Auth 实现文档
- Google：Web Bot Auth 实验指南
- AWS WAF：Web Bot Auth 支持