每一辆跑得快的车都该有刹车。这是句废话——直到你发现，整个 AI agent 赛道都在造更猛的引擎，没人装刹车。

你大概有过这种时刻。给一个自主 agent 派了个活：「把这个登录 bug 修了。」它接走，后台跑了二十分钟，回头给你开了个 PR。你点开 diff，bug 确实修了。但它顺手还动了三个你压根没提的文件，其中一个在认证模块里。它觉得「refactor 一下更干净」。你后背有点凉。

这种凉不是因为这个 agent 笨。恰恰相反，是因为它太能干，能干到你根本没让它做的事它也顺手做了。而整个过程里，没有任何东西对它说「不」。

我觉得这才是这一轮 AI agent 浪潮里最被忽视的问题。所有人都在比谁更自主。Devin 强调你 assign 完就可以去喝咖啡，Copilot 的 coding agent 强调后台独立工作，Jules 恨不得告诉你它同时跑六十个任务，Multica 甚至能把 agent 像同事一样排进看板、让小队长分派任务、定时触发日报周报。方向高度一致：更少的人介入，更多的 agent 自走。

这当然是好事。能自主干活的 agent，是这一波技术真正值钱的地方。

但我慢慢发现一个不太对劲的对称性缺失：我们给 agent 踩到底的油门，却忘了给它装刹车。

「刹车」在这里是个具体的、一点都不浪漫的东西——在 agent 真正去改一个文件之前，有没有一道机制能判定：这个文件，它今天能不能碰？如果它在修 bug 的路上顺手摸了认证模块，有没有东西当场拦下它，而不是等它全改完了再靠人 review diff 兜底？

答案几乎是：没有。你去翻这些产品的边界，它们基本都停在 issue 级、PR 级，或者仓库分支级。「把任务派给谁」「什么时候派」「派给哪台机器跑」——这些调度问题，它们解决得很好。但「agent 落笔改文件的那一瞬间，这个写动作到底允不允许」——这个问题，它们不答。

这事在系统工程里其实有个老说法。安全关键系统有一条基本原则叫 fail-closed：出了异常、判不准的时候，默认停机，宁可不动也不能乱动。电梯失电抱闸，核电站失控紧急停堆，自动驾驶感知冲突时踩刹车——都是 fail-closed。它的潜台词是：有些场合，「什么都不做」比「做点什么」安全得多。

而几乎所有 AI agent，默认是 fail-open 的。它们被训练成「尽量帮用户把事办成」，遇到边界模糊、权限不清的情况，倾向于往前迈一步试试，而不是停下来问。一个 fail-open 的系统，平时特别好使，因为它总在帮你。直到有一天它帮你帮过了头。

我得承认，让 agent 自主，本身没什么毛病。一个能自己规划、自己执行、自己提 PR 的 agent，是过去几年最让人兴奋的东西。我自己也用得很爽。

可「能用」和「能放心用」之间，差着一道门槛。门槛就是：当它做错了，是在它动手之前就被挡住，还是在它做完之后才被发现。 前者叫约束，后者叫 review。这俩看着都拦住了问题，代价却天差地别——前者是 agent 压根改不了它不该改的，后者是你得在每一个 PR 里瞪大眼睛找它偷摸改了什么。团队一大、PR 一多，后者根本兜不住。

再往深想一层，这其实不只是技术问题，是责任问题。

当一个能改生产代码的 agent 真的进了团队，「它被允许改哪些文件」就不只是个配置项，是一道责任线。出事了——线上挂了、密钥泄了、认证逻辑被悄悄改坏了——谁担？如果 agent 既是写代码的那个、又是审查的那个，那等于没人审。企业治理里有一条快被说烂但永远成立的底线：生成和审查必须分离，人类对最终落下来的那一行代码负责。

这条底线，在 agent 越自主的时候，越容易被悄悄绕过。因为自主的 agent 太顺手了，顺手到你会忘了它也是会犯错的、也是会被诱导的、也是需要被喊停的。

所以我现在越来越觉得，这一波缺的不是更强的 agent，是给所有 agent 的那一脚制动。

它不需要很重。一道在每次写文件前判一下路径的 hook，一次必须由人按下才推进的阶段切换，一条「想改代码先退回去显式说明」的递进锁，就够了。它甚至不该是个独立的大产品，它最好是那种能装进任何 agent 工具链的、极轻的一层——让 agent 该自主的时候自主，但在它越界的那一刻，有个东西能默认说不。

回到开头那句废话。引擎造得再猛的车，没刹车是上不了路的。只不过这一次，「车」是会自己改你生产代码的 agent，而我们还停在比谁引擎更猛的阶段。

（task-loop 是这个思路的一个极轻开源实现：给 Claude Code 装一个 fail-closed 的文件级守门 hook，越界写当场拦，阶段切换人发车。）