Agent 执行链的委派语义：服务器如何区分用户、代理与中间层

服务器不能仅凭一个信号回答这个问题。更准确地说，它需要把请求拆成三层：请求是不是自动化、是哪一个 agent 与运营方、这个 agent 代表哪个用户以及被授权做什么。前两层是“识别中间层”，第三层才是“委派语义”。截至本文可见的材料，Cloudflare 已提供部分识别与策略能力，但完整的委派上下文仍在建设中；具体协议字段、签名格式和跨厂商互操作待核实。

中间层把“用户”从请求里拿掉#

Cloudflare 在 2026 年 11 月 5 日的文章中把远程托管的个人 AI agent 定义为：接受人类指令、通过控制云电脑或浏览器追求目标的自动化，通常由 Operator 作为托管服务运营。对站点来说，这类 agent 是中间层：任何位于用户和站点之间、让站点看到它而不是用户的东西。云浏览器、代理和 VPN 也是中间层，agent 只是最新的一种。

关键变化不是“出现了自动化”，而是关系被截断。没有 agent 时，用户直接访问站点；有 agent 时，站点看到 agent，一个 agent 可能代表许多用户。文章提出一条原则：用户与站点之间的业务关系，以及各参与方的安全责任，不应因为中间化而消失。传统上，这要求站点回答身份、声誉、问责三个问题：操作者是否如实表明身份、是否可信、出问题谁负责。agent 和其运营方也需要可识别、可问责，因为 agent 能做出人类做不到的规模和速度。

现有信号的能力边界#

把材料中的挑战归纳成下表，可以看出“区分”不是二选一判断，而是多个问题。

Cloudflare 在 2026 年 11 月 4 日的文章里宣布，Security Analytics 的 Bot Analysis 增加 Personal Assistants 类别，Top statistics 增加相应组件，列出哪些 agent 访问站点及各自请求量，并可下钻到路径、状态码和来源网络。这是“识别 agent”的可见性层，不等于识别用户。

站点还需要知道 agent 代表谁。材料提到，在 Account Abuse Protection（早期访问）覆盖的范围内，站点和反欺诈团队可以看到每个 agent 代表哪个用户、哪些 agent 在用户群中活跃，以及登录和注册是否由 personal agent 发起、是哪一个。若怀疑攻击者利用 agent 操作账号，可按该账号的 Hashed User ID 下发 WAF 规则，而不是把 agent 对所有用户封掉。该功能的区域、套餐和正式可用时间待核实。

委派语义至少要回答四个问题#

本文所说的“委派语义”，指请求沿执行链传递时，对“谁在操作、代表谁、被授权做什么、谁负责”的可验证表达。它不是单个 HTTP 头，也不是把用户信息明文塞进请求。材料把未来方向概括为隐私感知地携带用户上下文、评估声誉、建立问责；这仍是目标，不是已发布标准。

• 主体：请求背后是哪个用户。至少应有稳定假名或哈希标识，避免明文暴露；材料中的 Hashed User ID 是账号级缓解的例子。
• 代理与运营方：是哪一个 agent、由哪个 operator 运营。仅有 UA 不够，需要可验证目录或签名机制；具体机制待核实。
• 授权范围：用户允许 agent 做什么，例如比价、读取内容、登录、下单，以及金额、时间、路径等限制。材料提到站点可能缺少“是否现有客户、授权了什么、是否有订阅、应适用哪些保护”等信息。
• 责任：出错时谁承担退款、争议、滥用成本，如何审计和申诉。这是身份与声誉之外的第三根支柱。

这四个问题不要求所有站点一次性实现。它们是设计委派上下文时的检查维度；字段名、传输方式和验证协议都应以实际采用的规范为准。

一个可落地的分层顺序#

从工程角度看，先做能观测的，再做能关联的，最后做能验证的，比较稳妥。

1. 观测：把 personal agent 流量从“未知自动化”里分出来，按 agent 看请求量、路径、状态码和来源网络。材料中的 Bot Analysis 与 Top statistics 属于这一层。
2. 账号关联：在登录、注册、结账等事件上记录 agent 标识，并尽量关联到账号哈希；异常时按账号缓解，避免全局封 agent。注意早期访问功能的覆盖边界。
3. 策略：材料提到可在 Security Settings 设置整体 Agents 策略，再为受支持的 personal agent 选择 Allow、Block on pages with ads、Block。公开内容与广告变现页面可以采用不同策略；支持哪些 agent、哪些套餐可用待核实。
4. 委派上下文：在协议未定前，至少为日志和策略决策预留字段；对敏感操作增加用户侧确认，作为过渡性建议。不要把自造的“信任头”当成跨厂商标准。

下面是一个日志关联维度的演示，字段名为本文占位，不是任何已发布协议，也未执行：

{
  "agent_id": "agent_demo",
  "operator": "operator.example.com",
  "account_hash": "HASHED_USER_ID",
  "delegation_scope": ["read:product", "checkout"],
  "policy_decision": "allow_on_non_ad_pages"
}

这段示例只说明站点希望把“哪个 agent、哪个运营方、哪个账号、什么范围、做了什么策略决定”放在同一条记录里。真实实现需要签名、过期时间、撤销机制和隐私评估；这些在材料可见部分没有给出，不能当成现成能力。

边界与常见误区#

第一，识别 agent 不等于识别用户。已验证目录能回答“它可能是谁”，不能回答“它代表谁、是否获授权”。第二，CAPTCHA 不能证明委派关系；agent 本来就不是人类，材料明确指出这类信号没有新增身份信息。第三，直接封 agent 可能误伤大量合法用户，因为一个 agent 可以服务许多用户；账号级缓解更精细，但依赖账号关联能力。第四，携带用户上下文必须做隐私设计，材料强调 privacy-aware，而不是明文透传。第五，本文讨论以远程托管 agent 为主；材料明确本地 agent 或用户自己浏览器内的 agent 不在该文主要范围内。最后，本文对第一篇的引用仅限抓取片段可见部分，该片段已截断，完整结论以原文为准；相关产品的套餐、区域与支持范围待核实。

给开发者的检查清单#

• 日志中分开记录 agent 标识、operator、账号哈希、授权范围、策略决策；不记录明文凭证或真实密钥。
• 按路径和商业模式配置策略：公开内容、广告页、结账和敏感操作不必同一规则。
• 异常登录或滥用优先按账号哈希缓解，避免把整个 agent 封禁；确认所用功能是否处于早期访问。
• 敏感操作增加用户侧确认；不要把 CAPTCHA 或 UA 当作委派证明。
• 监控 agent 的登录、注册、结账事件与错误率，用数据判断哪些 agent 可靠；材料没有给出通用阈值。
• 在协议未定时，为委派上下文保留接口，但不要自造不兼容的信任链；等待可验证、隐私感知的标准或产品能力。

区分用户、代理与中间层，最终不是给请求打一个“人/机器人”标签，而是恢复被中间层截断的关系：agent 可识别，operator 可追溯，用户可关联，授权可限定，责任可落实。Cloudflare 已提供部分可见性和策略工具，完整委派语义仍在推进；对开发者而言，先把观测和账号级控制做扎实，再为委派上下文留出接口，是当前更可控的路径。