浏览器之外的 agent 身份：委托链上哪一层该被服务器看见

服务器不该只看见“一个 agent”，也不该直接看见“一个裸的用户 ID”。更可操作的划分是把委托链拆成三层分别可见：执行体（哪个 agent 在发起请求）、运营者（谁托管它、对它负责）、委托人（代表哪个用户、授了什么权）。默认让服务器看见前两层，用于分类、限速和问责；第三层按站点实际需要、经用户同意，以最小断言的形式提供。

这个划分不是现成标准，而是本文根据 Cloudflare 2026 年 11 月两篇博客中可见内容整理的分析框架。两篇文章分别讨论问题空间与已发布的产品能力，其中第一篇的抓取内容被截断，以下只依据可见部分陈述。

问题出在“中间人”，而不是“机器人”#

Cloudflare 在《Agents aren’t humans (but they kinda are)》中把远程托管的个人 agent 定义为中间人：它坐在用户与站点之间，站点看到的是它，而不是用户。云浏览器、代理和 VPN 也属于中间人，agent 只是最新的一类。变化在于规模——agent 流量增长很快，站点过去“直接封掉中间人、要求用户关掉服务”的做法会越来越不可行。来源

该文用一个助手 Ezra 的比喻说明后果：Ezra 同时替四个人跑腿，杂货店再也分不清谁的偏好；有人事后否认授权购买，店里只能证明“Ezra 来过”；有人在银行试一串密码，银行能封的只有 Ezra，而封掉 Ezra 等于封掉她服务的所有客户。换成网站与 agent，就是同一组问题。

文章由此提出一条原则：用户与站点之间的业务关系，以及各参与方的安全责任，不应因为中间化而失效。这是问题陈述，不是已完成的协议设计。

为什么只看 agent 层会坏#

材料列出的挑战可以归成几组，它们指向同一个缺口：站点需要的信息不都在“这是哪个 agent”这一层。

• 取证与纠纷：友好欺诈（用户先授权、事后否认）过去可以靠设备、IP、地址等旁证；agent 的购买来自 agent 自己的基础设施，这些旁证不存在。
• 账号与授权边界：一个付费订阅经 agent 被多人使用；站点看到的却是一个账号、一个客户端。
• 身份与合规：年龄、地区限制、KYC、活体检测都假设“在场的人就是被验证的人”，而 agent 永远不是那个人。站点只能选择接受转交的验证结果、拒绝 agent，或放弃检查。
• 策略与误伤：一个用户用共享 agent 做撞库或爬取，站点能检测到，却只能封掉整个 agent，连带封掉它的合法用户。
• 资源与计费：agent 会轮询库存价格、打昂贵接口、消耗免费额度；读取内容后在别处回答用户，站点承担服务成本却拿不到访问、广告曝光或购买。

这些不是“agent 不守规矩”的道德问题，而是可见性层级错配：站点的决策需要用户层信息，手上却只有执行体层信息。

三层各自回答什么问题#

三层的顺序不应颠倒。先确认执行体，才能谈针对 agent 类别的策略；先确认运营者，才能把“这个 agent 可信”与“这个运营者可信”区分开；只有当前两个问题不足以支撑决策时，才需要引入用户层断言。材料中“一个 agent 服务许多用户”的结构，正是要求站点不要把所有判断都压在执行体层。

用户层断言应当满足什么

材料把“以隐私感知的方式携带用户上下文”列为下一步目标，没有给出字段或协议。以下是基于该目标的工程推断，不是已发布规范：

• 受众限定：断言面向特定站点，不能被原样重放到别处。
• 范围与时效：只说明这次委托允许做什么、到什么时候失效。
• 来源可验证：由运营者或用户侧签发，站点能校验，而不是 agent 自报。
• 最小披露：能回答“是否已成年”就不必给出出生日期；能回答“是否订阅用户”就不必给出账号 ID。
• 可撤销：用户撤回委托后，站点侧能感知或至少不再接受旧断言。

这些要求与“把用户身份直接透传给每个站点”是相反方向：目标不是扩大暴露面，而是让站点在需要时拿到刚好够用的信息。

服务器侧的判断顺序#

下面是一段示意伪代码，只表达决策次序，不对应任何真实 API，也未执行：

# 示意，未执行；函数名与字段均为占位
def handle(request):
    agent = verify_agent_claim(request)        # 执行体：能验证吗？
    operator = resolve_operator(agent)         # 运营者：谁负责？
    if policy_for(agent, operator) == "block":
        return deny()
    if route_needs_user_context(request):
        assertion = verify_user_assertion(       # 委托人：按需、限定受众
            request, audience=this_site
        )
        if assertion is None:
            return limited_or_challenge()
        return serve_with(assertion.scope)
    return serve_default()

关键不在代码，而在两个约束：用户层断言是按需取的，不是每个请求都带；拒绝时优先缩小到账号或会话，而不是扩大到整个 agent。材料中“按 Hashed User ID 下发 WAF 规则、而不封禁 agent”的做法，正是后一个约束的实例。

已经能落地的部分#

在《See the agents, set the terms》中，Cloudflare 描述了已发布的分析与策略能力：Security Analytics 的 Bot Analysis 增加 Personal Assistants 类别；Top statistics 增加个人助理组件，可查看哪些 agent 来访、请求量、路径、状态码与来源网络；处于 early access 的 Account Abuse Protection 能显示每个 agent 代表哪个用户、哪些账号在用，并可在账号维度处置。来源

策略侧，原有 Agents 策略扩展为可按受支持的个人 agent 分别设置 Allow、Block on pages with ads 或 Block，设置项更名为 AI Crawler and Agent access policies。这解决的是执行体层与页面层：站点能决定“欢迎哪类 agent、在哪些页面欢迎”。

材料同时明确，agent 身份只是故事的一部分：站点可能认出请求来自哪个 agent，却仍不知道用户是否为现有客户、授权了什么、是否有订阅、该适用哪些保护。跨站携带用户上下文、评估声誉、建立问责，被列为下一步目标。

边界与待核实#

本次提供的材料没有给出委托凭证的格式、签名机制、跨运营者互操作方案，也没有说明不同司法辖区对合规检查的具体要求。把这些写成“已确定”会超出证据。可以确定的是方向：服务器需要的不止一层身份，而每一层的可见性都应有明确目的与最小化约束。

对开发者的实际含义是：在接入 agent 流量时，先把“我要回答哪个问题”写清楚——是分类限速、是账号纠纷、还是合规校验——再决定取哪一层信息。把三层混成一个不透明字符串，短期省事，长期会把误封和取证问题一起留给线上。