服务器看不到真实用户：代理代授权带来的身份断层怎么补

直接回答：断层补不上“识别 agent”这一层就够了。服务器丢的是三样东西——谁在代跑、它代表谁且被授权做什么、出问题谁负责。目前只有第一样有现成工具，后两样在 Cloudflare 2026 年 11 月 4 日和 5 日的两篇文章里仍被写成目标而非能力。所以现实做法是：先把 agent 流量看清、把处置粒度从 agent 挪到账户、按业务方式分级放行，其余部分留出接口等生态补齐。

断层的位置：中介一直存在，只是这次规模变了#

按 Cloudflare 2026 年 11 月 5 日的文章，远端托管的 Personal AI Agent 本质上是一种中介（intermediary）：任何坐在用户与站点之间、让站点看到它而看不到用户的东西。云浏览器、代理和 VPN 都算。Agent 只是最新的一种。

真正变化的是规模和形态。文章给出的描述是：agent 不疲劳、可并行、全天运行，并且能承受人类不会忍受的摩擦。这意味着一件事——原本良性的行为一旦被放大，也会变成新风险。

文章把安全与反欺诈的依赖归纳为三要素：身份（对方对自己身份的陈述是否真实）、声誉（是否可信）、问责（谁为这次行为负责）。并据此提出“中介原则”：用户与站点之间的业务关系、以及各方的安全责任，不应因为中间隔了一层而失效。这句话是判断标准，不是已经实现的机制。

断裂面：哪些原有手段会失效#

下面这些场景来自上述文章的列举，可以直接对照自己的站点自查。

注意第一条最后那类成本：文章明确指出，站点维持结账行为记录有助于减少额外验证带来的摩擦、降低拒付率、提高成交数量。也就是说，记录本身是资产，而不是合规负担。

短期能落地的三件事#

1. 先把 agent 流量从“不明自动化”变成可分类的流量

按 2026 年 11 月 4 日的文章，Security Analytics 的 Bot Analysis 图表新增了 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列；Top statistics 新增 Personal Assistants 组件，列出哪些 agent 在访问、各发多少请求，筛选后可联动查看请求路径、状态码与来源网络。工程上的意义是：你能判断这个 agent 是在登录、读商品页、走到结账，还是在它用不了的页面上报错。

2. 处置粒度从 agent 挪到账户

同一篇文章提到，使用 Account Abuse Protection（当时为 early access，可用范围待核实）的站点可以看到每个 agent 代表哪个用户：登录与注册事件会标注是否由 personal agent 发起、是哪一个；单个账户的概览页会列出为该账户服务的 agent。对可疑登录，分析师可以判断它来自用户用了数周的 agent，还是今天才出现的 agent。若确认是攻击者借某个 agent 操作某账户，可以对该账户的 Hashed User ID 下 WAF 规则，而不必对所有依赖这个 agent 的用户一起封禁。

这条是可迁移的设计思路：把封禁键从“客户端标识”换成“主体标识”。agent 标识适合用来分类和限速，不适合用来做终局处置。

3. 按页面的变现方式分级放行

文章介绍，原有的 Agents 策略扩展为对受支持的 personal agent 逐个设置：Allow（不阻断）、Block on pages with ads、Block。可以先设总体策略为“含广告页面阻断”，再对希望欢迎的 agent 单独放行。Search 与 Training 的既有策略不变，该设置项更名为 AI Crawler and Agent access policies。添加新 zone 时会询问页面是否靠广告变现，并据此给出推荐策略。

这里的取舍是业务性的：同一个 agent，一个发布方可能全站放行以便读者找到文章，另一个可能只在广告页阻断。两种都对，取决于收入结构。

一个工程化的记录模型（示意，未执行）#

下面是字段命名上的设计建议，不是任何厂商的规范，也没有实际运行过。目的是把“三层信息”在日志里分开存放，避免以后只有 agent 标识却无从追责。

{
  "request_id": "req_demo_0001",
  "agent": {
    "id": "agent_demo",
    "operator": "operator_demo",
    "verified": true
  },
  "delegation": {
    "scope": ["checkout:create"],
    "issued_at": "2026-11-08T00:00:00Z",
    "expires_at": "2026-11-08T00:10:00Z"
  },
  "subject": {
    "user_ref": "sha256:PLACEHOLDER",
    "account_age_days": 420
  },
  "action": {
    "type": "checkout",
    "amount_minor": 1000,
    "currency": "CNY"
  }
}

三点说明：subject.user_ref 只存哈希或内部引用，不存明文身份；delegation 表达的是“这个用户授权这个 agent 做这件事”，而由谁签发、如何验证签发者，来源材料未提供细节，属于待核实范围；agent.verified 只表示身份可识别，不代表可信或可问责。

边界：这些做法不要用#

• 别把人机验证当身份。agent 永远不是人，把人类的验证结果透传给站点既不加信息，也只是给它增加延迟。
• 别信 UA 字符串。文章明确写到，攻击者会复制知名 agent 的 UA 来获取同样待遇。
• 别做全局封禁。封一个 agent 等于封它背后的所有用户，这是文章反复强调的连带损失。
• 本地 agent 不在上述讨论范围内。文章明确把跑在用户自己设备或浏览器里的 agent（文中举例 OpenClaw）排除在主要议题之外。如果你的场景是本地自动化，本文的结论只部分适用。

还没解决的部分#

11 月 4 日的文章在结尾把下一步写成三件事：以隐私友好的方式（1）让用户上下文穿过 agent 传递，（2）帮助站点评估声誉，（3）在出错时建立清晰的问责。原文表述是“随着我们与 agent 运营方及生态中的其他方推进，会分享更多”。

换句话说，截至材料抓取时，这三项是方向而非可调用的能力。具体的传递格式、验证方式、是否收费、覆盖哪些 agent，均待核实。不要基于“已有标准”做架构假设；更稳妥的做法是把 delegation 与 subject 字段先在日志里留出来，等上游形态明确再填充。

结论#

身份断层的补齐顺序是：先让 agent 流量可分类，再把处置键换到账户维度，再按页面的收入方式决定放行粒度。这三步今天就能做，且不依赖任何未落地的标准。把“携带用户授权上下文”和“建立问责”当作接口预留项，而不是现有能力——这样即使上游方案变化，你的日志与策略层也不需要重写。