agent 代用户访问时，用户身份该保留在哪一层：中间层剥离与委托边界

简短回答：不要指望在传输层“顺带”保住用户身份。用户身份应当放在委托层——用一个可验证的断言把“哪个用户、经由哪个代理、被允许做什么”带进请求；网络层、请求头与会话只能作为证据，不能作为身份本身。这是本文依据材料做的分层归纳，不是来源原文的结论。Cloudflare 的文章Agents aren't humans (but they kinda are)（来源日期 2026-11-05）在本次可读范围内说明了问题空间与“协作式方法”的方向，具体协议字段、令牌格式与验证流程待核实。

中间层为什么会把用户身份“吸收”掉#

材料给的定义很朴素：中间层是任何位于用户与站点之间、让站点看到它而不是用户的东西。云浏览器、代理与 VPN 早已属于此类，远程托管的 agent 是最新的一种。变化不在“存在中间层”，而在于规模和速度——材料称 agentic 流量增长很快，并可能在不久的将来超过传统的人类浏览。

文章用了一个助理的比喻（转述，非实测案例）：助理 Ezra 同时替四位客户跑腿，杂货店老板过去认识其中一位客户、知道她的偏好，现在只见到 Ezra，分不清四份订单各是谁的；出现拒付时，店家唯一见过的人是 Ezra；有人在银行用一长串密码逐个试探，银行能封的也只有 Ezra，而封掉 Ezra 等于同时封掉另外三位客户。把 Ezra 换成 agent、把店铺换成网站，就是材料描述的现状。

值得记住的是 agent 的物理特性：它不疲劳、可 24 小时运行、可并行、能忍受人类不会忍受的摩擦。而站点的容量规划与变现模型，长期是建立在“人类有极限”这个前提上的。

逐层看：每一层能证明什么#

下表是本文的分析框架，用于说明分层取舍；它不是来源原文的分类表。表中的“不能回答”是设计边界，不是对任何具体产品的评价。

材料特别指出两个反直觉点。其一，agent 常常跑在住宅 IP 上、使用真实浏览器，并有意不把自己与人类流量区分开，因此网络层信号既不可靠、也容易被冒用——攻击者复制知名 agent 的 User-Agent 就能拿到同样的待遇。其二，把“控制浏览器的是人类”这一信号透传给背后的用户，不增加任何新信息，只会让 agent 更低效。

站点真正要回答的三个问题#

材料把安全与反欺诈领域的传统需求归纳为三件事：身份（行为人对自己是谁是否诚实）、声誉（此人是否可信）、可问责性（谁为这次行为负责）。agent 的出现让这三个问题同时失去着力点：站点看不到用户，只能选择在没有用户信息的前提下信任中间层，或者拒绝中间层。

而拒绝这条路会逐渐走不通。材料指出，历史上站点可以简单封禁中间层流量、要求用户关掉中间层服务；当 agent 流量成为多数时，这个做法就失效了。这就是文章提出的“中介原则”的背景：无论是否经过中间层，用户与站点之间的业务关系、以及各参与方的安全责任，都必须得到维持。注意这是来源明确表述的原则，本文只做引用。

身份被剥离后，具体坏在哪里#

材料列出了一份站点侧的挑战清单。下面摘录其中与本主题直接相关的几项，保留原意、压缩表述：

材料还提到合规（年龄、地域限制）、身份冒用、策略绕过、基于风险的身份验证失效、未授权持卡人等问题；片段在“用户归因”处被截断，后续条目本次材料未提供。上面每一行都指向同一个结构性事实：站点失去的不是某个字段，而是把行为归属到某个责任主体的能力。

Cloudflare 的委托模型指向什么，以及材料没说什么#

按摘要，这篇文章的定位是“定义问题空间，并引入一种协作式方法，用于安全地识别、放行与管理这类自动化流量”。因此它属于问题定义与方向性提案，而不是一份可直接实现的接口规范。本次可读内容中未出现：断言的具体字段与编码、由谁签发与验证、密钥与吊销机制、与现有 OAuth 类授权体系的关系、浏览器或运营者侧的接入方式。这些都需要回到原文全文或后续文档核实，本文不作推断性补全。

可以直接引用的是方向本身：让 agent 与背后的运营者可被识别、可被追责，同时保留用户与站点之间原有的业务关系。换言之，身份信息的落点不在“更聪明的指纹”，而在一次显式的委托声明。

给服务端设计的边界条件#

以下是从上述问题反推的工程建议，属于本文判断，不是来源结论：

1. 先定责任主体，再定字段。在讨论加什么头之前，先明确“用户授权的购买由谁承担争议成本”。字段是责任划分的结果，不是起点。
2. 区分“自述”与“断言”。User-Agent 与自定义头属于自述，可被复制；只有经过验证方校验的委托信息才能进入授权判断。两者要分开存放、分开使用。
3. 不要用人类验证充当身份。材料明确指出 agent 从不被期望是人类，把人机校验结果透传没有新增信息。
4. 限流与封禁的粒度要能落到用户。如果封禁单位只能是 agent，就会产生材料所述的连带封禁；这要求在上游就能区分“同一 agent 下的不同用户”。
5. 保留可审计记录。材料提到站点需要为反欺诈保留结账行为记录；委托链路上同理，需要记录“哪一次请求由哪一条委托覆盖”，否则事后无法举证。

什么时候这套讨论不适用#

材料的范围限定值得照抄：主题针对托管在用户设备之外的 agent；本地 agent（例如跑在用户自己设备或浏览器里的）不在其讨论范围。本地场景下用户与设备的一致性本来就存在，中间层剥离问题弱得多。另一个边界是：若请求背后根本没有在场的用户（无人值守的定时任务），委托层能提供的是运营者身份与用途声明，而不是用户身份，这两者不应混为一谈。

待核实清单#

• Cloudflare 提案的具体断言格式、签发与验证主体、吊销方式：本次材料未提供。
• 材料提到的 agent 产品实例（Muse、dots）的当前可用性与覆盖范围：文章发布时点为 2026 年 11 月，现状待核实。
• “agentic 流量可能超过人类浏览”是材料的趋势判断，不是已发布的统计数字；如需引用比例，应回到原始数据并保留统计口径与时间窗。
• 各挑战条目在实际站点上的影响量级，材料未给出量化数据，本文不填。