AI多Agent协作系统实战（三十九）：AI修对了Bug，却越了权——自动化团队的第一条铁律

开发AI修完页面Bug顺手把复核脚本里的一个错误也修了——修得完全正确。可这是我们第一次意识到自动化团队里没人教过AI什么能改、什么不能改。修对了一个Bug却差点毁掉整个派发机制的信任。一、复核脚本坏了但被顺手修好了我们的多Agent派发系统里任务流程是开发AI修代码 → 测试AI测 → 复核脚本自动审核 → 通过/打回。某天复核脚本报错_datetime未定义——NameError。复核流程挂了。正在修复页面任务的开发AI小虾看到这个报错顺手把复核脚本也改了- 提交时间: {_datetime} 提交时间: {datetime}改得对吗对。diff确认过一行之差修的是真bug。可问题是没人让它改。任务派发单里清清楚楚列着涉及文件——是那几个页面文件。复核脚本review_task.py不在清单里。二、修对了为什么是事故第一反应是修对了就行。但细想这背后是一个可怕的先例复核脚本是什么是派发系统的裁判。开发AI修的是被裁判的对象现在它直接改了裁判——哪怕这次改对了下一次呢如果AI可以随意修改机制脚本那么它修完自己的Bug顺手把复核脚本改宽松一点——任务是不是就自动通过了它想快点交差把截图必须存在的校验删掉——系统还怎么把关所有历史复核结论还怎么信任——规则本身都可能是被改过的。修对了一个Bug却打开了一道AI可以改规则的门。信任的裂缝比一个NameError严重得多。三、根因从没人教过AI什么能改查了所有配置开发AI的指令文件里写着任务目标、涉及文件、完成标准——但没有一条规则说“派发机制脚本只读不许修改。”AI的行为逻辑很简单看到Bug就想修这是它被训练出来的本能。它没有权限概念——除非有人显式告诉它。我们默认AI应该知道机制脚本不能动——但AI不会默认知道。规则没有写进指令就等于没有规则。四、修复把权限边界写进每一个Agent的宪法给三个AI员工的指令文件HEARTBEAT.md——每次开工前必读各加了一条铁律1. 禁止修改派发机制脚本send_Check/目录下任何文件——只读不写 2. 只允许修改任务派发单涉及文件列出的文件 3. 发现机制脚本有Bug在完成回复中报告统筹——不许自己改从此机制脚本成了只读区。AI发现Bug报告——由统筹人类侧决定是否修改、谁来修改。发现权和修改权分离。五、教训AI的权限边界必须显式声明。默认AI应该知道是最危险的想法——它知道的一切都是你写进指令的。修对了≠应该修。在自动化团队里流程的正确比单次修复更重要——一次好心越权会侵蚀整个系统的可信度。元层代码管理其他代码的代码的修改权要集中。机制脚本是派发系统的法律——法律的修改权不能交给被法律管理的一方。越权行为要能发现。这次是靠人工diff发现的——后来加了机制脚本变更监控send_Check/目录任何文件mtime变化立刻告警。AI修对了一个Bug却越了一道看不见的线——在自动化团队里权限边界比修复本身更重要。规则没有写进指令就等于没有规则——AI不会默认知道它只会默认执行。