原文标题：Agent Responsibly
原文链接：https://vercel.com/blog/agent-responsibly

Agent Responsibly

作者：Matthew Binshtok — 2026 年 3 月 30 日

以下内容基于 Vercel 内部分享的一次演讲。我们将其公开发布，因为它所描述的问题并非 Vercel 独有，而且这个框架对任何使用 Agent 进行交付的团队都有参考价值。

Coding Agent 正以前所未有的速度生成代码。在有严格判断力的工程师手中，它们是生产力倍增器。但如果缺乏严谨的判断，它们就是一种将错误假设高效直送生产环境的方式。

当团队盲目部署 Agent 生成的代码时，后果可能是立竿见影的。一个看起来完美无瑕的 Pull Request 可能提交了一个通过测试、却在生产中扫描每一行数据的查询。看似正确的重试逻辑可能在下游服务上引发”惊群效应”（thundering herd）。而一个没有 TTL 的缓存可能悄无声息地增长，直到 Redis 崩溃。

绿色的 CI 不再是安全的证明。在 Agent 时代，“通过 CI 只是反映了 Agent 说服你的流水线某项变更是安全的能力——即使它一上线就会立刻降级你的基础设施。“

虚假的信心

Agent 生成的代码具有危险的说服力。它附带着精心撰写的 PR 描述，通过了静态分析，遵循了仓库的代码约定，并包含合理的测试覆盖。从表面上看，它就像是一位资深工程师写的。

但 Agent 并不理解你的生产环境。它不知道你的流量模式、你的故障模式，或者你共享基础设施中的隐式约束。它不知道某个 Redis 实例已经接近容量上限，不知道某个数据库硬编码到了特定区域，也不知道某个 Feature Flag 的灰度发布会从根本上改变下游系统的负载特征。

“这个 PR 看起来是正确的”与”这个 PR 可以安全上线”之间的鸿沟一直存在。Agent 加宽了这条鸿沟——它们生成的代码比以往任何时候都更完美无瑕，却对生产环境的现实完全视而不见。

“利用”与”依赖”

利用（Leveraging）AI 和依赖（Relying on）AI 之间存在根本性的区别。

• 依赖意味着：如果 Agent 写了代码、测试通过了，那就可以上线了。作者从未建立起对变更的心智模型。结果就是大量充满隐藏假设的 PR，因为无论是作者还是审查者都无法清晰说明代码到底在做什么，根本无法审查。
• 利用意味着：使用 Agent 快速迭代，同时对输出保持完全的所有权。你清楚地知道代码在负载下的行为。你理解相关的风险。你愿意为此负责。

在一个 Pull Request 上署名意味着”我已经阅读了这段代码，并且理解它在做什么。“如果你需要重新阅读自己的 PR 才能解释它可能对生产环境产生什么影响，那工程流程已经失败了。

判断标准很简单：你是否愿意为与这个 Pull Request 相关的生产事故承担责任？

守护生产环境

答案不是停止使用 Agent。生产力的提升是不可否认的，而且模型只会越来越好。AI 辅助的代码审查和分析是极其强大的工具，能够发现人类遗漏的 Bug 和风险。

但仅仅依靠审查——无论是人工审查还是 AI 审查——在面对 Agent 生成代码的巨大产量时，注定是一场败仗。“我们已经到达了一个拐点：实现代码不再稀缺。真正稀缺的资源不再是编写代码，而是判断什么可以安全上线。”

所有基础设施都必须适应这一新现实。

这不是要给开发生命周期套上层层审批的枷锁。而是要构建一个闭环系统，让 Agent 能够以高度自主的方式运作，因为它们的环境是标准化的，验证是简便的，部署在默认情况下就是安全的。

组织原则很简单：让正确的做法成为最容易的做法。

自动驾驶式部署。 每一项变更都通过门控流水线（gated pipeline）逐步灰度发布。如果金丝雀部署（canary deployment）出现降级，灰度发布会自动停止并回滚。系统不依赖工程师盯着仪表盘。它自行捕获问题，将影响控制在一小部分流量上，然后自动回退。当出现问题时，它只在局部出问题——而不是全局性故障。

持续验证。 基础设施持续地自我测试——不仅仅是在部署时。负载测试、混沌实验（chaos experiments）和灾难恢复演练在持续进行。在 Vercel，去年夏天在生产环境中进行的数据库故障转移演练，正是今年一次真实的 Azure 故障对客户毫无影响的原因。能在压力下屹立的系统，是那些经过了刻意压测的系统。

可执行的护栏。 在 Vercel，运维知识被编码为可运行的工具，而非文档。一个 safe-rollout skill 不是一个解释 Feature Flag 如何工作的 Notion 页面。它是一个实际的工具——它配置 Flag、生成带有回滚条件的灰度计划，并指定如何验证预期行为。当护栏是可执行的，Agent 就能自主遵循，人类也不需要背记规则。

最终目标不是让工程师对每一项变更都施加极致的审慎。而是让基础设施本身是严谨的。在这样的世界里，快速交付默认就是安全的——因为系统自身能控制爆炸半径、持续验证、优雅降级，并将最佳实践编码为可执行的默认值。

我们正在投入的方向

核心平台团队正在积极地将这些护栏构建到共享基础设施中：

• 围绕共享基础设施建立更强的护栏，在部署流水线的每个阶段进行运行时验证
• 在 PR 阶段实施更严格的静态检查，尤其是围绕 Feature Flag
• 在 Staging 环境中进行镜像生产流量的端到端测试
• 只读 Agent 在生产环境中持续验证系统不变量——使用专门的 Agent 来审计生成式 Agent 所做的假设
• 通过 defect-commit 与 defect-escape 比率等指标，在平台层面及时发现风险上升趋势

利用 Agent，承担风险

我们的标准是：利用 Agent，而不是依赖它们。

低质量的代码过去看起来就像低质量的代码。现在不是了。AI 工具只会变得更强大。Diff 会越来越大，代码会越来越有说服力，盲目信任输出的诱惑也会越来越强。真正出色的工程师不会是生成最多代码的人，而是对自己交付的内容保持冷酷判断力的人。

在你提交下一个 PR 之前，问自己：

• 这段代码做了什么？灰度发布后它的行为是什么？
• 它可能如何对生产环境或客户造成负面影响？
• 如果因为这段代码引发生产事故，我是否愿意承担责任？

如果答案是”是”，你就是在利用 AI。放心交付。

如果答案是”否”，你还有工作要做。

引用

• 原文：Agent Responsibly — Vercel Blog, 2026-03-30