一次委托的完整旅程
张三是销售运营，每周一要出客户周报。数据在 CRM 里，导出、清洗、做表两小时。团队上了一个报表 Agent——但张三的 CRM 账号能看整个大区的客户明细，他不敢把账号交出去。
下面是他真正做的事：8 个瞬间，完整走完一次委托的一生。
瞬间 1 · 在册
报表 Agent 三个月前就注册进了台账：谁开发的、给哪个业务线用、技术负责人是谁、业务归属人是谁——都在册。张三今天用的不是一个来历不明的脚本，而是一个有身份、有责任人的 Agent。
瞬间 2 · 交办
张三在内部工具里说："出上周的客户周报。" 应用不直接去调 CRM——它先替 Agent 向 GenAuth 提出一次委托请求：我需要代表张三，读客户报表，两小时。
瞬间 3 · 确认
张三看到一个授权确认页：报表 Agent 请求 只读客户报表，有效期 2 小时。他点了同意。
这一步是整套机制的分水岭。在此之前 Agent 什么权限都没有；在此之后它拿到的也不是张三的账号，而是张三本人权限的一个切片。
瞬间 4 · 缩权
同意之后，GenAuth 还要算一道交集：张三本人有权限看客户报表吗？企业批准过这个 Agent 拿这类权限吗？请求的范围在两者之内吗？三个集合取最小——这就是缩权（三方交集详解）。
一个后果值得记住：张三授权不出他自己都没有的权限。 委托是让渡，不是提权。
瞬间 5 · 持令
Agent 拿到一枚委托令牌（Delegate Token）：写着谁授权（sub = 张三）、授权给谁（agent_id = 报表 Agent）、什么范围（只读报表）、多长时间（2 小时）、审计编号（audit_id）。
不是密码，不是长期 key，是一份带期限的授权切片。
瞬间 6 · 兑换与访问
委托令牌不直接调资源。Agent 用它兑换出目标资源的访问令牌——令牌里 sub 仍是张三、act 标明是报表 Agent 在行动。你的 API 网关校验三件事：签名对不对、受众对不对、scope 在不在授权范围内。只读请求放行；同一枚令牌若尝试写入，直接拒绝。
令牌把"代表谁"和"谁在执行"分成两个字段，这是审计能追责到人的前提。
瞬间 7 · 留痕
从张三点同意那一刻起，audit_id 串起了后面每一步：授权、兑换、每次访问、以及后面的吊销。事后任何人问"这份客户数据是谁批准 Agent 取的"，答案是一条完整链路，不是一句"系统账号取的"。
瞬间 8 · 收权
两小时后令牌自然失效，Agent 什么也做不了了——不需要任何人记得去关它。
如果中途出事（Agent 行为异常、张三发现授权错了、安全团队要求立即断），可以主动收权：停用这个 Agent 专用的访问密钥（这也是为什么建议每个 Agent 一把密钥——停一把不牵连别人），必要时在资源侧按 Agent 拒绝请求。各层手段与各自的生效时效见 吊销与应急处置——那一页把"多快能停下来"讲得很直白，包括做不到的部分。
整件事张三只做了一个动作：点了一次同意。其余七个瞬间由这套机制自动完成——而这一个动作，让"Agent 代人干活"从一次凭证外泄风险，变成一次有边界、有时限、有记录、可撤回的授权。
下一步
- 第一次委托：30 分钟跑通 —— 亲手把这条路走一遍。
- Delegate Token 与缩权 —— 瞬间 4 和 5 的原理。
- 员工数据助手 —— 同一个场景的业务视角。