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