委派链路该保留哪些用户身份字段：AI agent 流量穿过中间层之后

先说结论：在 AI agent 代表用户访问网站的链路里，被中间层剥离的不只是“这是不是一个机器人”，而是站点原本能从直接会话中读到的用户上下文。要让委派链路可核对，需要保留的字段大致分四类——主体引用（agent、operator 与用户各自的可解析标识）、委派范围（用户授权 agent 做什么）、授权证据（谁签发、何时、能否验证）、操作与问责锚点（这次动作由谁在什么版本上执行、出问题谁承担）。需要强调的是：这四类是设计建议，不是已发布的协议标准；本次材料只明确了问题空间和部分产品能力，字段级的公开规范仍待核实。

中间层剥离的到底是什么#

Cloudflare 在 2026 年 11 月 5 日的文章中把 agent 归入“中间层”（intermediary）：任何坐在用户与站点之间、使站点看到它而不是用户的东西。云浏览器和代理（包括 VPN）早就是中间层，agent 只是最新的一种。区别在于规模——文章称 agentic 流量增长很快，并可能在不久的将来超过传统的人类浏览（来源：Agents aren't humans (but they kinda are)）。

同一篇文章给出的判断原则是：用户与站点之间的业务关系、以及各参与方的安全责任，不应因为中间层的存在而失效。这条原则落到工程上，就是站点需要重新获得三样东西——身份（Identity）、信誉（Reputation）、问责（Accountability），对应三个问题：行为方对自己身份的陈述是否属实？这个人是否可信？出了问题谁来负责？

文章列出的受损场景可以归并成一条线索：站点过去依赖“直接会话”做出的判断，现在失去了依据。

• 账号共享：站点看到的是一个账号和一个客户端，无法判断一份付费订阅是否被用来服务多个用户。
• 友好欺诈：用户先批准 agent 下单、事后否认授权。过去的旁证是同一设备、IP、地址，而 agent 的购买来自 agent 自己的基础设施，这类证据不存在。
• 身份验证失效：活体检测、KYC 证件核验都假设“在场的人就是被验证的人”，而 agent 永远不是那个人。站点只能在三种做法里选：接受 agent 转述的验证结果（削弱检查）、拒绝 agent、或放弃检查。
• 流量混杂：一个用户滥用共享 agent 做撞库或测卡，站点能检测到，但只能封禁整个 agent，连带封掉它所有的正常用户。
• 资源耗尽与无补偿消耗：agent 可以持续轮询价格与库存、打昂贵的搜索和客服端点；也可以把内容读走去别处回答用户，站点承担了服务成本却拿不到访问、广告曝光或成交。

这些不是“识别 agent”能解决的问题。认出 agent 只回答了链路的一端，另一端——它代表谁、被授权做什么——仍然是空的。

委派链路可保留的四类字段#

下面的分层是笔者的整理建议，用于组织讨论与实现核对；材料本身没有给出字段清单。判断某条信息该不该进链路，可以用一个简单标准：没有它，站点是否就只能退回到“封掉整个 agent”这一种选择。

1. 主体引用：agent、operator、用户三层都要有可解析标识

Cloudflare 在 2026 年 11 月 4 日的文章里介绍了已有的可见性能力：Security Analytics 的 Bot Analysis 图中新增 Personal Assistants 分类，Top statistics 中新增 Personal Assistants 组件，可以查看哪些 agent 在访问、各自发了多少请求、请求了哪些路径、返回了什么状态码、来自哪些网络（来源：See the agents, set the terms）。这解决了 agent 一侧的标识。

用户一侧，材料提到 Account Abuse Protection（早期访问）能让站点与反欺诈团队看到“每个 agent 代表哪个用户”，账号概览页会显示该账号上有哪些 agent 在操作。文章还提到，怀疑攻击者通过 agent 操作某账号时，可以针对该账号的 Hashed User ID 下发 WAF 规则，而不必封掉所有依赖这个 agent 的用户。

据此，主体引用至少包含：agent 标识、operator 标识、用户的稳定引用（例如经哈希的 ID）。建议不要传原始 PII：站点需要的是能与自己已有账号体系对上号的引用，而不是又一份需要保管的身份数据。

2. 委派范围：用户到底授权了什么

材料把“用户授权 agent 做了什么”明确列为尚未解决的问题之一——站点可能认出了 agent，却不知道背后的用户是不是老客户、有没有订阅、授权范围到哪里。这是友好欺诈与越权操作的共同缺口。

建议记录的维度包括：动作类型（浏览、登录、加购、支付）、资源范围（哪些页面或端点）、有效期、是否允许再委派给下一层中间层。最后一项目前尤其容易被忽略：材料指出有时用户与站点之间不止一层中间层，如果允许链式委派而不记录深度与转授关系，问责会在这里断掉。

3. 授权证据：谁签发的、能不能验

仅有“用户说可以”的声明没有价值，站点需要能验证的凭据。这一层的不确定性最大：材料只说 Cloudflare 的目标是用“隐私友好的方式”携带用户上下文、帮助站点评估信誉、建立问责，并会与 agent operator 及生态各方继续推进；具体机制与字段形态待核实。

实现时可以先明确边界：授权证据证明的是“这次委派关系成立”，它不等同于身份核验。材料明确指出 agent 无法满足 KYC 与活体检测的假设，把这两件事混为一谈，会得到一个看起来完整、实际不成立的合规结论。

4. 操作与问责锚点：为争议留下可回放的记录

材料里“友好欺诈”“错位（agent 下错单、重复下单）”“未授权卡使用”三类场景都指向同一个需求：争议发生时，站点要能证明用户当时确实授权了这次动作。建议字段包括：动作发生时间、agent 版本或运行环境标识、operator 主体、以及争议时的责任归属方。

一个示意性的委派声明（未执行）#

下面的 JSON 仅用于说明字段如何组织，字段名是自拟的占位设计，未在任何环境执行或验证，也不对应任何已发布规范。

{
  "agent": {
    "id": "agent_example_001",
    "operator": "operator.example.com",
    "version": "YOUR_AGENT_VERSION"
  },
  "subject": {
    "ref": "hashed-user-id-placeholder",
    "ref_type": "site_scoped_hash"
  },
  "delegation": {
    "actions": ["browse", "checkout"],
    "resource_scope": ["/products/*"],
    "expires_at": "2026-11-08T00:00:00Z",
    "redelegable": false,
    "chain_depth": 1
  },
  "evidence": {
    "issuer": "operator.example.com",
    "issued_at": "2026-11-07T00:00:00Z",
    "verification": "待核实"
  },
  "accountability": {
    "responsible_party": "operator.example.com",
    "dispute_contact": "placeholder@example.com"
  }
}

注意其中两处刻意的留白：verification 与时间、版本类字段都写成占位，因为本次材料没有给出可核验的取值方式。把不确定项显式留在配置层，比填一个看起来合理但无法验证的值更安全。

不能靠字段解决的边界#

• 人工验证不会因此变得有意义。材料指出 agent 从来不是人类，把“通过人机验证”这个信号透传给背后的用户不增加任何新信息，只会让 agent 更慢。
• 身份核验仍是另一件事。委派证据能说明关系存在，不能说明屏幕前的人是谁。年龄限制、地域限制这类合规要求，材料明确说 agent 无法提供满足门槛的保证。
• 携带上下文本身会制造新的隐私面。材料把“隐私友好”作为前提条件写进了目标，实现时如果直接把用户标识与行为明细透传给每个站点，等于用一个新的追踪面换掉旧的可见性缺口。
• 字段不能替代信誉判断。材料把信誉与问责并列为独立目标，说明仅靠声明无法区分可靠的 agent 与经常出错的实验性 agent。

落地顺序：先看清，再定策略，最后谈上下文#

材料里 Cloudflare 的产品路径本身就提供了一个可参考的顺序：先做可见性（哪些 personal agent 在访问、访问了什么），再给分档策略，最后才是用户上下文与问责。

1. 先建立基线：把自动化流量按 agent 类别拆开看，记录路径、状态码与来源网络，确认这些流量对业务是帮助还是风险。
2. 再定策略：材料给出的策略枚举是 Allow（不阻断）、Block on pages with ads（在带广告的页面上阻断）、Block，并支持对整体 Agents 策略与单个受支持的 personal agent 分别设置。文章提到该设置项已更名为 AI Crawler and Agent access policies。
3. 然后才引入用户上下文：在能看到“哪个 agent 替哪个账号操作”之后，再讨论把委派范围与授权证据带进链路，避免一开始就把最敏感的部分暴露出去。
4. 始终保留单账号处置能力：材料中按 Hashed User ID 下发 WAF 规则的做法，是把处置粒度从 agent 降到账号的关键；如果只能整包封禁，误伤成本会迫使你放弃大部分策略。

还需核实的事项#

• 委派链路的字段级规范、签发与验证机制：本次材料只描述了目标，没有给出协议细节。
• Account Abuse Protection 的开放范围与时间：材料标注为早期访问（early access）。
• 受支持的 personal agent 名单与 operator 范围：材料未列举完整清单。
• 信誉评估的数据来源与判定口径：材料将其列为下一步方向，尚无公开方法。

对开发者而言，当下能做的不是等待标准落地，而是先把自己这一侧的记录做对：分清 agent、operator 与用户三层标识，为每次委派动作留下时间、范围与责任方，把无法验证的部分明确标成待核实而不是填默认值。这样等生态给出字段规范时，替换的是字段名，而不是整套记录逻辑。