🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
Agent 访问第三方 SaaS
方远是一家两百人公司的销售 VP，每天三百封邮件、一屏日历。团队给他配了个助理 Agent：早上把邮件整理成摘要，会议冲突自动改约，重要客户来信即时在 IM 上提醒。听起来很美——前提是 Agent 能访问他的邮箱、日历和 IM。这三样，恰好是方远数字生活里最私密的三样。
IT 部门给出的老办法各有各的糟糕。把密码告诉 Agent？等于交出整个数字身份，改密码那天所有集成一起断。走一次第三方授权，然后把长期凭证塞进 Agent 的环境变量？凭证从此长住在 Agent 侧——Agent 被攻破，邮箱、日历、IM 一锅端；更麻烦的是三个月后没人记得清授权过什么、给了谁、还活着几份。IT 的死结就在这里：不给就没法用，给了就收不回。
流程
解法一句话：凭证托管，令牌派发。方远的第三方凭证由令牌派发（Token Dispatcher）托管，永不出库；助理 Agent 每次干活，只能凭委托令牌（Delegate Token）申请一张短时、缩权、可回收的访问令牌。Agent 从头到尾接触不到原始凭证——它拿到的每一张令牌都有期限、有范围、有账可查。机制详解见 Token Dispatcher（令牌派发）。图中 ①–⑦ 是全流程跳号，与一次委托的完整旅程一致，本页截取 ②–⑤：
三个关键时刻
- 授权确认（Consent）——分两层，缺一不可。连接时刻（一次性）：方远把自己的邮箱、日历账号连接进托管——走的是第三方服务自己的标准授权流程，凭证落进托管侧，Agent 全程不在场。委托时刻（每次任务/会话）：授权确认页写明助理 Agent 这次申请的范围——比如只读邮件、读写日历、不含代发邮件。这个范围可以比连接时授予托管的范围更窄，且只能更窄，不能更宽（缩权，attenuation）。
- 审计记录：每一次令牌派发都带 audit_id 落进审计链：谁授权——方远；以谁身份——方远，由助理 Agent 代表行动（on-behalf-of）；做了什么——为哪个第三方服务派发了什么范围的令牌、随后访问了什么。对 IT 来说，这是第一次能回答"公司里有哪些 Agent 正在以谁的名义访问哪些第三方服务"——答案不在某人的记忆里，在审计链里。
- 吊销：方远换了岗位、Agent 行为异常、或者干脆不想用了——断开连接，托管即停止派发新令牌；可随时吊销授权，已签发令牌的失效时效见吊销与应急处置。改密码不再是唯一的应急手段，而且原始凭证从未离开托管，也就不存在"散落在各处的副本"要追缴。
本场景用到的能力
| 能力 | 在本场景中的作用 | 深入阅读 |
|---|---|---|
| Token Dispatcher（令牌派发） | 凭证托管，令牌派发——本场景的核心 | Token Dispatcher（令牌派发） |
| 委托令牌与缩权（attenuation） | 每张派发出去的令牌都短时、限范围 | Delegate Token 与缩权 |
| 授权确认（Consent） | 连接与委托两层，都由方远说了算 | Consent 与审批 |
| 审计链 | 每次派发与访问都可追溯 | 审计与追责链 |
下一步
- 概念：Token Dispatcher（令牌派发）——托管与派发的机制详解
- 指南：让 Agent 代表用户访问第三方服务——连接→授权→租借的完整路径
- 场景：员工数据助手——访问的是内部资源时，同一套委托逻辑