中间层抹掉用户身份之后：Agent 委托凭证该带哪些字段
远程托管的 Agent 是位于用户与站点之间的中介，站点看到的是 Agent 而非用户，因而失去识别、服务与追责用户的能力。按材料提出的身份、声誉、可问责三问，委托凭证至少要能重建用户、Agent、Operator 三方关系，并携带主体假名、代理方标识、授权范围、时效与受众、可验证性与追责路径；多跳中介下还需保留原始主体。本文给出的字段分组属工程推导，材料未提供字段级规范。
- 中间层问题的实质是站点无法再回答三个问题：行为人是否如实表明身份、是否可信、谁为行为负责。
- 委托凭证的字段应按这三问反推，缺一组就有一类判断失效，例如账号共享、友好欺诈争议、封禁粒度。
- 把“通过人机验证”或 Agent 的 IP、设备指纹当作使用者证据，是材料明确指出的失效点，不应写进凭证语义。
Agent 代表用户访问服务时，站点看到的往往不是用户，而是托管 Agent 的中间层。材料把这一问题的核心概括为：站点失去了识别、服务并追责其背后用户的能力，而成本由站点承担（Cloudflare Blog，2026-11-05）。因此，委托凭证要解决的主要问题不是“证明这是个人”，而是让站点在看不到用户的情况下仍能回答三件事：行为人对身份是否如实、是否可信、谁为行为负责。
先说明材料限制：本次可用内容是该文的摘要与一段被截断的正文，没有给出字段级规范，结论也可能位于未提供部分。下文“建议携带”的字段是按该文提出的三问推导的工程结构，不是来源规定；是否已有成熟标准，待核实。
中间层抹掉的是什么#
材料把远程托管的 Agent 归为中介（intermediary）：它坐在用户与站点之间，站点看到它而不是用户。同类中介还包括云浏览器与代理（含 VPN）。区别在于规模与走向：材料称 Agent 流量增长迅速，并可能在不久的将来超过传统的人类浏览。材料同时明确，本地运行的 Agent、以及跑在用户自己浏览器与设备上的 Agent，不在其主要讨论范围内。
关键结构是“一对多”：一个 Agent 可代表多个用户行动。材料用助手 Ezra 作比：她同时服务 Amy、Bob、Charlie、Debra。杂货店曾经认识 Amy，现在只见到 Ezra，分不清订单偏好属于谁；Bob 事后否认授权扣款时，店方唯一见过的经手人是 Ezra；Charlie 让 Ezra 逐个试密码时，银行能看见攻击，却只能封禁 Ezra，而封禁会连带封掉其余三位客户（同文）。把 Ezra 换成 Agent、把店铺换成网站，就是材料描述的网络现状。
材料据此提出一条原则：用户与站点之间的业务关系、以及各参与方的安全责任，不应因为中介的加入而失效。站点需要的新工具，是在用户经由 Agent 访问时仍能像直接访问那样识别、服务并追责；同时 Agent 与其背后的 Operator 也必须可识别、可追责，因为 Agent 能做出人做不到的事——不疲劳、全天候、可并行、能承受人不会忍受的摩擦。
三问对应哪些失效场景#
材料指出，安全与反欺诈传统上依赖三件事：身份（Identity）、声誉（Reputation）、可问责性（Accountability），即行为人是否如实说明自己是谁、这个人是否可信、出了事谁负责。这三问可直接当作字段设计的最小检验：一个字段如果三问都回答不了，就不该占据载荷空间。
| 材料列出的挑战 | 站点原本依赖的信号 | 中间层介入后失去什么 |
|---|---|---|
| 友好欺诈：用户先批准 Agent 购买，再以未授权为由争议 | 同一设备、IP、地址与历史无争议订单等间接证据 | Agent 的购买来自 Agent 的基础设施，这类证据不存在；即使胜诉，争议本身也有成本 |
| 基于风险的身份验证 | 设备、位置、行为与用户历史一致 | Agent 跑在云基础设施上，每次访问都显得异常 |
| 流量混杂 | 把滥用行为归到具体账号再处置 | 某个用户借共享 Agent 撞库、抓取或测卡时，站点只能封 Agent，连带封掉其全部合法用户 |
| 身份验证断裂 | 活体检测、KYC 证件核验假定在场者即被验证者 | Agent 从不是那个人；站点只能接受透传的验证结果（削弱检查）、拒绝 Agent，或放弃检查 |
| 人机验证失效 | CAPTCHA 判断控制浏览器的是不是人 | Agent 本就不是人；把该信号透传给人类用户不增加新信息，只降低 Agent 效率 |
| 账号共享与策略规避 | 按账号或身份实施限流、白名单 | Agent 未必表明自己是 Agent，也常不携带所代表用户的信息 |
| 未补偿消费与资源耗尽 | 按访问、曝光、订阅或试用计费与限额 | Agent 读取内容去别处回答用户，站点付出服务成本却无访问、曝光或购买；持续轮询与昂贵端点亦无人类节奏约束 |
委托凭证建议携带的字段#
以下分组按“缺了它，哪一问就答不了”组织。字段名与编码仅为示意，材料未提供任何格式约定。
| 字段组 | 至少包含 | 回答的问题 | 缺失后的具体后果 |
|---|---|---|---|
| 用户主体 | 面向本站的稳定假名（按站点区分的 pairwise 标识），而非用户在他处的原始账号；可选携带经用户同意的属性声明，如年龄段、地区 | 这次访问背后是谁 | 无法与历史订单、订阅、争议记录关联，账号共享与策略规避无法区分，合规判断缺少输入 |
| 代理方 | Agent 标识与版本、Operator 标识 | 谁在替我行动、谁运营它 | 无法按 Agent 可靠性分摊退款与支持成本，也无法把处置落到正确的运营方 |
| 授权范围 | 允许的动作、资源、金额上限、次数、时间窗 | 这次行为是否在授权内 | 用户事后否认时，站点缺少可核验的授权证据 |
| 时效与受众 | 签发时间、过期时间、受众（本站）、一次性随机数 | 凭证是否被重放或挪用到别处 | 一张凭证可跨站复用，限流与风控失去意义 |
| 可验证性 | 签发方、签名算法、密钥引用、验证方法 | 这些声明由谁背书、站点怎么验 | 声明退化为自述，与直接采信 Agent 的 User-Agent 字符串无异 |
| 可问责与审计 | 责任方、争议受理路径、可关联的审计引用 | 出了事找谁 | 站点能检测到问题却无处追索，只能以封禁 Agent 兜底 |
| 链路完整性 | 多跳中介下的原始主体与各跳中介标识 | 最终站点看到的到底是谁 | 材料指出有时会有多个中介同时位于用户与站点之间；若每跳重写主体，站点仍只看到最后一跳 |
有一条约束值得单列：不要把“通过人机验证”写成身份字段。材料明确说 Agent 从不是人类，透传该信号不增加新信息。同理，Agent 的 IP 与设备指纹不应被当作使用者证据——它们恰好是材料列出的“证据消失点”。
占位示例：委托声明长什么样#
下面的 JSON 只是结构示意，域名与取值均为占位（example.com、YOUR_NONCE），未执行、未对任何端点验证，也不对应任何现行规范。
{
"issuer": "https://operator.example.com",
"subject": "pairwise:user-pseudo-7f3a",
"agent": {
"id": "agent:placeholder-001",
"operator": "https://operator.example.com"
},
"delegation": {
"granted_by": "user",
"scope": ["purchase:create"],
"limits": { "amount": "100.00", "currency": "CNY", "count": 1 },
"window": { "from": "2026-11-10T00:00:00Z", "to": "2026-11-10T01:00:00Z" }
},
"audience": "https://shop.example.com",
"issued_at": "2026-11-10T00:00:00Z",
"expires_at": "2026-11-10T01:00:00Z",
"nonce": "YOUR_NONCE",
"accountability": { "contact": "https://operator.example.com/disputes" }
}解读时注意：subject 是给这一个站点看的假名，换站点应换值；scope 与 limits 是站点判断“是否在授权内”的唯一依据；audience 与 nonce 防止跨站复用与重放。
边界：凭证解决什么、不解决什么#
- 合规不能被凭证替代。材料指出，若允许 Agent 访问，Agent 并不提供足以满足站点合规门槛的保证。凭证传递的是声明，站点仍需自行做年龄、地区等判断。
- 封禁粒度是主要收益之一。凭证让处置可落在用户维度；否则会重复材料中“封禁 Ezra 等于封禁全部客户”的结果。
- 声誉部分待核实。材料把声誉列为三要素之一，但未说明如何计算、由谁共享。
- 隐私取舍未在材料中展开。按站点区分假名、最小化披露属性属工程建议，其代价与可撤销性需另行评估。
待核实#
由于正文被截断，以下问题本次材料未回答，不宜据此下结论：委托凭证是否已有标准化字段与协议绑定；Operator 如何被认证与持续验证；用户如何撤销一次委托；站点如何在不引入跨站追踪的前提下验证主体。文中所有“建议携带”均为工程推导，不是来源规范。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
