🧪 Beta — 能力已可用，接口契约可能微调。本页为混排页：〔多跳委托〕小节属路线图能力，已在节内单独标注。
三种访问模式（Access Patterns）
访问模式回答授权系统绕不开的两个问题：这次行动，账算在谁头上（token 的 subject 是谁），规则查谁的（策略打在谁身上）。GenAuth 把 Agent 的行动方式归为三种：代表用户的委托模式、以自己身份行动的自主模式、Agent 调用 Agent 的多跳委托。
为什么 Agent 需要它
一把钥匙走天下，是 Agent 授权最常见的错误起点。把 Agent 的所有行为都记成"某个用户在操作"，审计失真——出了事分不清是人还是 Agent；把所有行为都当成"服务在跑批"，权限失控——用户数据被一个不代表任何用户的身份碰了，事后既指不出授权人，也划不出边界。
三种模式不是三套系统，而是同一套身份与令牌体系下的三种主体安排。选对模式，subject 与策略落点自然就对了；选错模式，后面的授权、审计、吊销全部跟着错位。
一张表看三种模式
| 模式 | token 的 subject | 行动者如何标识 | 策略打在谁身上 | 有委托人吗 | 状态 |
|---|---|---|---|---|---|
| 委托模式（on-behalf-of） | 用户（sub = 用户） | 兑换后的访问令牌以 act 标出 Agent | 这次委托：用户同意的范围与期限，叠加 Agent 身份与模板边界 | 有 | 🧪 Beta |
| 自主模式（autonomous） | Agent 自身（sub = Agent） | 主体即行动者，无 act | Agent 身份及其模板上的策略 | 无——但有责任人 | 🧪 Beta |
| 多跳委托（multi-hop delegation） | 最初的用户 | act 链记录每一跳 | 每一跳独立评估，范围只收窄 | 有，且跨多跳保留 | 🚧 Roadmap |
委托模式：代表用户行动
🧪 Beta — 本小节能力已可用，接口契约可能微调。
用户把任务交给 Agent，同时把完成任务所需的一小片权限显式让渡给它——这是 GenAuth 的主线模式，对应主骨架泳道图的跳②–⑥（全图见 一次委托的完整旅程）。
token 的 subject 是谁：始终是用户。委托令牌（Delegate Token）的 sub 是用户；兑换后的访问令牌 sub 仍是用户，同时以 act 标出实际行动者是哪个 Agent。审计因此能同时回答"以谁身份"和"谁在动手"——这正是借用户账号做不到的。
策略打在谁身上：打在"这次委托"上。用户在授权确认（Consent）页同意的 scope 与期限写入令牌；同时受 Agent 身份与模板边界约束；再往上还有用户本人的真实权限这道天花板。三者如何取交集、各自何时校验，见 Delegate Token 与缩权。
典型场景：员工数据助手。销售运营张三让报表 Agent 出上周客户周报，Agent 拿到的是"只读、仅报表接口、两小时"的授权切片，而不是张三的账号。完整故事见 员工数据助手。
流程骨架（责任方标注）：用户交办并确认授权（User，跳②）→ GenAuth 签发委托令牌（GenAuth，跳④）→ Agent 兑换出目标资源的访问令牌（Agent × GenAuth，跳⑤）→ 资源侧校验 sub / act / scope 后放行（App，跳⑥）。
自主模式：以自己的身份行动
🧪 Beta — 本小节能力已可用，接口契约可能微调。
有些 Agent 不代表任何用户：定时对账、批处理、内部服务巡检。它们以自己的一等身份行动。
token 的 subject 是谁：Agent 自己。令牌的 sub 就是 Agent 身份，没有 act——因为主体与行动者是同一个。
策略打在谁身上：打在 Agent 身份及其模板上。它能访问什么，完全由注册审批时企业为它划定的边界决定（见 Agent 的身份模型），不存在"用户同意"环节。
**没有委托人，不等于没有责任人。**自主模式的 Agent 一样要登记技术负责人（Owner）与业务归属人（Sponsor），一样进台账、走审批、可熔断。典型场景见 无人值守的定时任务 Agent。
自主模式不是委托模式的捷径
凡是要动某个用户数据的行动，都应走委托模式，把用户的同意留在链条上。用自主模式的宽身份去碰用户数据，等于把"谁授权的"这一栏永久留空——审计与合规都过不去。
多跳委托：Agent 调用 Agent
🚧 Roadmap — 本小节描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
复杂任务里，一个主管 Agent 会把子任务拆给专家 Agent：行程 Agent 调用订票 Agent，订票 Agent 再调用支付查询 Agent。委托关系跨越多跳传递，两条纪律必须守住：
- subject 不漂移：无论链条多长，令牌的
sub始终是最初发起委托的用户；每一跳的行动者依次记入act链，完整委托链可回放。 - 范围只收窄：每一跳拿到的权限只能是上一跳的子集，只减不增（缩权，attenuation）；每个 Agent 独立认证，禁止把上一跳的令牌原样透传。
策略打在谁身上：打在每一跳上——每次传递都是一次独立的策略评估点，任何一跳的 Agent 被禁用或超出边界，链条就在那一跳断开。
怎么选
三个判断题，按顺序问：
- 这次行动会动某个用户的数据或权限吗？会——委托模式。
- 没有任何用户在场，只动 Agent 自己被批准的资源？是——自主模式。
- 链条上出现了第二个 Agent？是——多跳委托，且链上每一跳仍要回答前两问。
标准与协议
- RFC 8693（OAuth 2.0 Token Exchange）——委托与多跳场景中"行动者"（
act）语义的协议来源；GenAuth 实现其兑换流程，act结构做了扩展（见 Token 与 Claim 参考）。 - RFC 6749（OAuth 2.0）——自主模式的协议原型是客户端凭证授权（client credentials）：应用以自身身份获取令牌；GenAuth 在其上叠加 Agent 一等身份与治理。
- IETF AAT 草案（Attenuating Agent Tokens）——多跳"每跳只收窄"的标准化方向；GenAuth 的多跳设计与该方向对齐。
下一步
- 场景：员工数据助手 —— 委托模式的完整故事
- 上手：让 Agent 代表用户调用你的 API —— 委托模式落到代码
- 参考：Token 与 Claim 参考 ——
sub与act的字段契约