在生产系统上工作的 agent 需要获得行动许可。像“修复这个部署”这样的请求不会预先告诉你它将采取哪些操作或需要什么访问权限。给 agent 广泛的访问权限，一旦出错就可能影响无关资源。每一步都请求批准，用户就必须在还不知道 agent 打算如何解决问题之前逐个批准操作。反复的提示会让这种审查变成一种点击批准的习惯。
Vercel Agent 先调查问题，然后提出一个计划，说明它将做什么以及需要什么访问权限。批准该计划即授予执行该计划所需的额外权限，因此用户可以在授权任何更改之前审查提议的修复方案。
计划决定权限
对于损坏的生产部署，Vercel Agent 可能会检查最近的部署和构建日志，然后将失败的部署与最后一个已知正常的部署进行比较。只读访问让这项调查可以自动运行。如果调查导致提议重新部署，Vercel Agent 会在一个计划中请求额外访问权限，用户可以审查该计划并通过一次决定予以批准。
访问权限由 scope 定义，即 Vercel 授权系统所识别的命名能力。任何请求超出只读基线的访问权限的计划都会整体等待批准，包括其中包含的任何只读任务。在此示例中，调查在单独的只读计划下运行，之后 Vercel Agent 才提议重新部署：
| 计划 | 工作 | 请求的 scope |
|---|---|---|
| 调查失败原因 | 检查最近的部署和构建日志，然后将失败的部署与最后一次成功的部署进行比较 | read:deployment |
| 重新部署最后一个已知正常的构建 | 创建部署 | read-write:deployment |
示例计划及其涵盖的工作和请求的 scope。
简短的只读查询无需计划即可运行。对于较长的调查，Vercel Agent 会创建一个只读计划，以便用户在其自动运行时跟踪其任务和进度。
计划将用户想要完成的事情与 Vercel Agent 被允许做的事情连接起来：
- 意图：用户要求的结果。
- 工作：Vercel Agent 为实现该结果而提议的任务。
- 访问权限：这些任务所需的 scope。
- 强制执行：强制执行访问限制的凭据和 API 检查。
部署请求如何变成带有权限的计划。
每个存储的计划都会记录其任务和进度，请求的 scope 附加到每个任务上。任务描述解释了为什么需要访问权限，并且 scope 在整个计划中合并。
调查失败的部署并获得重新部署的批准。
只读基线目前包括所有以 read: 开头的已注册 scope。当计划请求超出该基线的访问权限或包含受支持的外部操作（例如打开 GitHub pull request）时，就需要批准。只读操作仍可能暴露敏感信息，因此自动批准并不意味着该工作无害。
Vercel Agent 只能使用用户已拥有的权限
Vercel Agent 作为 Vercel App 运行，用户授权其在团队内代表自己行事。该授权受用户现有权限的限制，因此批准计划不能授予用户没有的访问权限。
Vercel OAuth 服务将该授权换取为具有特定 scope 的较短生命周期令牌。这些 scope 定义了令牌允许哪些能力，例如读取部署或更改项目设置。Vercel API 在每次请求时检查令牌以强制执行这些限制。
Vercel Agent 如何为已批准的工作获取令牌。
用户可能为拥有数十个项目的团队授权 Vercel Agent。重新部署计划请求部署写入权限。编辑环境变量、更改域名和管理团队成员资格各自需要自己的权限。
部署写入权限比单次重新部署更广泛。在计划中指定部署 X 本身并不会将令牌限制为该部署。运行时（协调 Vercel Agent 执行的软件）在选择其已批准的凭据之前会检查计划是否处于活动状态。Vercel API 会根据该凭据的权限检查每个请求。
批准决定 Vercel Agent 可以使用哪些权限
当用户批准需要额外 Vercel 访问权限的计划时，会再次检查其请求的 scope，并准备一个包含只读基线加上已批准权限的令牌。运行时（协调 Vercel Agent 执行的软件）在选择其已批准的凭据之前会检查计划是否处于活动状态。该凭据仍受其 scope、团队、用户权限和有效期的约束。
使用的凭据取决于工作：
| 工作 | 凭据 |
|---|---|
| 只读调查 | 具有只读 scope 的基线令牌 |
| 已批准的 Vercel 更改 | 具有基线 scope 加上已批准额外 scope 的令牌 |
| 外部操作 | 特定于该提供方的凭据和权限 |
Vercel Agent 对每种工作使用哪种凭据。
模型的指令告诉它何时提出计划并请求批准。如果它尝试执行超出令牌权限的操作，Vercel API 会拒绝该请求，即使模型认为该操作是完成任务所必需的。
单个计划可以包含 Vercel 更改和 GitHub pull request。用户在一个计划中审查两者，而每个提供方使用单独的权限和凭据。GitHub pull request 访问权限与所有者和仓库绑定，因此在 acme/storefront 中打开 pull request 的批准适用于该仓库，即使用户也有权访问 acme/payments。在那里打开 pull request 需要其自己的批准。
计划与令牌使用相同的权限定义
提议的计划可能请求已被重命名或移除的权限。我们最初为 Vercel Agent 维护了一份单独的权限列表，它可能与签发其令牌的 OAuth 服务不同步。我们改为使用相同的范围定义，以便在规划期间捕获这些不匹配。
在会话设置时，Vercel Agent 从 Vercel 范围注册表加载这些定义到内存目录中。获取注册表需要团队授权，而范围定义本身在团队之间共享。该目录提供在三个阶段使用的定义：
- 计划验证：请求的范围会被规范化，未知或格式错误的名称会在计划被存储或提交审批之前被拒绝。
- 审批：请求的范围决定计划是否符合只读基线，还是需要额外访问权限。
- 令牌准备：有效范围定义已批准工作的凭据。
有效权限来自何处以及如何检查。
例如，更新防火墙规则的任务可能请求一个过时的范围。系统会拒绝提议的计划并返回有效范围，以便 Vercel Agent 在请求批准之前进行纠正。这会在规划期间捕获不匹配，并要求显式纠正，而不是回退到更广泛的访问权限。
获取注册表会增加延迟和服务依赖，因此 Vercel Agent 会缓存该目录，并在加载已存储的计划时使用该副本进行检查。这些检查反映缓存的定义，直到目录通过注册表中的更改刷新。
恢复工作需要一份有效且已批准的计划
Vercel Agent 可能在原始聊天请求结束后才收到批准，或在执行已批准的重新部署之前失去连接。存储的计划包含其状态、批准人及批准时间，以及其任务和请求的权限。该记录将提议的工作与用户授权的访问权限关联起来，并允许在恢复工作时检查批准。
计划被批准、拒绝或停止时会发生什么。
在恢复之前，运行时会重新加载计划，并在选择具有其已批准权限的凭据之前检查该计划是否处于活动状态。已停止的计划无法通过该检查，即使其令牌在到期前仍有剩余时间。
如果批准和停止请求同时到达，只有当停止尚未改变计划状态时，计划才能从等待批准转为活动状态。然后，运行时会在使用已批准的凭据之前再次检查计划是否处于活动状态。
如果调查发现当前计划需要替换，Vercel Agent 可以提议另一个计划。请求提升访问权限的替换计划需要其自己的批准，让用户有机会一起审查修订后的工作和权限。
权限需要更精确的地方
随着 Vercel Agent 触及平台的更多部分，我们不得不修正涉及多个资源或具有不同后果的操作的访问规则。附加域名可能需要域名和项目权限，而暂存防火墙规则和发布它需要不同级别的访问权限。范围需要捕捉这些区别，同时保持每个计划的访问请求可管理。
将这些范围与提议的修复相匹配需要在规划全程中谨慎处理：
- 选择范围：Vercel Agent 在信息不完整的情况下选择范围，因此它可能请求过少的访问权限而使任务受阻，或请求过多而授予超出工作所需的权限。任务级指导帮助它选择，而验证会捕获无效的范围名称。即使是有效的范围也可能授予超出必要的更广泛访问权限。
- 描述工作：“重新部署上次成功的构建”为用户提供了一个具体的操作来评估，而仅凭范围名称则让用户自己去推断后果。计划需要解释预期的更改，并明确令牌实际执行哪些限制。
- 理解拒绝：被拒绝的操作可能表示缺少范围、资源不正确，或本应保持阻止的操作。Vercel Agent 需要在请求额外权限之前区分这些情况。
即使拥有正确的权限，重新部署也需要判断所选提交是否可以安全发布。这取决于应用程序、故障和提议的修复。用户需要足够的信息来评估该选择，而 Vercel Agent 仍必须正确执行它。
只读调查还需要对其检索的信息进行控制，包括敏感的项目配置和操作细节。我们选择了只读基线，以便 Vercel Agent 在请求批准之前进行调查，而这一选择需要随着范围及其暴露的信息变化而持续审查。其他系统可能需要更窄的基线。单独的控制必须管理检索到的信息如何处理以及可以流向何处。
Vercel Agent 可能做出错误决策，或在其读取的内容（如构建日志）中遇到恶意指令。在这两种情况下，范围凭据限制了它可以执行的操作，但被允许的操作仍可能造成损害。因此，计划与沙箱隔离、网络策略、机密处理、速率限制、审计日志和服务授权协同工作。我们在代理架构中的安全边界方面的工作解释了代理、其凭据及其执行的代码之间的分离。
从调查到已批准的操作
权限始终与需要它的工作绑定。运行时为活动计划选择已批准的凭据，其范围定义了 Vercel Agent 可以执行的操作。由于调查已经完成，用户可以一并评估提议的修复及其请求的访问权限。
试用 Vercel Agent 来调查你项目中的问题。查看它发现的内容，如果它提议更改，请在批准前评估计划及请求的访问权限。