Agent 不是人类，但差不多算是

AI Agent 如今正在为数以百万计的人操作网页。对一个 Site 来说，Agent 可以有多种形态。它可能与执行任务的人类用户无从区分，也可能看起来像是一个访客，代表着许多 User。这让 Site 失去了识别、服务并追究 Agent 背后那个或那些用户的能力，一旦出问题，代价却由 Site 承担。本文认为，Site 要想把开放给 Agent 的访问权限做到最大，整个生态就必须发展出新的机制，以维系 Site 与 User 之间的关系。在安全与反欺诈领域，这历来需要三样东西，即身份、声誉与问责，让 Site 能够回答三个问题。操作者对自己是谁是否说了实话？这个人可信吗？出了事谁来负责？

“Personal AI Agent”（简称“Agent”）是一种自动化程序，它接受人类（“User”）的指令，通过操控云端计算机或浏览器来达成某个目标。它们通常由“Operator”托管和维护，作为托管服务或面向消费者的产品的一部分提供。例如 Meta 的 Muse 和 OpenAI 的 dots，而且新的产品一直在不断推出。Agent 有可能在网上采取其 User 能采取的任何行动，却不受约束人类的那些限制。它们不会疲倦，全天候运行，并行行动，还能忍受没有人会忍受的摩擦。网络的很大一部分，从 Site 如何规划容量到如何赚钱，都建立在那些限制之上。

从根本上说，远程托管的 Agent 是中介。中介是任何位于 User 与 Site 之间的东西，于是 Site 看到的是它，而不是 User。Agent 是最新的一类中介，但中介早已存在。云浏览器（由软件代表 User 操控的托管浏览器）和代理（转发 User 流量的服务，包括 VPN）同样是中介。变化的是趋势。Agent 流量正在快速增长，并可能在不久的将来超过互联网上传统的人类浏览。这迫使今天运营 Site 的每一个人正视现实。过去，Site 可以直接封禁中介流量，要求 User 关闭中介服务；当大部分流量都来自 Agent 时，这一招就失效了。一旦封禁不再可行，Site 运营者就只剩下中介一直造成的问题。Site 失去了关于 User 的直接信息，却必须在没有这些信息的情况下决定是否信任中介。

本文讨论的是托管在用户设备之外的 Agent。本地 Agent（例如 OpenClaw），或运行在用户自己的浏览器、自己设备上的 Agent，不在本文的主要讨论范围之内（参见下文“关于开源与本地 Agent”）。

这篇文章建立在一个原则之上。

中介原则。用户与站点之间的业务关系，以及各参与方的安全责任，不因中介的存在而改变。

站点需要新的工具，来识别、服务并追究通过 Agent 行事的用户，效果要和该用户亲自到访时一样。Agent 及其背后的 Operator 也必须可识别、可追责，因为 Agent 能做到用户做不到的事。Agent 几乎可以无限制地放大人类访问的规模，因此即便是过去无害的行为，也会带来新的风险。

中介问题

来认识一下 Ezra。Ezra 在她的城市里给人当私人助理。她最大的客户是当地一位 CEO Amy，但她同时也为 Bob、Charlie 和 Debra 工作。她替他们跑腿，买菜、约诊、办手续、订机票。Ezra 混在人群里，并不起眼。

街角杂货店的老板以前认识 Amy。他知道她买什么，会把他觉得她会喜欢的东西留出来。现在只有 Ezra 上门，一次带着四个人的订单，老板分不清哪些偏好是谁的。他不想把 Ezra 拒之门外，因为她给他带来了不少生意。

后来 Bob 让 Ezra 帮他买一部 iPhone。一周后他打电话给商店，说自己从未授权这笔扣款，手机却留在了手里。商店想赢下这场纠纷，就得证明是 Bob 要买的。可商店见过的人只有 Ezra。

再后来 Charlie 给了 Ezra 一串密码：“我忘了自己的是哪个，但肯定在这几个里面。”Ezra 耐着性子在 Charlie 的银行一个个试。银行能看出正在发生攻击，但它能封禁的人只有 Ezra。封了 Ezra，也就等于封了 Amy、Bob 和 Debra。

这些商家没有一个是对 Ezra 本人有意见。他们的问题是只能看到 Ezra，看不到她在替谁办事。把 Ezra 换成 AI Agent，把商家换成网站，就是今天的网络。

网站主希望获得足够的可见性，既能防止不良行为，也能有效地变现或从自己的站点获取价值。但正如 Ezra 的例子所示，这种可见性在 AI Agent 面前大量消失。下面列出了一些网站主可能想要应对的行为。它们过去已有解决办法，如今却因为允许 Agent 而变得更棘手。

挑战	网站所有者的目标
账号共享	网站需要确保一份付费订阅不会被滥用、服务于大量用户。通过 Agent 访问时，网站看到的只是一个账号和一个客户端。
合规与非法活动	网站必须满足法律要求，核实用户信息。例如，部分网站有年龄或地域限制。如果允许 Agent 访问，Agent 无法提供能满足网站合规标准的保证。
友好欺诈	友好欺诈指用户认可了 Agent 的购买，随后又以未经授权为由发起拒付。网站或许能靠间接证据胜诉。同一设备、同一 IP、同一地址，与用户过去无争议的购买记录吻合，就能作为佐证。但 Agent 的购买来自 Agent 自己的基础设施，这些证据并不存在。即便网站胜诉，拒付本身也要花钱。网站需要留存结账行为记录以防欺诈。留存这些记录有助于网站减少额外验证带来的整体摩擦，降低交易拒付率，并提高结账总量。
人机验证失去意义	网站希望区分自己拥有哪些类型的用户。CAPTCHA 及其他人工验证检查的是控制浏览器的实体是不是人。Agent 从来就不被期望是人。把这一信号透传给人类用户的方案没有增加任何新信息，只会让 Agent 效率更低。
身份冒充	网站希望把内容访问限制在人类用户范围内，或对特定用户能访问什么施加限制。Agent 常常运行在住宅 IP 上、使用真实浏览器，混在人类流量之中，并刻意不把自己与人类流量区分开。攻击者会复制知名 Agent 的 user agent 字符串，以获取同样的待遇。
身份验证失效	网站可能要求对用户身份或其他信息做额外验证，才允许访问敏感操作或内容。活体检测、KYC 证件核验等机制，前提都是在场的人就是被验证的人。Agent 永远不是那个人。网站只能接受 Agent 透传过来的验证结果（这会削弱检查）、拒绝 Agent，或者干脆取消检查。
行为失准	网站可能希望保护自己免受较新或较实验性的 Agent 的错误操作影响。Agent 会犯错，比如买错商品、选错日期、重复下单。网站可能通过退款和客服来承担成本、维护客户好感，却无从判断哪些 Agent 是可靠的。
策略规避	网站想实施基于身份的策略（例如封禁、仅允许合作伙伴、限流），但 Agent 并不总是表明自己的身份，也常常不携带其所代理用户的信息。
资源耗尽	提供免费服务或依赖用户参与的网站，在设计时通常假定用户行为存在上限。Agent 会不停轮询（例如查库存、查价格），频繁请求昂贵的端点（例如搜索、库存或客服聊天），并耗尽免费试用和促销额度。
基于风险的认证失效	网站希望维持其基于风险的认证系统，该系统期望设备、位置和行为与用户相符。Agent 运行在云基础设施上，每次看起来都不寻常。
流量混杂	网站希望保护自身和用户账号免遭滥用或欺诈。当一个用户滥用共享 Agent 进行撞库、抓取或测卡时，网站能检测到滥用行为，却只能封禁该 Agent，而这会连带封禁它的所有合法用户。
未经授权的持卡人	网站和支付服务商需要保护持卡人免遭未经授权的交易，同时尽量减少拒付成本及其他与欺诈相关的成本。当授权用户用卡完成购买时，责任在持卡人。如果持卡人把卡交给非授权用户，他仍要为交出卡片负责。Agent 不具备授权用户身份，因此网站无法判断用户是否认可这笔购买。实际操作中，用户发起拒付时，掏钱的是网站。
无回报的消耗	靠内容变现的网站需要能看清并控制谁在访问内容，才能套用正确的变现模式。Agent 读取或抽取内容（文章、商品数据、评价），在别处回答用户。网站为提供内容付出成本，却换不来一次访问、一次广告曝光或一笔购买。
用户归属	网站为同意的用户提供个性化、推荐和忠诚度计划等附加能力，依赖与用户会话和设备绑定的分析数据。Agent 流量要么把许多用户归并成一个客户端，要么完全不带用户会话出现。

在上面几乎每一个挑战中，主要代价都由 Site 承担。这一结果源于存在中间方时信任的运作方式。

我们的愿景

我们的目标是这样一个互联网，所有 User 访问网站的机会都不低于从前。在 Agent 出现之前，Site 通常能靠一套技术手段缓解这些风险，包括对 User 的设备、会话和历史做指纹识别。User 仍然可以用隐私浏览模式上网，我们认为 Agent 也应该能做到这一点。但 Agent 多半没法在不经过额外验证的情况下登录银行账户。

这一切并不要求 Agent 表现得像人，也不要求每个操作都有人在场。它要求的是，Site 有办法获取或要求提供 User 的信息，从而在适用时追究其责任，无论有没有 Agent。

人们试过的办法，以及它们为什么不够

一个常见的提议是让 Agent 把 Site 的 CAPTCHA 转交给 User 去解。这只能证明那一刻有个人在场（“human in the loop”，即 HITL），仅此而已。HITL 主要是一种防止因对齐失误而出错的机制。对齐是 Operator 与 User 之间的问题，解决了它也解决不了上面的大部分问题。比如，它无法把 Bob 和其他人区分开（流量混杂），也完全说明不了其余时间里 Agent 是在替谁行事。况且，Agent 存在的意义就是消除摩擦，而 HITL 又把摩擦加了回来，所以 Operator 有动机替 User 去掉它或绕过它。

另一个常见的提议是用严格限定的访问控制。Agent 被设计成能做 User 能做的任何事，所以实践中它们会申请、也会拿到做一切事的权限。权限范围是“一切”，对 Site 来说等于什么都没说。而且即便范围很窄，它也只说明了 Agent 被允许做什么，没说 Agent 做错时由谁负责，而这恰恰是 Site 真正需要答案的问题。

网络需要什么

网络需要一套工具和协议，让站点与 Agent 能够协作判定哪些行为和操作是被允许的，也让站点能够向 Agent 表达偏好与策略，而且这一切要以所有站点和 Agent 都能合理支持的方式实现。所幸这几条战线上的工作都已在进行，其中大部分（即便不是全部）问题都可以通过套用现有标准来解决。

协议

Agent 与站点可以借助明确的协议来解决上述部分问题。例如，MOLE 就是一个正在推进的方案，目标是在不使用用户专属标识符的前提下实现限流，让站点摆脱隐式身份，转向用显式协议达成同样的目的。这与 x402 协议 类似，后者旨在让网络支付成为可能，同时保持隐私。我们正在积极探索如何利用现有协议解决其他问题，也在现有方案力有不逮时探索设计新协议。

身份

谈到 Agent 身份，Web Bot Auth（WBA）是我们首选的方法。WBA 允许 Agent 对请求签名，为 Agent 标识自身（并隐含地标识其 Operator）提供了一条安全途径。但我们仍需定义一套支持多级中间方的机制。当 Agent A 在浏览器 C 中使用 Agent B 时，站点必须能够知晓这一点，从而正确地识别并管控 Agent A 的访问，例如防止 策略规避。

其他类型的身份信息，如会话、账户乃至用户专属 ID，可能视具体场景而有必要。我们正与相关标准组织合作，探索传递这类身份信息的方式。

下面来看看与用户相关的几种身份类型。归根结底，身份是一个连续谱，在不同程度上交换关于用户的信息，同时最好遵循数据最小化原则。身份为我们提供了一种回答“你是谁？”的机制，进而回答后续两个问题：“你真的是你说的那个人吗？”以及“我们能信任你吗？”。

很多情况下，我们并不需要识别身份。Privacy Pass、MOLE 这类保护隐私的访问控制方法，能帮我们回答“能不能信任你”，而不必回答“你是谁”。Private Access Tokens 是我们早期在不识别用户身份的前提下建立信任的一种尝试，MOLE 则是这项技术的后继。不过，有些场景需要在这条谱系上采用分级披露，大致可以归为以下几类。

1. 无标识，用户在网上活动，不提供任何标识符。
2. 会话，站点需要某种方式，把同一会话内的请求关联到同一个 Agent。这样站点就能为某个会话建立信誉，并据此采取行动。例如 Poppy 就引入了会话 ID 的概念，正是为此。
3. 账户，站点需要一种方式，把跨会话的请求归属到同一个用户。这可以是 Operator 或第三方分配给用户的稳定标识符，在用户与该 Operator 的账户存续期间保持不变，比如同一个 Agent 每天用同一个标识符访问同一个站点。由此可以实现的一个用例是：“把你的站点账户绑定到你的 Agent 账户”。
4. 唯一，有些站点可能要求由第三方签发的、每个用户唯一的标识符，且该标识符跨 Operator、账户、Agent 和会话保持不变。这对高风险操作有用，也适用于需要限制访问昂贵资源、或承担严格合规义务的站点。政府身份证件、第三方身份验证，以及 Proof of Human 这类去中心化技术，都能提供这种标识。

归根结底，站点要决定自己需要哪些信息，才能让客户端回答“这个请求背后的实体，此刻是否有权执行该操作？”很多情况下，传递这些信息的协议已经存在或正在开发。WBA 传递 Agent 的平台身份，MOLE 传递用户信誉，OAuth 传递账户身份，等等。

声明

除身份之外，某些操作还需要关于真实本人的事实，例如年满 18 岁或为持卡人（身份验证失效、友好欺诈）。这类信息通常由 Operator 在注册时验证，或已由第三方掌握。

要让 Agent 访问带有此类限制的 Site 或执行带有此类限制的操作，我们需要一套机制，让 Site 能够请求这些信息，Operator 或第三方能够提供这些信息。

Site 的 Agent 访问策略

目前，Agent 只能通过逐一尝试并解读 Site 的响应（通常是看是否被封禁）来推断 Site 的规则。这对双方都是资源浪费，有时还会让守规矩的 Agent 显得像恶意流量。Robots.txt 规定了爬虫可以访问哪些位置，但并不完全适合用来表达 Agent 可以执行哪些操作。

Site 需要一种机器可读的方式来公布允许 Agent 执行哪些操作。IETF 正在积极制定相关的偏好表达机制，主要在 AI Preferences Working Group 中推进。不过该小组关注的是使用偏好（如训练、推理、搜索）的表达，目前还没有小组专门处理这里讨论的、范围更大的偏好表达机制需求。

关于开源与本地 Agent

不以“Intermediary”形式运行的 Agent（例如设备端 Agent，或 OpenClaw 这类本地托管的 Agent）带来的是另一类问题。它们看起来就是自动化程序，事实上也是，而且没有一个可为其建立信誉或追究责任的单一主体。

对此有很多解法，其中之一是要求这些 Agent 提供 Unique ID。不过这不是 Trusted Agent Delegation 最初要解决的重点。

下一步

Site 面临的这些问题，靠碎片化、厂商私有的机制解决不了。它们需要开放、可互操作、扎根于真实世界经验的标准。我们一直在与生态各方积极合作，现在仍在继续。合作对象包括主要 Operator、身份验证公司、支付服务商、商户、发布方、代理服务商和云浏览公司，目的是把运营需求直接对接到 IETF 及其他地方正在进行的相关工作。

我们的重点是弥合运行中的代码与各工作组正在制定的新兴规范之间的差距，涉及 Web Bot Auth、AIPREFs、OAuth、WIMSE 和 MOLE 等工作组和活动。为此，我们一方面参与共同编写和完善 WBA、MOLE 等开放协议，另一方面大规模构建并部署这些协议的实现。

我们同时宣布成立 Trusted Agent Delegation（TAD）联盟。TAD 的目标是汇聚生态系统中各方的代表，围绕本文提出的整体问题集展开讨论，梳理所有现有协议，并在必要时向 IETF 提出定义更明确的问题，交由 IETF 推进解决。我们计划未来在 IETF 期间举办边会，并组织研讨会，以促进讨论。

如果你在构建 Agent、Agent 运行时，运营边缘或云平台，或者负责商业、合规类应用或基础设施，我们也需要你参与进来。参与方式详见此页面。

现在就能做的事

我们的方向是建立一个开放、可互操作的基础，TAD 是第一步。但你不必等新协议落地，现在就可以重新获得可见性和控制权。从本周起，Cloudflare 客户可以采取三项具体措施。

看清哪些 Agent 在访问你的站点，以及它们在做什么。Security Analytics 现在将 Personal Assistant 单独列为一类流量，并新增一个组件，列出访问你站点的每一个 Agent、各自发送的请求数、访问的路径以及遇到的错误。原本无法解释的自动化流量，变成了可以分析的流量。至于 AI 爬虫和机器人对业务的整体影响，包括每个 Operator 抓取了多少内容、又回传了多少流量，企业版 Bot Management 客户可以使用 Business Insights。

按 Agent 自行设定访问权限。通过 AI Crawler and Agent access policies，你可以放行能带来业务的 Agent，限制带不来业务的 Agent。你可以允许某个 Agent 访问整个站点，或仅在含广告的页面上拦截它，也可以完全拦截。你的 Search 和 Training 策略保持独立。

把 Agent 和它背后的用户对应起来，并据此采取行动。对于使用 Account Abuse Protection（抢先体验）的站点，现在每次登录和注册都会显示请求是否来自个人 Agent，以及是哪一个。当攻击者在某个账号上滥用共享 Agent 时，你可以只针对该账号做缓解，用 WAF 规则匹配它的 Hashed User ID，而不必把该 Agent 对所有其他正常用户一并封掉。这是对前文所述 流量混杂（Traffic commingling）难题的第一个具体答案。你终于能越过 Agent 看到背后的用户，并据此作出响应。

这些是这一愿景的第一批构件，且已投入生产环境。随着标准逐步成熟，还会有更多跟进。

如果贵公司对 Agent 持更严格的立场，我们很想听听。欢迎直接联系我们，讲讲你遇到的问题。我们希望参与构建这样一个互联网，站点所有者既有可见性也有控制权，同时 Agent 在这些控制范围内能获得最大限度的合理访问权限。你可以联系客户支持团队，或发邮件至 crawlercontrols@cloudflare.com。