生产运维 Agent 如何按修复计划授权

让 AI 修复线上部署，难点不只是找到故障，还包括决定它能动哪些资源。提前给足权限，误操作可能波及其他项目；每一步都弹确认，用户又容易养成直接点通过的习惯。

Vercel Agent 的做法是先用只读权限调查，再把修复动作和所需权限放进同一份计划，交给用户一起审批。这篇文章值得读的地方，是它把这套流程背后的凭证、API 校验和恢复执行机制讲清楚了，也承认了一个边界：授权合理，不代表修复一定正确。

先查清问题，再批准具体动作

用户说「修复这个部署」时，Agent 还不知道要看什么日志、是否需要重新部署，更不该直接拿到一组宽泛的写权限。

Vercel Agent 会先检查近期部署和构建日志，把失败版本与最近一次成功版本比较。如果调查结果支持重新部署，再提出包含具体动作和权限的计划，例如「重新部署最近一次正常的构建」，申请 read-write:deployment。

这里的 scope 是授权系统识别的能力名称，可以理解为凭证允许执行的操作类别。每个任务记录自己需要哪些 scope，系统再把它们合并成整份计划的权限请求。

用户批准的对象，是准备执行的工作及其所需权限。

短小的只读查询可以直接运行；较长的调查会生成只读计划，让用户看到任务和进度，但自动执行。当前只读基线包含所有已注册、以 read: 开头的 scope。

有个流程细节容易被忽略：只要一份计划超出只读基线，整份计划都要等待批准，里面的只读任务也不能提前跑。因此，文章中的调查与重新部署被拆成两份计划。先取得证据，用户才能判断后面的写操作是否合理。

计划负责说明意图，token 和 API 负责限制操作

Vercel Agent 作为 Vercel App，在用户授权的团队内代表用户执行工作。它的权限上限来自用户已有权限，用户批准计划也不能授予自己原本没有的能力。

Vercel OAuth 服务把授权换成有效期更短、带指定 scope 的 token。只读调查使用基线 token；需要额外 Vercel 权限的计划获批后，系统再次检查 scope，准备包含只读基线和已批准权限的 token。Vercel API 在每次请求时检查凭证。

模型指令负责提醒 Agent 何时提计划、何时申请批准。真正挡住越权请求的是 API：即使模型认为某个操作对完成任务很有必要，只要 token 没有权限，请求仍会被拒绝。

不过，权限类别与具体资源之间还有距离。

计划写了部署 X，不代表 token 就只能操作部署 X。

read-write:deployment 比「重新部署一次指定构建」更宽。它不等于环境变量、域名和团队成员管理权限，但也不是天然绑定单次部署的凭证。运行时负责确认计划处于 active 状态，再选用已批准的凭证；API 则检查该凭证的 scope、团队、用户权限和有效期。

跨服务任务也遵循各自的授权边界。一份计划可以同时包含 Vercel 修改和创建 GitHub pull request，用户一次审阅，但两边使用独立凭证。文中的 GitHub 授权绑定 owner 和 repository：批准在 acme/storefront 创建 pull request，不覆盖 acme/payments，后者需要单独批准。

权限定义与计划状态，都要在执行时管住

这套机制还要处理两个工程问题：计划申请的权限可能过时，获批的工作也可能已经被叫停。

Vercel 团队最初为 Agent 单独维护权限列表，后来发现它可能与 OAuth 服务脱节，于是改为共用 Vercel scope registry 的定义。会话建立时，Agent 将定义加载到内存目录；获取 registry 需要团队授权，但定义本身在团队间共享。

这份目录贯穿三个环节：保存和展示计划前，规范化并校验 scope；审批时，判断是否超出只读基线；准备 token 时，确定有效权限。如果更新防火墙的任务用了过时名称，系统会拒绝计划并返回有效 scope，让 Agent 明确修正，而不是退回到更宽的权限。

代价是获取 registry 会增加延迟和服务依赖。Vercel 因此缓存目录，重新加载已保存计划时也使用缓存校验。缓存刷新之前，检查依据仍是旧定义。原文没有说明刷新周期，以及权限撤销如何与缓存更新衔接。

计划状态则决定获批权限还能不能使用。用户可能在原对话结束后批准计划，Agent 也可能在执行前断线，所以保存记录需要包含任务、权限、状态、批准人和批准时间。

恢复时，运行时重新加载计划，确认它仍为 active，才能选用对应凭证。即使 token 尚未过期，已停止的计划也不能通过这个检查。批准与停止同时到达时，只有停止尚未改变状态，计划才能转为 active；使用凭证前还要再检查一次。

如果调查发现需要替换方案，新计划只要请求额外权限，就必须重新审批。

我的判断

我认可它把调查和修改分开的方向。用户看到故障证据、准备部署哪个版本，以及为什么需要写权限，才有条件做出有效判断。只展示一串 scope，或者连续弹出孤立的工具确认框，都容易让审批失去上下文。

共用权限定义、由 API 强制检查、恢复执行前重查计划状态，也都是比单靠提示词更可靠的工程措施。不过，文章没有提供误操作率、审批耗时或越权拦截率等对照数据。「更安全」在这里主要由机制设计支撑，不能当作已经量化验证的效果。

它的局限也很明确：scope 合法，不代表 scope 足够精细。绑定域名可能同时需要域名和项目权限，暂存防火墙规则与正式发布规则也应区分。Agent 在信息不完整时选权限，可能申请不足而卡住，也可能申请过多。校验名称只能解决其中一部分问题。

只读基线同样需要结合团队情况决定。所有 read: 自动放行，有利于排障，但项目配置和运行细节也可能敏感。相比默认开放全部只读能力，一般团队可以按任务收窄可读资源；文章也明确承认，其他系统可能需要更窄的基线。

最后，权限正确与业务判断正确是两件事。最近一次成功构建是否仍适合上线，要看应用和故障上下文，不能仅凭历史构建状态决定。构建日志中的恶意指令也可能误导 Agent。scope 能限制操作范围，却不能保证范围内的操作无害，因此还需要沙箱隔离、网络策略、密钥处理、限流和审计日志配合。

能拿来做什么

• 给前端部署助手设计流程时，先安排读取部署记录、构建日志和比较版本，再生成独立的修改计划，让审批界面展示调查依据与拟执行动作。
• 用 Node 接入平台 API 时，把权限检查放到实际执行请求的服务层，并使用受限凭证；模型生成了调用参数，不能成为放行依据。
• 在计划中同时写清业务动作与真实授权范围，例如「重新部署最近一次正常构建」及 read-write:deployment，明确凭证是否绑定具体资源，避免界面承诺超过系统约束。
• 给能够中断和恢复的 Agent 保存批准人与计划状态，恢复前重新校验；用户停止任务后，即使 token 尚未到期，也应阻止继续使用该计划的凭证。