不是你的智能体搞砸了生产环境，而是你的流水线。

你的智能体没有搞砸生产环境，搞砸的是你的流水线。

许多团队使用智能体来提交拉取请求（PR）。他们使用 CI 来进行代码检查、测试和构建。然后，通过定时任务将代码从 staging 环境移动到生产环境。这种设置最终会导致失败。

问题不在于智能体是否有恶意，而在于流程不当。你将两个不同的问题合并到了同一个关卡中：

• 这通过 CI 检查了吗？
• 这现在适合让用户看到吗？

这两者并不相同。CI 检查的是代码能否运行，而不是检查某个功能是否已准备好交付给客户。

如果你的流水线将“已合并”和“已上线”视为同一回事，那么你就麻烦了。你是在没有决定进行持续部署的情况下，被动地进入了持续部署模式。

你必须将这两个事件解耦。

你可以使用特性开关（feature flags）来实现这一点。特性开关本质上只是一个布尔值和一个 if 语句。你不需要昂贵的工具就能开始，一个简单的配置值或环境变量即可。

我的设置遵循以下规则：

• PR 合并到 main 分支，但 main 分支并不是最终运行的代码。
• 一个独立的发布步骤将 main 分支提升到生产分支。
• 我必须明确发出“开始”指令。没有定时任务或计时器。
• 发布过程会等待构建完成后开始提供流量。
• 自动化检查会访问关键端点以确认网站运行正常。
• 人员会对变更进行最后的手动检查。

这创建了一个关卡。在用户看到任何内容之前，人类、机器和另一个人都有机会说“不”。

如果 Bug 仍然触达了用户，你需要快速回滚。为此，请在数据库迁移时遵循“扩展与收缩”（expand and contract）模式：

• 添加一个允许为空（nullable）的新列。
• 回填数据。
• 同时向旧列和新列写入数据。
• 从新列读取数据。
• 仅在后续的发布中删除旧列。

如果你跳过这一步，你的回滚按钮将毫无用处。如果一次迁移删除了旧代码需要的列，你就无法回滚，只能眼睁睁看着系统处于故障状态。

智能体会让这些错误发生得更快。它消除了曾经掩盖你糟糕流程的人工摩擦。你所忽略的规范从来都不是可选的，它只是以前被“人类在周五下午 5 点前发现错误”这一行为所掩盖了。

一旦把人从流程中移除，纪律就变成了强制性的。

来源：https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o