端到端业务时序
这一页是全站时序的权威源：SaaS 形态 7 跳、私有化同域旁挂形态 8 跳，两张完整泳道图。其他页面出现的时序片段都是这两张图的局部裁剪。两形态的差异只有一跳：⑧ 身份联邦。
读图先分清两套编号
图中 autonumber 生成的 1–N 是消息序号（每条箭头一个号）；①–⑧ 是环节跳号——全站文档引用"跳几"时指的都是后者。一个环节跳号通常覆盖多条消息。
SaaS 形态：7 跳
App 接入 api.eak.eazo.ai，从注册到吊销的完整闭环：
私有化同域旁挂形态：8 跳
GenAuth 部署在你的环境里，人的身份权威在你既有的 Human IAM——所以授权确认之前多出一跳：⑧ 身份联邦（插在②与③之间），用户先以企业账号完成 OIDC 联邦登录，GenAuth 由此确认"张三就是你目录里的张三"。
每跳承接的文档
时序图给全貌，细节各有专页。按私有化叙事顺序（① ② ⑧ ③ ④ ⑤ ⑥ ⑦）逐跳对照——SaaS 形态跳过⑧即可：
| 跳 | 环节（责任方） | 对应 API / 机制 | 相关文档页 | 备注 |
|---|---|---|---|---|
| ① | 注册与审批（App 管理员 × GenAuth） | 控制平面：Agent 注册、审批、责任人绑定 | 注册和管理你的 Agent · Agent 的身份模型 | Roadmap |
| ② | 发起委托 + 授权确认（User × App × GenAuth） | POST /api/v3/eak/delegations（interactive）→ GET /api/v3/eak/delegations/:grantId/approval-context → POST /api/v3/eak/delegations/:grantId/approve | Consent 与审批 | |
| ⑧ | 身份联邦，仅私有化（GenAuth × Human IAM） | OIDC 联邦登录 + 用户映射 | 整合原理 | Roadmap |
| ③ | 缩权校验：三方交集（GenAuth × Human IAM） | 用户真实权限评估 | Delegate Token 与缩权 | Roadmap |
| ④ | 签发委托令牌（GenAuth） | POST /api/v3/eak/delegations/callback/consume → 委托令牌 | Delegate Token 与缩权 · Token 与 Claim 参考 | |
| ⑤ | 令牌兑换（Agent × GenAuth） | POST /api/v3/eak/token-exchange（RFC 8693） | Delegate Token 与缩权 · 让 Agent 代表用户调用你的 API | |
| ⑥ | 资源侧校验（App：资源服务/网关） | sub / act / scope 交集校验 | 保护你的 API：资源侧集成 | Roadmap |
| ⑦ | 审计与吊销（GenAuth × User/管理员） | audit_id 全链贯穿；POST /api/v3/eak/delegations/introspect；分层吊销 | 审计与追责链 · 吊销与应急处置 |
标注 Roadmap 的跳怎么读
标注 Roadmap 的环节，概念与设计已定型（两张图即按此目标态绘制），接口与操作步骤以正式发布为准。对应文档页会在首屏给出同样的徽章说明。
两形态的差异，就是⑧
只有这一处不同：
- SaaS 形态：用户身份由 GenAuth 托管侧确认，授权确认页直达，全程 7 跳；
- 私有化形态：人的身份权威在你的 Human IAM，所以 Consent 之前先走⑧——OIDC 联邦登录 + 用户映射，把"确认授权的这个人"锚定到你目录里的真实员工，全程 8 跳。
其余七跳，两形态逐条一致：同一套概念、同一套 API、同一套审计链。这也是"两形态代码零差异"的底气所在（见 部署形态）。
下一步
- 同一趟旅程的叙事版：8 个瞬间讲完一次委托 → 一次委托的完整旅程
- 亲手把②④⑤跑一遍 → 第一次委托：30 分钟跑通
- 静态视角：五方关系与信任边界 → 系统全景与信任边界