人类要与线上世界交互，需要一个入口：键盘、屏幕、浏览器、设备。所谓线上的“人类检测”，检测的其实是人类使用这些设备时形成的行为模式。这些模式近年来已经变了：创业公司 CEO 用浏览器来总结新闻；技术爱好者把夜间开票时抢演唱会门票的流程自动化；视障人士在屏幕阅读器上开启无障碍功能；企业则把员工流量经由零信任代理转发。
与此同时，网站所有者仍然要保护自己的数据、管理资源、控制内容分发并防止滥用。这些问题并不取决于客户端是人还是机器人：有受欢迎的机器人，也有不受欢迎的人类。要解决它们，需要了解的是意图和行为。检测自动化的能力依然至关重要。不过，随着各类行为主体之间的界限变得模糊，我们现在构建的系统应当适应这样一个未来：“机器人与人类”不再是关键的数据点。
真正重要的不是抽象意义上的“人性”，而是这样一些问题：这是不是攻击流量？这个爬虫带来的负载与它回流的流量是否成比例？我是否预期这个用户会从这个新国家连接？我的广告是否被人刷了？
我们用“机器人”一词讨论的，其实是两个不同的故事。第一个是：当已知爬虫没有带回流量时，网站所有者是否还应该放行它们。对此我们已经有所涉及，即面向希望表明身份又不想被冒充的爬虫的基于 HTTP 消息签名的机器人认证。第二个是新型客户端的出现，它们不具备 Web 浏览器历来具有的那些行为特征，这对私有速率限制等系统很重要。
本文将探讨 Web 防护目前是如何运作的，以及当机器人与人类之间的界线逐渐消失时，它必须如何演进。
我们曾经拥有的 Web
我们使用 Web 时，并不直接与每天交互的成千上万台服务器对话，而是通过 Web 浏览器。浏览器也被称为“用户代理（user agent）”，因为它们代表我们行事，维护我们的利益，让我们能够安全地购物、阅读和观看，而不必让网站访问我们的整台电脑或手机。
网站同样关心浏览器如何工作。它们希望内容被准确呈现（适配手机屏幕、背景色正确、语言无误），希望用户能够完成购买、阅读文章、使用麦克风，或者无需密码就安全登录，也希望人们能看到文章旁边的广告。
浏览器用户与网站之间的这种利益张力由来已久。发布者通常希望对用户体验拥有像素级的控制，而浏览器另一端的人往往想以发布者未曾设想的方式使用自己获取的数据。
Web 浏览器厂商及其周边的标准生态一直审慎地平衡这些利益，有时还引发了很大争议。例如，你可以用浏览器扩展屏蔽广告，但随着时间推移，浏览器限制了这类扩展的能力。无障碍标准（例如 WCAG）为以非像素的方式使用 Web 内容铺平了道路，并且在许多地方有监管要求作为后盾。人们可以质疑其中每一项取舍的具体细节，但它们是作为一个整体打包而来的：只要你想在 Web 上立足，无论是发布者还是用户，都必须接受。
然而现在，这种平衡正在发生变化。让助手总结新闻或汇总研究资料并不是新概念，但 AI 让每个人都能获得这种能力。摩擦来自这些新兴客户端的运作方式。人类助手可能会在发布者不知情的情况下打印文章或截图，但他们起码仍然要用标准的 Web 浏览器来渲染网站。AI 智能体跳过了这一步，打破了浏览器所建立的、在发布者权利与用户权利之间的平衡。它们不渲染页面，悄悄地直接抓取原始数据。对发布者而言，由于这些客户端与既有的浏览器流量相互重叠，它们天然是不透明的。网站所有者无法判断，被抓取的内容是在服务于某一份私人报告（可能被扭曲，也可能未注明出处），还是被摄取去为百万用户训练模型，而后者会破坏维持网站运营的那种可预测（且可变现）的流量。
让 Web 得以运转的那份默契正在瓦解。为了理解其原因，下一节先介绍互联网上一种常见的架构。
客户端-服务器模型
让我们退后一步，看看互联网上的主要部署模式之一：客户端-服务器模型。客户端向服务器发出请求，以获取某个资源：
图 1：客户端-服务器模型。客户端发送请求，服务器予以响应。
为了处理更多请求，网站可以提升服务能力：部署更多服务器，或在静态流量前放置缓存。同样，来自客户端一侧的请求数量也可能增加：要么是某个客户端发出了更多请求，要么是客户端数量成倍增长。
图 2：多个客户端向不同的服务器发送多个请求，其中一台服务器前面部署了 CDN。
这种简洁性正是 Web 成功的原因之一。它允许多种客户端并存，也让网络得以演进，而无需每台服务器确切知道对端运行的是什么软件。
图 3：两种不同的客户端环境向服务器发送请求。每台服务器只能看到请求，看不到请求背后的最终用户。
这种开放性也带来了不确定性。网站能看到一个针对某资源的有效请求，但通常无法知道响应离开服务器之后会发生什么：内容是被渲染出来，供某个人通过键盘、鼠标和屏幕操控浏览器来查看，还是被一个独立程序自动发起请求、存档响应、建立索引，并输入到一个更大的系统中。
当今的机器人管理
这个模型的运作效果出奇地好。这也是为什么运营一个网站可以简单到只需启动一台接入互联网的 Web 服务器。但这只在服务器不必决定哪些请求能承受得起、值得信任或应当优先处理时才成立。
有时这关乎容量。如果你的服务按全球每秒 100 个请求的规模配置，却收到了 200 个，你就必须丢弃一部分请求。如果服务器只有 1 个 CPU，而到来的请求需要 2 个，你就必须丢弃请求。如果服务 200 个请求的成本高得无法承受，你就必须对所有请求限速。
你可以随机丢弃请求。这可能不公平，也可能误伤想要服务的客户端，但行得通。在没有其他信号的情况下，别无选择。
而容量只是问题的一部分。服务器还会出于许多其他原因区分客户端：把攻击与正常流量分开、管理非恶意的负载、防止数据被提取、限制广告欺诈、防止虚假账号注册，或阻止代表用户执行的自动化操作。
困难在于，Web 客户端默认是未经认证的，却又暴露了许多局部信号。因此，大多数服务器会根据收到的信息来应用访问控制逻辑。如果某个 IP 地址发出的请求数是其他地址的 10 倍，它可能会被封锁。更进一步的服务器可能会推断该 IP 地址被 VPN 使用，因而代理着不止一个用户的流量。服务可以决定应用一个系数：假设每个客户端每秒可发出 10 个请求，那么共享 IP 地址在请求被丢弃之前可以获准达到 100 rps。
这正是机器人管理的关键之一：它旨在向服务器提供更多关于客户端的信息，帮助其做出决策。由于客户端不受服务器控制，这些信息天然不精确。此外，同样的信息还会产生指纹向量，服务器可将其用于个性化广告等其他目的。这就把一种缓解手段变成了一种追踪手段。
概括来说，服务器能从客户端看到以下信号：
- 被动客户端信号：在互联网上发出请求所必需的信息。客户端必然会发送你的 IP 地址，并且通常会建立 TLS 会话。
- 主动客户端信号：由客户端自愿提供，终端用户通常看不到。包括 User-Agent 标头或认证凭据。
- 服务器信号：服务器自己观察到的信息，例如处理该请求的边缘服务器所在的地理位置，或收到请求的本地时间。
要限制和封顶大规模的滥用，源站关心的是客户端发出多次请求的能力和意图。对于靠广告运营的网站，源站需要确信广告确实展示给了终端用户。为维护品牌，源站可能希望确保客户端具备特定的渲染能力：PDF 阅读器、SVG 渲染器、虚拟键盘。如果请求来自拦截代理，源站可能还希望确保该请求确实源自终端客户端
流量增长，运营成本也随之增长。如果客户端不产生价值（无论是否为金钱形式），服务器就没有动力去承担这些成本。
不同的运营者对这种环境的应对方式不同。一些大型爬虫和平台会表明自己的身份，因为可预测的访问值得付出可被追溯的代价，这甚至可能有所帮助。另一些则设法避免被识别：或是因为预期会被封锁，或是因为追求匿名，或是因为它们代表终端用户行事。结果是一种建立在局部信号之上的不稳定平衡。
这就是为什么“人类与机器人”的框架具有误导性。源站关心的不是抽象意义上的“人性”，而是客户端的行为是否在网站能够支撑的范围之内。
题外话：速率限制三难困境
图 4：速率限制三难困境。去中心化、匿名、可问责，三者只能取其二
在如何管理互联网访问的问题上，存在一个根本性的矛盾：去中心化、匿名、可问责，三者只能取其二。
- 完全去中心化 + 匿名意味着没有问责。被封锁的客户端可以另开一个账号，而不会对其声誉造成任何影响。这意味着源站必须投入更多来管理自己的资源。这是 Web 的默认状态。
- 去中心化 + 可问责意味着每个人都知道你是谁，这对某些场景有效，但缺点明显。想想“使用……登录”这类 OAuth 机制，它需要注册账号，并向第三方暴露你的活动。
- 匿名 + 可问责很可能需要治理、规则和执行机制。目前没有任何广泛部署的系统能让同一个行为主体同时具备这两种属性。最接近的先例是 Web PKI，其中的治理机制（CA 策略、证书透明度）让服务器承担问责。当这种治理失灵时，会产生后果。而在客户端一侧，目前还没有对等的机制。
现有工具借助前一种组合中的要素去追求后一种：TLS 指纹、IP 地址、robots.txt。它们试图实现问责，但只有在衍生出的指纹保持稳定时才有效。
重要的区别在于“是什么”，而非“是谁”
对于要决定如何处理入站流量的网站所有者来说，有意义的区分未必是机器人与人类，而是在源站了解所接收流量的需求与客户端保护隐私的需求之间取得平衡。
希望被识别的平台和服务
图 5：一个爬虫向服务器发出多个请求
有些流量来自发出海量请求的已知运营者：搜索引擎爬虫、云平台、企业基础设施。这些行为主体通常对隐私的期望很低。它们是基础设施，从可识别的来源发出数百万个请求。能够识别请求来源，有助于在基础设施提供方向你发送过多请求或访问了不该访问的页面时，减少误判。自我标识是我们提出的负责任 AI 机器人原则之一。Cloudflare 运营其 Radar 的 URL 扫描器，以及我们公开爬取能力的方式，都是基于这些原则。
对于这类流量，身份是行得通的。更准确地说，一些运营者可以容忍请求可被追溯，因为可靠的访问值得这样做。使用 HTTP 消息签名的 Web Bot Auth 允许运营者对自己的请求进行加密签名。例如，OpenAI、Google、Cloudflare 或 AWS 会对源自其平台的请求签名。源站可以验证“这个请求确实来自该平台的基础设施”，而无需依赖 IP 范围或 User-Agent 字符串。
人类和其他终端用户理所当然有不同于“被识别”的期望：在不牺牲访问权限和体验质量的前提下保持匿名。
需要匿名的分布式流量
图 6：三个不同的浏览器向服务器发出请求。一个由人类操作，一个由设备端助手操作，还有一个经由企业代理转发。
另一些流量来自众多来源，每个来源发出的请求相对较少。这包括浏览网页的人类、做测量的研究人员、使用住宅代理的抓取程序，以及越来越多代表人类行事的 AI 助手。
而且机器人与人类之间的区别越来越失去意义。预订演唱会门票的 AI 助手与原本会手动预订的人类之间，并无本质差别。两者都是分布式的，都需要匿名。在每种情况下，源站都希望减少那些按预期使用服务、而非滥用服务的用户所面对的摩擦。
身份或许可行。要取代我们过去对 IP 地址的假设，它应当提供一组与特定客户端绑定的、唯一且可验证的属性，并通过账号登录、电子邮件地址或硬件密钥来证明。然而，这意味着访问网站时需要出示这一身份，同时也会损害隐私。
我们希望构建能够证明行为、而无需证明身份的现代方案。
面向 Web 的匿名凭证
自 2019 年起，通过 Cloudflare 访问网站的客户端就能够提供这样的行为证明，方法是在请求中附带一个隐私令牌。这得益于 Cloudflare 对 Privacy Pass 的早期支持。Privacy Pass 已标准化为 RFC 9576、RFC 9578，它让客户端可以携带由签发方背书的、证明其曾通过某项检查（例如解决过一次挑战）的凭据，而不会把这一结果变成稳定的标识符。它定义的令牌与任何先前的访问、请求或会话都是不可关联的。
这很重要，因为它提供了一种不同于指纹识别的模式。服务器不再收集被动信号，而是可以向客户端索取一个主动提供的、保护隐私的信号。
这降低了建立会话时的摩擦。Privacy Pass 在 Cloudflare 的基础设施上每天已扩展到数十亿个令牌，主要用于隐私中继服务。
图 7：Privacy Pass 兑换与签发协议的交互，出自 RFC 9576 第 3.1 节
该 RFC 强调了四种角色。签发方（issuer）信任一个或多个证明方（attester）在签发凭据（RFC 中即令牌）之前执行某些检查。客户端持有这些凭据，并在合适的范围内决定何时出示。源站始终掌控自己信任哪些签发方，以及每次出示意味着什么。这并不能消除滥用或策略问题，只是为客户端和服务器提供了一种保护隐私的方式来处理它们。
这个系统很简单，但也有局限：例如，它不支持动态速率限制。如果一个客户端获得了 100 个令牌，却在第一或第二次会话之后开始消耗过多资源，就没有办法让之前已签发的剩余令牌失效。
此外，由于不可关联的特性，新的签发方很难出现。源站无法就签发方令牌所传达信号的质量提供任何反馈机制。
最后，签发方提供的令牌数量与这些令牌兑换时可进行的不可关联出示次数之间是 1:1 的关系：一个令牌对应一次出示。理想情况下，我们希望有这样一种系统：客户端只需联系签发方一次，之后就能针对特定源站上下文进行多次出示。这指向了由用户代理持有经背书的凭据并出示由其派生的证明，而不是反复获取一次性令牌。
我们的目标是帮助建立一个开放的私有速率限制生态。本着这一精神，我们正在协助开发和探索新的 Privacy Pass 原语，例如匿名速率限制凭证（Anonymous Rate-Limit Credentials，ARC）和匿名信用令牌（Anonymous Credit Tokens，ACT）。
例如，借助 ACT，客户端可以证明“我在这项服务上有良好的历史记录”，而不必透露“我是这个用户”。ACT 在协议层面保持各次出示之间的不可关联性，这是这里的关键密码学属性。即便在 RFC 9576 第 4.3 节的签发方与源站联合部署模型中，协议的设计也使令牌的签发与出示之间不可直接关联。但这并不能消除通过 IP 地址、Cookie、账号状态或时间等其他层面产生的关联。同样的属性也可以通过标准化的 VOPRF 和 BlindRSA 原语来实现，它们位于 ACT 所实现的反向流程框架之内。
一个成功的生态必须是开放的签发方生态。在实践中，这不仅仅意味着“任何人都可以签发凭据”。源站需要能够决定信任哪些签发方；用户代理需要有一致的方式来呈现被请求的内容；生态还需要让签发方建立声誉、让依赖方停止信任低质量签发方的途径。任何单一的守门人都不应控制参与资格。
要实现这一点，需要有一套能跨浏览器和其他用户代理工作的协议和客户端 API。它必须部署简单、对用户清晰，并且足够收窄，使浏览器能够对滥用性的证明请求设置限制，而不只是把它们展示出来。
如果我们什么都不做，会走向何方
网站所有者已经在对新兴客户端造成的冲击做出反应。这一方面是由大规模的抓取和模型训练造成的，另一方面也源于用户代理以网站未曾预料的方式行事。因此，网站要求有更多技术手段来阻止 AI 爬虫及相关工具。在机器人与人类之间的界线日益模糊的生态中，我们今天拥有的措施单靠自身将变得越来越无效。
如果这些措施失效，我们可以预期网站会转向：要求注册账号才能查看任何内容，或将访问权限与某个稳定的标识符绑定。这意味着不再有靠广告支撑、无需登录的文章，也不再有“每月三篇免费文章”。其他内容业务可能会彻底离开 Web，直接向 AI 厂商收费提供其数据和服务，或是躲进大型平台运营的围墙花园之中。
这些结果都很糟糕。Web 所提供的对信息的开放访问让每个人受益。并不是所有网站都会做出这些选择。在线提供内容有许多原因，并非全都出于商业目的。但如果足够多的网站这样做，它们就会把 Web 上的“常态”变成某种更糟的东西。
这很重要，因为开放的 Web 是这样一种环境：不同的客户端可以从不同的来源收集信息，而无需依赖少数几家参与者。信息来源的多样性本身也让我们受益。在一个对信息的访问主要由少数几家公司中介的 Web 上，我们把太多权力交给了太少的人。其结果不仅是匿名客户端面临更多摩擦，也是一个更加脆弱的互联网，发布者触达用户的途径变得更少。
匿名认证同样伴随着一些风险
我们应当清楚自己在构建什么。用于证明属性的基础设施，可能变成用于要求属性的基础设施。匿名凭证本意是证明持有者的某些方面，例如“我解决过一个挑战”或“我没有超过速率限制”。但一个能够证明任何单一属性的系统，同样也能证明其他属性，这令人担忧。
如今，出示 Privacy Pass 令牌可能传达的是“已解决 CAPTCHA”。明天，同样的系统可能证明完全不同的属性。例如，只向“具备设备证明（device attestation）”的设备签发令牌，会把较旧的设备及其用户排除在外。类似地，要求“拥有 Apple 或 Google 账号”之类的属性，会把非主流平台的用户排除在外。
一旦有了验证匿名证明的基础设施，被证明的内容就可能不断扩大。我们必须确保这不会成为访问互联网的门槛。
为什么我们仍应构建它
门槛早已存在。平台越来越多地要求提供身份。网站正在封锁来自共享代理的流量。问题不在于门槛是否会出现，而在于用户是否仍能掌控自己的隐私。
正如我们所讨论的，机器人管理需要共享一些信号。匿名证明的替代方案更糟。如果无法匿名地证明属性，每道门槛都需要指纹：换用特定的浏览器重试、关联你的账号、不要使用 VPN。对一些人来说，这甚至不是可选项，比如那些根本不知道自己的连接被代理了的人。
保护隐私的凭证并不会消除对信任或策略的需求，但可以让这些要求更明确、更少渗透。与指纹不同，证明是显式的。用户可以看到被索取的是什么，而 Web 浏览器和 AI 助手等客户端可以帮助落实用户同意。
决策时，请使用这条底线
有一个简单的检验标准，可用来评估下一代服务于所有人的互联网方案：这些方法是否允许世界上任何地方的任何人构建自己的设备、自己的浏览器，使用任何操作系统，并获得对 Web 的访问？如果这一属性无法成立，如果来自特定制造商的设备证明成为唯一可行的信号，我们就应当叫停。
这意味着我们需要培育一个开放的签发方生态，由任何单一的守门人决定谁能参与都是不可接受的。在速率限制三难困境中，去中心化对开放的 Web 而言是必选项。我们还不完全清楚该如何构建它，但我们知道需要去培育它。
一种新的平衡
到目前为止，Web 在很大程度上处于平衡状态。其中一些方面可能是美好的巧合，另一些则可能是必然。对许多终端用户和发布者来说，它之所以行得通，是因为 Web 保持了足够的开放，足以支持各种各样的客户端去访问同样丰富多样的资源。
这种平衡正面临风险。面向 Web 的保护隐私原语，是为构建另一种结果所做的一次尝试：保护隐私、开放、可问责。它不保证成功，但总好过坐等。
如果你有兴趣跟踪并参与，这项工作在 IETF 和 W3C 公开进行。我们相信，当年人们聚在一起塑造今天 Web 的那些现有场所，正是设计明天 Web 的最佳场所。
互联网是为终端用户而存在的，他们需要处于互联网的中心。