Vercel 内部做过一次关于 AI Agent 责任使用的分享，最近公开了。很实用，不是在说 AI 多厉害，而是说 AI 多容易让人踩坑。
## 问题在哪
AI 生成的代码看起来很可信：PR 描述完整、测试通过、风格符合规范，就像一个老工程师写的。但 AI 其实不了解你的生产环境——不知道流量模式、不知道失败模式、不知道共享基础设施的隐性约束。
Vercel 举了几个真实场景：
– 一个看起来没问题的查询，在生产环境会扫描每一行数据
– 重试逻辑看似正确，实际会产生雷鸣般的羊群效应压垮下游服务
– 没有 TTL 的缓存在悄悄增长，直到 Redis 挂掉
现在的 CI 通过不等于安全。在 AI 时代，CI 通过只是说明 AI 很擅长说服你的流水线相信这个改动是安全的——哪怕它会在生产环境立刻劣化你的基础设施。
## 依赖 vs 利用
这里有个本质区别：
– 依赖 AI：觉得 AI 写的加测试通过等于可以发布，作者自己都没有建立对改动的心理模型。PR 体量巨大，满是隐性假设，根本没法 review。
– 利用 AI：用 AI 快速迭代，同时对输出保持完全的所有权。清楚代码在负载下的表现，理解相关风险，愿意为之负责。
简单判断标准：你愿意为这个 PR 相关的生产事故背锅吗？
如果答案是否定的，说明你还需要更多工作。
## Vercel 的解法：让正确的事情更容易做
不是说不用 Agent，而是把基础设施做成让正确的事情默认发生。
自驱式部署（Self-driving deployments）：每次变更通过渐进式灰度发布。如果金丝雀部署出现降级，系统自动停止并回滚。不依赖人盯着仪表盘。出了问题也在局部，不会扩散。
持续验证：基础设施不仅在部署时测试，而是持续不断地跑负载测试、混沌实验和灾备演练。Vercel 去年在生产环境演练过数据库故障转移，所以今年 Azure 真实宕机时对客户是完全透明的。
可执行的 Guardrails：把运维知识编码成可运行工具，而不是躺在 Notion 里的文档。比如 safe-rollout 不是一个解释功能标志怎么用的页面，而是一个实际接线功能标志、生成灰度计划（含回滚条件）、指定验证方式的工具。当 Guardrails 可执行，Agent 就会自动遵守，人类也不需要死记硬背。
## 核心原则
不是给开发流程加官僚主义，而是建立闭环系统——让 Agent 可以在高自主环境下运作，因为环境是标准化的、验证是简单的、部署默认是安全的。
终点不是工程师对每个改动都极度严谨的世界，而是基础设施本身就很严谨的世界。
## 写在最后
下次开 PR 之前，问自己三个问题：
1. 这个改动做了什么？ rollout 之后表现如何？
2. 会对生产或客户造成什么负面影响？
3. 我愿意为这段代码背生产事故的锅吗？
如果都是 Yes，你在利用 AI。发吧。
—
原文：https://vercel.com/blog/agent-responsibly
暂无评论内容