个人 agent 访问网站：中间层剥离后还剩哪些身份字段

先说结论：当个人 AI agent 作为中间层替用户访问站点时，服务器能拿到的基本只剩三样东西——agent 自身的标识、它所在的基础设施、以及它发出的请求行为。用户是谁、授权了什么、是不是既有客户、有没有订阅，这些字段在中间层被剥离。唯一的例外是请求本身携带登录态：这时站点可以用账号维度把 agent 和某个具体用户关联起来，但关联的是"账号"，不是"人"。

这个划分来自 Cloudflare 在 2026 年 11 月发布的两篇文章：一篇讨论 agent 委派中的身份、声誉与问责问题（Agents aren't humans (but they kinda are)，2026-11-05），另一篇介绍面向个人 agent 的可见性与访问控制能力（See the agents, set the terms，2026-11-04）。需要说明：第一篇在本次材料中被截断，其结论部分未提供，下文只引用已给出的段落；两篇文章描述的是厂商能力与问题空间，不是对任意站点现状的测量。

一、剥离之后，字段还剩几层#

把一次经由 agent 的请求拆开看，站点实际拿到的信息可以分成四层。

• 网络与传输层：源 IP、自治系统、TLS 指纹、请求头顺序等。Cloudflare 指出 agent 常跑在住宅 IP 上、使用真实浏览器，因此这一层的区分力在下降——它看起来可能和你的一般访客没有区别。
• agent 标识层：User-Agent 字符串、以及是否命中经过验证的 bot 目录。Cloudflare 表示其 Security Analytics 的 Bot Analysis 图新增了 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列。但同一篇文章也承认，攻击者会复制知名 agent 的 UA 字符串来获得同样的放行待遇，所以 UA 单独不可作为依据。
• 账号层：登录态、会话、以及站点内部的用户主键。只有请求带着登录态时，站点才能把 agent 与某个账号对上。Cloudflare 在 Account Abuse Protection（材料标注为早期访问）中提供的"每个 agent 代表哪个用户"、登录与注册事件标注、账号概览里的 agent 列表，都属于这一层。
• 行为层：请求路径、状态码、请求频次、是否到达结账页。这些不是身份字段，但能回答"这个 agent 在做什么"。按单个 agent 过滤后，其他图表会联动展示它请求的路径、收到的状态码和来源网络。

二、丢掉的字段：身份、授权、声誉、问责#

第一篇材料提出的"中间层原则"（Intermediation Principle）认为，用户与站点之间的业务关系、以及各方的安全责任，不应因为中间层的存在而失效。落到可核对的字段上，站点原本能回答四个问题，现在答不全了：

第二篇材料把这件事讲得更直接：站点可能认出了发起请求的 agent，但缺少原本会有的用户信息——是不是既有客户、授权 agent 做了什么、有没有订阅、该套用哪些保护措施。

三、这些缺口落到具体场景是什么样#

第一篇材料列了一份较长的场景清单，这里挑几项与开发者实现关系最近的：

• 账号共享：一份付费订阅被用来服务多人时，站点看到的仍是一个账号、一个客户端。
• 友好欺诈：用户批准了 agent 的购买后又否认授权。过去站点可以用"同一设备、同一 IP、同一地址"作为旁证，而 agent 的购买来自 agent 自己的基础设施，这些旁证不存在。
• 人机验证失效：CAPTCHA 判断的是"控制浏览器的是不是人"。agent 本来就不是人，把这一信号透传回用户不增加任何新信息。
• 身份验证被削弱：活体检测、证件核验都假设"在场者即被核验者"。站点只剩三个选项——接受 agent 转交的验证结果（削弱检查）、拒绝 agent、或放弃检查。
• 流量混杂：一个用户滥用共享 agent 做撞库或扫号时，站点能检测到滥用，但只能封禁该 agent，连带封掉它的全部正常用户。
• 无补偿消费：agent 读取内容去别处回答用户，站点承担了服务成本，却没有获得访问、广告曝光或成交。

这些是材料给出的问题归类，不是对某类站点发生频率的统计。

四、站点侧目前能做的两件事：看见、设条件#

第二篇材料描述的能力可以归纳为两步。

第一步是看见。在 Security Analytics 中按 Personal Assistants 类别筛选，再用 Top statistics 里的新组件查看是哪些 agent 在访问、各发多少请求；选中一个 agent 后，其他组件联动显示它的路径、状态码与来源网络。对于启用了 Account Abuse Protection 的站点，还能看到 agent 与用户账号的对应关系、每次登录与注册是否由 agent 发起，并在账号维度上用 Hashed User ID 下 WAF 规则——这样处理的是一个被滥用的账号，而不是把这个 agent 的所有用户一起封掉。

第二步是设条件。原有的 Agents 策略扩展为可按"受支持的个人 agent"逐个设置，选项为 Allow（不阻止）、Block on pages with ads（在带广告的页面上阻止）、Block。站点可以先设一个总体策略，再对个别 agent 覆盖。材料给出的例子是：总体设为"在带广告的页面上阻止"，再对希望欢迎的某个 agent 单独放行。原有的 Search 与 Training 策略保持不变，该设置项也更名为 AI Crawler and Agent access policies。

注意适用范围：材料反复使用 "supported personal agents" 这一限定。哪些 agent 在支持名单内、早期访问能力对哪些套餐开放、是否有额外计费，本次材料未提供，属于待核实项。

五、开发者可以按这份清单核对#

下面是一个字段核对清单，用于判断自己的站点在中间层剥离后还能拿到什么。它不是可执行代码，也没有在任何环境运行过；把它当作记录模板即可。

{
  "request_layer": {
    "source_ip": "占位：是否为住宅/云主机段",
    "asn": "占位",
    "tls_fingerprint": "占位"
  },
  "agent_layer": {
    "user_agent": "占位：是否被验证目录覆盖，还是仅靠自报",
    "verified_bot": "占位：true / false / unknown（未知就写 unknown）"
  },
  "account_layer": {
    "session_present": "占位：请求是否携带登录态",
    "hashed_user_id": "占位：仅在已登录时可关联"
  },
  "missing_layer": [
    "用户是否为既有客户",
    "用户授权 agent 的范围",
    "订阅或权益状态",
    "该 agent 的历史信誉"
  ]
}

据此可以逐条问自己：

1. 我用来判断"这是哪个 agent"的依据，是经过验证的目录结果，还是仅仅一个可被复制的 User-Agent？
2. 我的风控逻辑里，有多少条规则默认"设备/IP 与用户历史一致"？这些规则在 agent 场景下会静默失效还是报错？
3. 当我要处置一个滥用行为时，能否只针对账号（Hashed User ID）而不波及同一 agent 的其他用户？
4. 我的访问策略粒度是"全部 agent 一个开关"，还是能对个别 agent 覆盖？策略默认值是什么，未识别的 agent 落到哪一档？
5. 封禁一个 agent 会连带影响多少正常用户？这个数字我能否在处置前看到？

六、边界与仍待核实的地方#

材料本身也划了范围。第一篇明确把本地 agent（运行在用户自己设备或浏览器里的 agent，例如文中提到的 OpenClaw）排除在主要讨论之外；本文讨论的都是远端托管、由运营方维护的个人 agent。"agent 流量可能在不远的将来超过传统人类浏览"是来源给出的趋势判断，不是测量结果。

此外，以下几点在本次材料中没有答案，应按待核实处理：支持的个人 agent 名单、Account Abuse Protection 的正式可用时间与准入条件、上述分析数据的保留期限、以及跨运营方传递用户上下文的具体机制。第二篇材料把"携带用户上下文、评估声誉、建立问责"列为下一步目标，说明这部分目前还没有落地成可对接的字段。

对开发者的实际含义是：现阶段能做的是把"agent 是谁"和"账号是谁"这两层尽量分开记录，并在策略上留出按 agent 覆盖的余地。至于"用户授权了什么"，短期内仍然拿不到，需要在自己的业务流程里补记录。