🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
让 Agent 代表用户访问第三方服务
读完本指南，你将知道：
- 怎么让 Agent 用得上用户的第三方服务（邮箱、日历、IM、云盘），却永远拿不到用户的凭证
- "凭证托管，令牌派发"在流程上具体是哪几步
- 用户断开连接后会发生什么
前置条件
- 已理解 Token Dispatcher（令牌派发） 的机制
- 已能签发委托令牌（见 快速开始）
- 明确 Agent 需要访问哪些第三方服务、需要哪些最小 scope
四个阶段
阶段 1 · 连接：用户把账号接进来
用户在你的应用里点"连接我的邮箱"，走该第三方的标准授权流程（OAuth 2.1 授权码 + PKCE）。授权范围由你声明——这是第一道闸门：你在这里申请了读写全部邮件，后面就永远收不回来了。
授权完成后，第三方返回的凭证进入托管层。你的应用不接收凭证原文，只拿到一个连接记录：哪个用户、哪个服务、连接状态、已授权范围。
阶段 2 · 授权：用户允许 Agent 用这个连接
连接建立不等于 Agent 能用。Agent 要用，还需要用户的一次委托——委托里声明"允许这个 Agent 使用我已连接的邮箱，做只读"。
两层分开的好处：用户可以先连账号自己用，再决定要不要让某个 Agent 也用；撤销 Agent 的委托，不影响连接本身。
阶段 3 · 派发：Agent 每次用都来申请
Agent 需要访问时，携委托令牌向托管层申请访问令牌，声明所需 scope。托管层执行派发检查：
| 检查项 | 不通过的后果 |
|---|---|
| 委托令牌有效且未过期 | 拒绝派发 |
| 委托人本人就是这个连接的所有者 | 拒绝派发（防止拿 A 的委托取 B 的账号） |
| 请求 scope ⊆ 委托范围 ∩ 连接已授权范围 | 拒绝派发或只派发交集部分 |
通过后派发一枚短时、缩权的访问令牌，并记入审计链。Agent 拿它调第三方服务。
阶段 4 · 失效：到期或收回
访问令牌到期即失效，Agent 需要再用就重新申请——这意味着每一次使用都经过一次检查，而不是一次授权后长期畅通。
三种收回路径：
- 用户撤销对 Agent 的委托 → 后续申请被拒，连接本身保留
- 用户断开账号连接 → 该连接的所有派发立即停止，托管的凭证按策略清理
- 管理员熔断 Agent → 该 Agent 的所有派发停止（见 吊销与应急处置）
设计建议
scope 在两个地方都要收窄。 连接时向第三方申请的范围决定了天花板，委托时授予 Agent 的范围决定了实际值。天花板给宽了，即使委托给得窄，用户的账号也已经过度暴露给了托管层——从连接那一步就按最小申请。
为不同用途建不同连接。 同一个用户的同一个服务，若"个人助理只读"和"营销工具读写"两类用途混用一个连接，就只能按更宽的那个申请。分开连接，各自最小。
别把令牌写进日志或提示词。 派发出来的访问令牌虽然短时，但它就是凭证。日志里记 audit_id 和连接 ID，不记令牌本体。
常见问题
Agent 能看到用户的密码或刷新令牌吗？ 不能。Agent 拿到的永远只是派发出来的短时访问令牌。原始凭证在托管层内，不向 Agent 也不向你的应用返回。
用户改了第三方账号密码会怎样？ 托管的凭证可能失效。此时派发会失败，需要引导用户重新连接。
多个 Agent 能共用一个连接吗？ 能。连接属于用户，委托属于"用户 × Agent"这一对。每个 Agent 各自申请、各自受限、各自入审计链。
下一步
- Token Dispatcher（令牌派发） —— 机制与三档使用形态。
- Agent 访问第三方 SaaS —— 场景视角。
- 审计与追责链 —— 派发事件如何入链。