给 agent 流量建立可识别的委派语义：服务器端如何区分人、代理与中间层

服务器端今天能较稳定回答的，是“这个请求属于哪一类自动化、它自称是哪个 agent”；还不能仅凭请求本身回答“它代表哪个用户、被授予了什么权限”。前者靠流量特征与已注册的 agent 目录，后者需要一层显式的委派声明。Cloudflare 在 2026 年 11 月的两篇文章中把这个问题拆成身份、声誉、问责三件事，并给出了第一阶段的可见性与访问控制；至于委派协议长什么样、字段如何定义，材料只说了“会继续分享”，属于待核实范围。

先定义中间层：三种拓扑，日志列数不同#

按第一篇的定义，中间层是任何位于用户与站点之间、使站点看到它而不是用户的东西。远程托管的 agent 是最新的一种，云浏览器和代理（含 VPN）早已存在。Agents aren’t humans (but they kinda are) 把这个结构画成三种情形：没有 agent 时用户直连站点；有 agent 时站点看到 agent 而看不到用户，且一个 agent 同时代表多个用户；有时用户与站点之间还叠着好几层中间层。

这个划分直接决定日志设计。只有第一种拓扑时，一条请求对应一个用户；第二、三种拓扑下，“请求数”与“用户数”不再是同一个量。如果日志里只有 IP、UA 和路径，事后无法把一次异常行为归到具体账号，也无法证明某笔操作是哪个用户授权的。工程上至少要能回答：这条请求的 operator 是谁、agent 实例是谁、它声称代表哪个账号、这个声称来自哪一层。

服务器端能拿到的信号，按可伪造程度分层#

下面这张表是工程判断，不是来源结论；材料只提供了各信号为何不可靠的具体描述。

把这几层混成一个“是不是 bot”的布尔值，是很多实现出问题的地方。前两层只能支撑限流与观测，不足以支撑授权。

委派语义要回答的三个问题#

第一篇把安全与反欺诈的传统要求归纳为身份、声誉、问责，对应三问：行为者对自己是谁是否诚实？这个人是否可信？出了问题谁来负责？换成 agent 场景，三问的落点分别是：

• 身份：问题不是“是不是人”，而是“这个 agent 由哪个 operator 托管、代表哪个用户”。材料指出，agent 目前不总能提供满足站点合规要求（如年龄、地域限制）的保证。
• 声誉：站点需要判断某个 agent 是否可靠。材料把“错位”列为一项挑战——较新或实验性的 agent 会下错单、选错日期、重复提交，站点只能用退款和客服消化成本，却无法分辨哪些 agent 可信。
• 问责：当一次购买被用户否认时，站点要能证明是用户授权的。材料用“友好欺诈”和“未授权卡用户”说明，agent 交易来自 agent 自己的基础设施，缺少“同一设备、同一 IP、同一地址”这类间接证据。

第一篇文章的立场可以概括为一句话：用户与站点之间的业务关系、以及各方的安全责任，不应因为中间层的存在而失效。这句话是原则，不是实现；它解释了为什么仅做“封或放”的判断不够。

人类验证在这里为什么失效#

CAPTCHA 一类机制检验的是控制浏览器的实体是不是人。材料明确写道：agent 从不被期望是人，把通过验证的信号透传给背后的用户不增加任何新信息，只会让 agent 更没效率。由此可以推出一条设计建议：不要把“通过人机验证”当作授权凭据写进业务逻辑。真正需要的是“谁授权了什么”，而不是“当时有人在屏幕前”。

从可见性到策略：一个可分四步的落地顺序#

第二篇See the agents, set the terms 公布的能力，可以当作一个参考实现顺序：

1. 观测：Security Analytics 的 Bot Analysis 图新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列；Top statistics 新增 Personal Assistants 小部件，列出哪些 agent 在访问、各发多少请求，并可按单个 agent 过滤查看路径、状态码与来源网络。
2. 账号关联：使用 Account Abuse Protection（材料标注为 early access）的站点，可以看到每个 agent 代表哪个用户；每次登录与注册事件会显示是否由 agent 发起以及是哪一个，账号概览也会列出该账号关联的 agent。
3. 策略：原 Agents 策略扩展为可按受支持的单个 agent 选择 Allow、Block on pages with ads、Block；设置项更名为 AI Crawler and Agent access policies，原有 Search 与 Training 策略保持不变。
4. 缓解：当怀疑某个账号被利用时，可对该账号的 Hashed User ID 下发 WAF 规则，而不是封掉整个 agent、连带影响其他依赖它的用户。

这个顺序值得借鉴的地方在于：先有可核对的数据，再有策略；先能定位到账号，再做阻断。反过来做，很容易把“某个 agent 的一次滥用”扩大成“所有用这个 agent 的用户都进不来”。

一个未执行的决策示意

下面的片段只示意判断顺序，字段名均为占位，材料未给出任何真实 header 名称，也未运行过。

# 未执行示例：仅示意分层，不依赖任何真实服务
def classify(req, known_agents, account_events):
    declared = req.headers.get("x-agent-id")        # 占位字段名
    operator = req.headers.get("x-agent-operator")  # 占位字段名

    if declared and declared in known_agents:
        tier = "known_agent"          # 可进入观测与策略分支
    elif looks_automated(req):
        tier = "likely_automated"     # 只做限流，不做授权
    else:
        tier = "unclassified"

    # 授权判断不放在这里：需要账号侧的委派记录
    return tier, account_events.get(req.account_id)

关键点是最后一行注释：流量层的分类结果不应直接充当授权结论。授权需要另一条链路，也就是材料里说尚在推进的“把用户上下文带过 agent”这件事。

边界：哪些还没有答案#

• 委派协议本身未公开。第二篇只说下一步会以隐私友好的方式做三件事：让用户上下文穿过 agent、帮助站点评估声誉、在出问题时确立清晰的问责，并称会与 agent 运营方及生态内其他方合作后再分享。因此 token 格式、验证主体、跨 operator 互认等均待核实。
• 本地 agent 不在讨论范围。第一篇明确把本地 agent（如 OpenClaw）和在用户自己设备、自己浏览器里运行的 agent 排除在主要议题之外，相关结论不能直接套用。
• 不要把“已识别”等同于“已授权”。识别解决的是“这是谁”，授权解决的是“它可以做什么”，两者在材料中是分开推进的。

如果现在就要动手，最小可行的做法是：先把 agent 流量从“未知自动化”里拆出来单独统计，再把 agent 事件写进账号维度的日志，最后才针对 agent 配置差异化策略。等委派机制成熟之前，这套数据结构至少能保证异常发生时定位得到具体账号，而不是只能一刀切地封掉一个 operator。