代理作为中间层：用户身份字段被剥离后的工程问题

先把结论说清楚：当代理（Agent）代替用户访问网站时，站点原本从直连请求里能读到的一整组用户身份字段——账号归属、设备与位置旁证、支付授权状态、合规信息——在中间层被替换成了代理自身的信号。工程上的难点不是“认不出这是自动化流量”，而是认出来之后仍然不知道背后是谁、此人授权了什么、出事由谁负责。Cloudflare 在 2026 年 11 月初的两篇文章里把这个问题拆成身份、信誉、问责三块，并给出了当前的可见性与策略能力。本文按开发者视角整理这些事实，并给出明确标注为推断的核对清单。

中间层改变了请求链路的形状#

按第一篇的定义，个人 AI 代理是接受人类指令、通过控制云电脑或浏览器来追求目标的自动化程序，通常由某个 Operator 以托管服务或消费级产品的形式运行。关键判断是：远程托管的代理本质上是一个中间层，和云浏览器、代理服务与 VPN 属于同一类东西——它坐在用户和站点之间，于是站点看到的是它，而不是用户。

这带来三种拓扑：没有代理时用户直连站点；有代理时站点看到代理，且一个代理可以同时替多个用户行动；有时用户与站点之间还叠着好几层中间层。同一篇文章把本地代理（例如运行在用户自己设备或浏览器里的代理）划在讨论范围之外，本文沿用这一边界。

原文用了一个助理跑腿的比喻：杂货店老板以前认识常客，知道她买什么；现在只见到助理，手里拿着四个人的订单，分不清偏好属于谁。换成网站，就是站点仍要完成风控、变现与合规，但可用的用户侧信息变少了。

被剥离的字段清单#

下表左列是站点过去默认能拿到的信号，中列是经过代理后实际看到的东西，右列是直接后果。前两列依据第一篇正文中列出的挑战整理；右列是按其含义做的归纳。

把这些行放在一起看，会发现它们是同一件事的不同侧面：中间层把“主体身份”和“通道身份”压成了一个字段。站点能判断通道是谁，却失去了主体是谁。原文还提到身份仿冒：代理常跑在住宅 IP 上、使用真实浏览器，并尽量不把自己与人类流量区分开；攻击者则复制知名代理的 User-Agent 字符串来获取同样的放行待遇。这意味着仅凭自报身份做识别，在对抗环境下并不可靠——这一点是推断，但它与原文列出的现象一致。

为什么“把人类信号透传回来”不是答案#

第一篇给出了一个明确判断：代理从不预期自己是人类，把“由人类通过验证”这个信号透传给站点不增加新信息，只会让代理更低效。同理，把 CAPTCHA 结果、设备指纹原样带回，也无法回答站点真正要问的三个问题：行为者对自己的身份是否诚实、是否可信、由谁为这次行为负责。原文把这三件事对应到身份（Identity）、信誉（Reputation）与问责（Accountability），并认为生态需要新机制来维持站点与用户之间的关系，而不是让站点在“全封”和“全放”之间二选一。

当前可用的两件事：看见与分级#

第二篇给出了已经发布的能力，范围限于“受支持的个人代理”，并非所有代理都能被识别，这是使用时必须注意的边界。

• 观测：Security Analytics 的 Bot Analysis 图新增 Personal Assistants 类别，可与其他类别并列筛选；Top statistics 新增同名组件，列出访问站点的代理及各自请求量，筛选某个代理后可查看其请求路径、返回状态码与来源网络。
• 账户维度：在 Account Abuse Protection（材料标注为 early access）中，站点方与反欺诈团队可以看到某个代理代表哪个用户、哪些账户在用同一个代理；登录与注册事件会标注是否由代理发起、是哪一个；账户概览显示该账户关联的代理。若怀疑攻击者借代理操作某账户，可以按该账户的 Hashed User ID 施加 WAF 规则，而不必封掉依赖同一代理的其他用户。
• 策略分级：在 Security Settings 中可设置整体 Agents 策略，再对每个受支持的代理单独选择 Allow、Block on pages with ads 或 Block；原设置更名为 AI Crawler and Agent access policies，Search 与 Training 策略保持不变。新增站点时也会按“页面是否靠广告变现”给出推荐策略。

这里值得开发者注意的是封禁粒度的变化：从“封代理”改为“按账户哈希封”，等于把中间层身份与主体身份分开处理。但它的前提是站点能拿到账户标识；对未登录路径，这个前提不成立。原文中“按账户处理”与“按代理处理”是两种不同粒度，不能互相替代。

尚未解决的部分#

第二篇把下一步目标写成三件事：以隐私友好的方式让用户上下文穿过代理、帮助站点评估信誉、在出问题时确立清晰的问责。文章没有给出字段格式、签名方式、验证流程或时间表，本次材料也未提供这些细节，具体机制待核实。因此，任何“现在已经能稳定拿到代理背后的用户身份”的说法都超出了材料支持的范围；能确认的是账户维度可见性已在 early access 中出现，且限于受支持的代理。

一份推断性的工程核对清单#

以下条目由上述事实推导而来，材料未给出实现方案，不构成对任何接口的调用说明。

1. 先分类，再定策略：按代理维度统计请求量、路径、状态码，判断它是在登录、读商品页、走到结账，还是反复撞在打不开的页面上。没有这份分布，策略只能拍脑袋。
2. 把封禁落到最细可用粒度：账户哈希优先于代理标识，代理标识优先于 IP；拿不到账户时，至少保留可回溯的关联 ID，避免一次处置波及全部用户。
3. 高风险操作不依赖透传验证：支付、改密、KYC 这类操作若接受代理转述的“已验证”，校验强度实际被削弱；需要在本端重新校验或降级处理。
4. 按变现路径分策：有广告的页面与结账路径可以用不同策略，这也是现有策略选项划分的依据。
5. 为争议保留证据：友好欺诈的核心是“用户是否授权”，代理会话与账户之间的关联记录比设备指纹更有用。
6. 不要把 CAPTCHA 当身份方案：它能区分控制浏览器的是不是人，但代理从来不是人，这个问题问错了对象。

下面是一段字段组织示意，未执行，仅用于说明“主体、通道、授权、验证强度”应当分开记录；其中的值都是占位，材料未定义任何真实字段名或格式。

{
  "request_id": "req_demo_0001",
  "agent": { "id": "agent_demo", "operator": "operator_demo" },
  "subject": { "account_hash": "HASH_PLACEHOLDER", "asserted_by": "agent" },
  "authorization": { "scope": "checkout", "expires_at": "2026-11-07T00:00:00Z" },
  "verification": { "method": "passthrough", "trust": "unverified" }
}

最后需要强调的是边界：这是一个关于数据契约与责任边界的问题，不是一个检测规则能解决的事。识别出代理只是第一步，站点仍要决定在缺失用户字段的情况下，哪些操作可以照常、哪些必须回到本端校验、哪些要按账户而不是按通道处置。