编码代理的权限应如何延伸到部署

AI 编程代理能改代码、跑测试，也能执行部署命令，但这些动作不该共用一份授权。作者的核心主张是：先自动化开发工作，把会影响用户、数据和费用的关键决定留给人。

这篇文章的价值在于把「允许 AI 干活」拆成具体权限，并提出一套可以试用的验收流程。对正在把 Agent 接入项目的前端和全栈团队，更值得讨论的是它可以独立做到哪一步，以及交付时要拿出什么证据。

能写代码，为什么不等于能决定上线

作者把权限划成五级：

• Level 1「Read」：读取文件、日志、文档和配置。
• Level 2「Suggest」：生成代码、测试、计划和补丁。
• Level 3「Change」：修改文件，运行本地检查。
• Level 4「Propose」：创建 pull request 或变更申请，交给人审查。
• Level 5「Execute」：合并、发布、部署，或者修改生产系统。

这套分法关注的是动作造成的后果。解释函数、重构重复代码，通常容易检查和撤销；生产部署则可能导致用户无法访问、数据损坏、密钥泄露、基础设施费用增加，也可能通过依赖影响其他服务。某次看起来普通的数据迁移，还可能难以回退。

能执行部署命令，不代表有权决定这次部署现在就该发生。

因此，作者反对给 Agent 一个笼统的 do_the_job 权限。一个「完成需求」的指令里，可能同时包含读代码、改代码、合并和上线，实际却跨越了几种不同的责任。

作者认为，日常编码工作大多可以在 Level 1–4 内完成；Level 5 应采用另一套标准。对小型 Web 项目，他建议先允许 Agent 跑测试、运行 linter、准备提交或 PR，而合入主分支、修改生产配置、通过外部服务花钱，都应先获得批准。后续再根据表现逐项扩权。

Agent 交付时，应该拿出什么证据

权限限制只回答了「能做什么」，没有回答「做得是否可靠」。

作者建议的流程是：接收任务、检查现状、制定计划、实现、测试、展示证据、人工审查，最后部署。这里最有用的增加项是「展示证据」：Agent 要说明增改了哪些测试、实际执行了哪些命令、作出了哪些假设，还有什么没有验证。

「测试通过」是一句结论；具体命令、执行结果和验证范围，才方便审查者判断这句话覆盖了多少内容。

作者提出一个「10 分钟实验」：挑一个小功能，让 Agent 在明确约束下完成，再按普通 PR 审查。下面这段提示词用来约束它的工作范围和交付内容：

You may inspect the repository and modify source files.

You must:
- explain the current implementation first
- make the smallest reasonable change
- add or update tests
- run the relevant checks
- report the exact commands and results
- list assumptions and remaining risks

Do not deploy, merge, or modify production systems.

要看清最后一行：禁止部署、合并和修改生产系统。中间的 report the exact commands and results 则要求它报告实际做过的检查，审查时需要核对这些结果是否足以支持改动。

这个实验衡量的是 Agent 能承担多少开发环节，以及它有没有增加审查负担。作者举的例子很直接：如果省下 30 分钟敲代码，却多出 45 分钟验证，整个流程未必更快。这是一个假设性的成本比较，原文没有提供实际计时记录，也没有展示「10 分钟实验」的执行结果。

调查里的部署比例，能证明什么

原文引用 Stack Overflow 2026 Developer Survey：66% 的受访者使用 AI 编程助手或代理，其中 73% 每天使用。

在使用 AI agents 的受访者中，委派编写或生成代码的比例为 72.9%，调试为 62.2%，编写或维护测试为 50.6%，部署则只有 9.8%。

两组数据的统计对象需要分清。前一组涉及编程助手或代理，后一组讨论使用代理的人把哪些任务交给它。不能把 9.8% 直接理解成全体开发者使用 AI 部署的比例。

这些数字支持作者的观察：开发者更愿意委派代码生产，对部署更谨慎。但它们没有证明「让 Agent 部署一定更危险」，也没有解释低比例究竟来自权限限制、工具接入情况，还是团队自己的选择。原文没有给出这些原因的拆分。

我的判断

我赞成按动作划权限，也赞成要求 Agent 交证据。相比只写一句「小心操作」，这套方法能落实到仓库权限、分支规则和生产环境访问控制上，团队也更容易明确谁负责最后的决定。

不过，作者把 Level 1–4 描述得相对安全，需要结合执行环境理解。运行本地检查可能触发项目脚本；如果环境里带着生产凭据，所谓本地操作也可能访问外部服务。权限边界要落实到可访问的资源，光在提示词里写禁止事项还不够。

另外，人工批准和自动部署可以同时存在。团队可以让人决定是否发布，再由 CI/CD 执行部署、检查和回滚。原文对这些替代流程没有给出对照数据，也没有比较人工批准与自动发布的故障率。它更适合作为引入 Agent 时的起步策略，而非已经验证过的最优方案。

真正该计算的是从提出需求到审查完成的总成本。 生成速度只是其中一部分。

能拿来做什么

• 给现有 Agent 列一张动作权限表，分别写清读文件、改源码、跑检查、创建 PR、合并和部署的授权，避免一句「完成需求」覆盖全部动作。
• 在前端或 Node 项目中选一个小功能，使用原文提示词试跑，要求交付具体命令、结果、假设和未验证项，再按普通 PR 审查。
• 记录 Agent 节省的实现时间和新增的验证时间，先判断开发流程是否变快，再决定扩大使用范围。
• 如果团队已有 CI/CD，可以让 Agent 准备变更和验证材料，由人批准发布，再交给现有流水线执行部署。