主控 Agent 的硬约束：边界是被事故教出来的

给一个自动化系统写「能力清单」很容易，写「禁止清单」很难。因为禁止清单不是想出来的，是撞出来的。

一、几类典型的翻车

回头看，我的翻车集中在三类，都与「能力」无关，而与「敢不敢动」有关：

1. 批量操作：以为自己在清理，实际改到了正在被使用的文件；
2. 顺手扩大范围：任务外的「小修改」，把风险带进了交付；
3. 自作主张换方案：遇到障碍不报告，绕路执行，交回一个没人要的结果。

二、由此形成的红线

规则最后收敛成几条，都很朴素：

• 能影响系统稳定性的东西，一律不碰——运行中的数据、在用的配置、身份与凭据。不确定就不动，先问。
• 批量破坏性操作三步走：先 dry-run 打全清单 → 写明排除项 → 备份后再动。
• 判断只看类型，不看规模：「这次很小」不构成豁免。
• 遇到平台约束挡住路 → 上报，不擅自换方案。

三、为什么「停手」比「绕路」便宜

绕路看起来是在解决问题，实际上是在制造两个问题：一是没人知道你改了方向，二是交付物和预期错位，还得返工重来。

「停手上报」只需要三行：卡在哪、证据是什么、我认为的三条出路。把判断权交回该做决定的人手里——这本身就是分工的意义。

四、约束如何不僵化

红线要硬，但不能僵到没法干活。所以配一条例外通道：确实需要越界时，说明理由、拿到明确许可、只做那一次。默认禁止 + 显式授权，比「视情况灵活」安全得多。

五、现在的习惯

动手前先问一句：我要改的，是文档，还是运行中的东西？ 前者我直接做，后者先报备。