Cloudflare发表智能体与网站关系的立场文章并宣布TAD联盟：列出十四项网站侧挑战，主张用Web Bot Auth和MOLE等标准，但标准多为草案、白皮书尚未发布、相关控制只覆盖经过Cloudflare的流量

2026年11月5日，Cloudflare发表了Bryan Becker撰写的长篇立场文章《智能体不是人（但又有点像）》，并宣布成立Trusted Agent Delegation（TAD，受信任智能体委托）联盟。它承接11月4日那篇关于个人智能体可见性与控制的产品文章，本期不重复那篇的内容；新增的是论证和标准化计划。这篇文章是一家销售机器人和访问控制产品的厂商的倡导性文字，所以关于成本和需求的判断都是Cloudflare自己的表述框架。

出发点是：个人AI智能体是一种中介。它替用户行事，通常由运营方作为托管服务运行，并从运营方的基础设施访问网站。网站看到的是智能体而不是用户，一个智能体还可能带着许多用户。Cloudflare说，网站要管理这种关系，通常需要三样东西：身份、信誉和问责。它提出的唯一组织原则被称为“中介原则”：无论中间隔着什么，用户与网站之间的商业关系，以及各方的安全责任，都必须得到维持。文章举了两个运营方的例子，Meta的Muse和OpenAI的dots，并说智能体流量可能在不久的将来超过普通人类浏览，那时过去“屏蔽中介”的办法就行不通了。

为了把问题讲具体，文章先讲了一个名叫Ezra的私人助理替四位客户跑腿的故事，然后列出一张包含十四项网站侧挑战的表。其中有账号共享、友好欺诈、身份冒充、流量混杂（一个客户滥用共享智能体时，网站只能封禁智能体，于是所有用户一起被封）、资源耗尽、内容被无偿消耗，以及验证码和基于风险的认证不再按设计工作。Cloudflare的结论是，几乎每种情况下主要成本都由网站承担。这是靠推理和例子支撑的说法，不是测量结果，文章也没有对这十四项做任何量化。

Cloudflare还解释了为什么两个常见方案不够。把验证码转交给用户，只能证明那一刻有某个人在场，并不能说明智能体其余时间在替谁行事，还把智能体本来要消除的摩擦加了回来。收窄访问范围在实践中很少用上，因为智能体会要求做一切事情的权限；而且即使范围很窄，它说明的也是智能体被允许做什么，而不是出错时由谁负责。

文章提出的方向是一组已有和新兴的标准。在身份方面，Cloudflare倾向于Web Bot Auth，即智能体对自己的请求签名；它的文档说这基于IETF草案，使用Ed25519密钥，并要求在固定的众所周知路径上提供密钥目录。文章指出一个未解决的情形：智能体在浏览器里再使用另一个智能体，这时网站必须看到整条链路。文档补充说，Cloudflare正在试验用Forwarded头把运营方身份沿这样的链路传递，并注明这是实验性的、可能变化。对于不带用户标识符的限速，文章指向MOLE，称它是Private Access Tokens的预期继任者；对于支付，则指向x402。它描述了四个层次的识别信息，从什么都没有，经过会话和账号，到来自第三方的唯一标识符，并说网站只应索取所需的最少信息。它还希望有办法传递“年满18岁”或“是持卡人”这类声明，也希望有机器可读的方式让网站公布智能体可以做什么；并指出IETF的AI偏好工作组关注训练、搜索这类使用偏好，但在Cloudflare看来，没有覆盖更大的需求。

TAD联盟是这次的宣布。它声明的目标是把生态各方的代表聚在一起，讨论这组问题，审视现有协议，并把定义清楚的问题带到IETF，同时在IETF会议和研讨会上安排旁会。联盟网站说白皮书即将发布，并展示了一个预期用例：回头客更换智能体，网站保持与这位购物者的关系，同时限制被分享的个人信息。文章说，运行在用户自己设备上的本地和开源智能体不是首要关注点。

文章最后讲了Cloudflare客户现在能做什么，这其实重述了11月4日的功能：Security Analytics把个人助理单独作为一类流量，按智能体设置的访问策略可以允许某个智能体、只在带广告的页面屏蔽它，或者完全屏蔽；账号滥用防护处于早期访问阶段，会显示登录或注册是否来自个人智能体以及是哪一个，从而可以用针对其哈希用户ID的WAF规则处置单个账号。文章还提到Business Insights，这是面向企业版机器人管理客户的报表工具，可以看到AI爬虫流量的更大图景。

我们的判断：有用的部分是这套词汇和失败情形清单，网站所有者可以逐项核对十四项里哪些适用。这些标准多数还是草案，MOLE被说成是“预期”的，白皮书尚未发布，已经上线的控制只覆盖经过Cloudflare的流量。应把这个联盟看作一项声明的意图，而不是已被采纳的标准。