🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
Token Dispatcher（令牌派发）
凭证托管，令牌派发——用户的第三方凭证由 Dispatcher 托管，原始凭证永不出库；Agent 只能凭委托令牌，申请一枚短时、缩权、可回收的访问令牌。
为什么 Agent 需要它
Agent 干活时经常要碰你控制不了的系统：用户的邮箱、日历、IM、云盘、CRM。这些系统的访问凭证（OAuth 刷新令牌、API key）有三个共同麻烦：
- 长期有效。刷新令牌一发数月不过期，交给 Agent 就等于长期让渡。
- 粒度粗。第三方给的 scope 往往按产品切，不按任务切——你想要"只读今天的日历"，它给你"读写全部日历"。
- 拿到就拿到了。一旦凭证进了 Agent 的内存、日志或提示词上下文，你就再也不知道它去了哪里。
Token Dispatcher 的答案是不给凭证，只给令牌：凭证锁在托管层，Agent 每次要用时来申请一枚有期限的访问令牌，用完即失效。
动态管控，不是静态保管
同类方案常见的思路是"建一个保险库，把凭证存起来"。存储是必要的，但它只解决了一半问题——存得住不等于管得好。
Dispatcher 的重心在派发那一刻：每一次申请都要过一道判断。
| 只做静态存储 | Token Dispatcher | |
|---|---|---|
| 关注点 | 凭证怎么加密存下来 | 每次取用要满足什么条件 |
| 取用时 | 拿到凭证本体 | 拿到一枚短时、缩权的访问令牌 |
| 判断依据 | 有没有权限访问保险库 | 委托令牌是否有效、委托人是否就是账号所有者、scope 是否在授权范围内 |
| 出事之后 | 凭证已外流，只能全量轮换 | 令牌到期即废；可停止后续派发 |
派发时的检查至少包含：委托令牌有效且未过期、委托人本人就是这个第三方账号的所有者（Agent 不能拿 A 的委托去取 B 的账号令牌）、请求的 scope 在委托范围与账号已授权范围的交集内。任何一条不满足，不派发并记审计。
三档使用形态
不同 Agent 的自主程度不同，需要的凭证形态也不同：
| 形态 | Agent 代表谁 | 凭证来源 | 典型场景 |
|---|---|---|---|
| 纯服务型 | 不代表个人，代表组织 | 组织级的工具凭证（如某个协作平台的应用令牌） | 定时抓取、批处理、系统集成 |
| 单用户委托 | 代表一个具体的人 | 该用户已连接的第三方账号 | 个人助理读你的邮箱、整理你的日历 |
| 多跳链 | 代表人，且中间经过多个 Agent | 上一跳的委托沿链传递，每跳只能更窄 | 编排型 Agent 调用子 Agent 完成复合任务 |
三档共享同一条纪律：权限在每一跳只能收窄（缩权）。多跳链尤其如此——链越长，末端拿到的切片越小。
工作原理
- 用户 把第三方账号连接到你的应用（走该第三方的标准授权流程），授权范围由你声明。
- Dispatcher 接收并托管返回的凭证；凭证加密存放，不向 Agent、也不向你的应用返回原文。此后凭证的刷新由 Dispatcher 负责。
- Agent 需要访问该第三方服务时，携委托令牌向 Dispatcher 申请访问令牌，声明所需 scope。
- Dispatcher 执行上文的派发检查，通过后派发一枚短时、缩权的访问令牌，并记入审计链。
- Agent 用这枚令牌调用第三方服务。令牌到期即失效，需要再用则重新申请。
- 用户或管理员 可随时断开账号连接，后续申请一律拒绝。
全程 Agent 接触到的只有第 4 步派发出来的短时令牌——原始凭证从未出库。
标准与协议
- RFC 8693 Token Exchange：派发的语义基础——用一种令牌换另一种受限令牌。
- OAuth 2.1 授权码 + PKCE：第一步"用户连接第三方账号"走各第三方的标准授权流程。
- 凭证的加密存放与刷新属实现细节，不构成对外契约。
下一步
- Agent 访问第三方 SaaS —— 场景视角。
- 让 Agent 代表用户访问第三方服务 —— 指南视角。
- Delegate Token 与缩权 —— 派发检查里的交集规则从哪来。