上一篇聊的是 Anthropic 那个 200 人团队，代码 100% 由 AI 写，但让 agent 自己改代码库这件事还在评估中，负责人原话是「我们其实是怕的」。那篇留下的问题是，那条线该画在哪。
大家好，我是一个做了十七年后端的架构师。这篇就只讲一件事，线怎么画，闸怎么装。
先把结果摆这儿。我把 agent 的权限分成五档，目前开到第三档，第四档和第五档没开。下面四道闸，今天下午能装完前三道。
闸一，验证必须可执行，不能靠人看
大部分团队现在的验证方式是「让 agent 写完，人 review 一下」。这套在一天五个改动的时候够用，一天五十个的时候直接塌。Spotify 那篇里说得很直白，变更数量已经超过了一些验证机制的处理能力（InfoQ）。
可执行的验证长什么样，至少要有一条能自动判对的路径。迁移类任务做等价性比对，接口类任务做契约测试，数据类任务做影子流量回放。Anthropic 那次把大型代码库从 Python 迁到 Rust，人设计的就是这类「怎么确认最终产物符合预期」的办法，苦活交给 agent，判据留在人手里（Business Insider）。
我自己的做法是项目里放一个固定的验证命令，agent 改完必须自己跑一遍，跑不过不许提交。
bash
# .claude/commands/verify.md
1. 跑全量测试，输出通过率与失败清单，不许只说「测试通过」
2. 列出本次改动删除或改签名的公开接口
3. 与改动前同一组输入做一次结果比对
4. 生成变更清单，标注涉及的配置项与开关第二条和第四条是我后来加的。吃过亏，agent 改了个工具方法的签名，测试全绿，上线之后另一个模块调不到。
闸二，把自动化变更排进人的工作时段
这一条我直接从 Spotify 抄的。他们把自动化变更安排在负责团队的工作时段执行（同上，InfoQ）。
听着很土，其实特别管用。agent 半夜跑出来的改动，出问题的时候没人接。我给自己定的规矩是，自动化任务只在两段窗口跑，上午十点和下午三点，跑完必须把结果推到群里。
如果你用的是定时任务，就两行 cron 的事。
bash
# 只允许在这两个窗口触发自动化改动
0 10 * * 1-5 cd /path/to/project && claude -p "/verify"
0 15 * * 1-5 cd /path/to/project && claude -p "/verify"闸三，回滚能力先于自动化能力
这条是硬判据，做不到就不许上自动化。
问自己三个问题。这次改动能不能一键回滚？回滚之后数据状态对不对？回滚要多久？
Spotify 出事之后的动作之一就是扩大回滚能力（同上）。顺序特别重要，他们不是先停自动化，是先补回滚。
我自己加的规矩更粗暴，没有一键回滚路径的改动，agent 一律不许碰。
闸四，授权分级，把那条线画出来
Anthropic 现在的状态就是一张现成的分级表，agent 已能在无人干预下自主修测试，改代码库还在评估中（IT之家与腾讯新闻转述）。
我照这个思路做了自己的矩阵。
| 动作 | 自动执行 | 需要人在环 | 我现在的档位 |
|---|---|---|---|
| 修失败的测试 | 是 | 否 | 已放开 |
| 改业务代码 | 是 | 是，看 diff | 已放开 |
| 开 PR | 是 | 否 | 已放开，限窗口 |
| 合并到主干 | 否 | 是，人点 | 未放开 |
| 动生产配置 | 否 | 是，双人 | 未放开 |
最后一档还有个更保守的玩法。Hacker News 上有个做法是「夜间跑 backlog 的 agent，只开 PR，从不自己合并」（The nightly Ralph loop）。这一条我认，PR 是给人看的提案，合并是人的责任，这两件事最好别交给同一个角色。
今天下午就能做的一件事
打开你的 agent 配置文件，把「允许自动执行」的工具列表翻出来，看看里面有没有 bash 的写操作、有没有 git push。有就先摘掉，只留测试和本地改动。
这一步做完，你就已经有了闸四的最低版本。
坦白讲
这四道闸我装到第三道，第四道只做了「不合并」这一层。回滚这块我自己的项目里也只有一部分服务做得到一键回滚，数据类的改动还是得人工兜。所以这篇给的是我已经跑过的部分，不是我全做到的部分。
还有一点，上面那个 verify.md 的第三条「与改动前同一组输入做结果比对」，在涉及外部依赖的服务上我还没找到省事的做法，目前只能靠在测试环境固定一批输入。这块你要是有更好的办法，评论区教我一下。
金句
先装回滚，再上自动化。顺序反了，出事的时候你连退路都没有。
往期推荐
- 《80 万行让 AI 重写，GitHub 靠的不是模型，是那层临时兼容层》
- 《数据库防呆机制几十年前就有了，你只是没给 Agent 接上》
- 《1866 个热门开源项目写给 AI 的规范，只有不到二十分之一说清了怎么检查》
先跑通，再优化，干就完了。
素材来源与出处
| 内容 | 出处 | 链接 |
|---|---|---|
| Spotify 变更量超过验证机制承载能力、自动化变更排入负责团队工作时段、出事后扩大回滚能力 | InfoQ 中国，2026-10-23 | www.infoq.cn/article/rVq... |
| Python 迁 Rust 时人设计验证办法、苦活交给 agent | Business Insider，2026-10 | www.businessinsider.com/anthropic-k... |
| agent 已可无人干预自主修测试、改代码库仍在评估 | IT之家与腾讯新闻，2026-10-22 | news.qq.com/rain/a/2026... |
| 夜间跑 backlog 的 agent 只开 PR、从不自己合并 | Hacker News，2026-10-22 | news.ycombinator.com/item?id=501... |
说明，文中数字与做法均来自上表链接或作者本人项目实践，未做任何估算或凑整。作者本人未验证的部分已在「坦白讲」一节标注。