让 AI Agent 碰生产前，先抄这 5 道护栏

先说结论

如果你正打算给 AI 编码 Agent 自建一套花哨的 harness，先停一下：多数团队缺的不是更强的编排，而是几道能挡住事故的护栏。护栏不需要多聪明，只需要在任何时候都能答上来三个问题——谁能动生产、动了怎么停、改坏了能不能整批回滚。

一个可以对照的样本

Matt Mazur 公开分享过自己的做法（以下数字均为其自述，未经第三方审计）：不搭复杂编排，全部跑在 Claude Code 桌面端的定时例程里，用 Mac 上的 caffeinate 防止休眠；配合书面 playbook 和一组硬约束，给一个已经跑了 17 年的 Rails SaaS（Preceden）在一个月里合入约 1531 个 PR、约 20 次批量部署，并自称期间没有发生回滚。

这个数字不必当标杆，但它说明一件事：能规模化的是流程约束，而不是更花哨的调度。

护栏一：例程角色表

每个定时例程只干一类活，每次都是新鲜会话，各自带一份书面 playbook：

• SEO 例程：按小时跑，负责文档、结构化数据、站点地图、落地页；
• Code 例程：按小时跑，修 bug 必须“先有能失败的测试，再有能通过的测试”，顺手补测试、删死代码；
• Dependency 例程：每晚只升一个包，安全告警优先；
• 选题/排名跟踪例程，以及负责审计其他例程的周回顾例程。

关键不是角色分得多细，而是一个例程一件事：权限、上下文、产出都可预期，出问题也定位得快。

护栏二：禁区清单 + 只走分支

禁区清单要写成文件，而不是留在脑子里：涉及支付、计费、数据迁移、生产配置、密钥目录的路径，Agent 一律不准改；每个改动独立分支 + PR，先进 dev，绝不直接碰 master；合并前跑安全审查，一旦有发现就停下来等人。

配套的是“故意做小”：PR 小到能一眼看完，先让系统稳定跑起来，再谈更大的野心。

护栏三：kill switch

必须有一个不依赖 Agent 自身判断的停止方式：一条命令、一个开关或一个环境变量，能立刻停掉所有例程。原则是先停、再查——出现异常时不要指望 Agent“自己修好”，先让系统停下来，再复盘日志。

护栏四：早晨 ask 队列

把需要人决策的事集中成队列，而不是随时弹窗打断人：例程遇到越权、无法判断或需要授权的事，不往下做，写进队列，人第二天早上一次性处理。

这条被低估得很厉害。人在白天连续点几十次“允许”之后，注意力会明显下降；而在固定时段集中看几条真正需要判断的事项，质量完全不同。人不是流程里的按钮，而是队列的审阅者。

护栏五：双模型审部署

部署不让单个模型说了算：工作日由部署例程把 dev 合进 master，条件是全量测试通过 → Claude 审整批判动 → Codex 独立二审 → CI 通过 → 平台上线；上线后盯一段时间日志和错误监控，需要时整批回滚，并让回滚粒度与 PR 批次对齐。

两个模型互审的价值不在于谁更聪明，而在于多一个视角，能把明显的问题拦在部署之前。

可以直接抄的检查表

1. 每个例程是否有独立角色和书面 playbook？
2. 禁区清单是否写成了文件，并被例程读取？
3. 是否所有改动都走分支 + PR，且不直接改主干？
4. 出问题时的 kill switch 是哪一条命令，谁有权执行？
5. 需要人决策的事，是否集中进队列而不是即时弹窗？
6. 部署是否至少有一道独立复审，且整批可回滚？
7. 失败是否由“先失败再通过”的测试证明，而不是由模型自述？

小结

把 Agent 放进生产，与其追求更聪明的编排，不如先落实这五件事：角色清晰、禁区明确、能停、人只做审阅、部署有独立复审。它们的收益是可预期的：不会让 Agent 变聪明，也不会让故障消失，但能把“不可控”变成“可回滚”。

（文中案例数字均来自当事人公开自述，未经独立审计；具体实践请结合自身团队与合规要求评估。）