北京
一个AI智能体想要强制推送代码到主分支。不是因为它搞混了什么——rebase卡住了，强制推送能解决问题，推理链条每一步都合理。局部正确，全局代价高昂。
这个例子之所以有教育意义，是因为命令本身带着后果。git push --force origin main，危险就写在命令里。你可以做模式匹配，可以把它放进清单，一个钩子函数读一下字符串就能拦截。
但我真正担心的大多数情况，根本不是这个样子。
两次退款调用，一次是灾难
看这两次退款调用：
一次退40英镑，一次退4万英镑。同一个接口，同样的参数名，同样的结构，同样的原因代码，所有预执行钩子能从文本里读到的东西全都一样。
关键来了：这两次调用本身都没有错。4万英镑可能是对一张完全合法的账单的完全合法的退款。40英镑可能是对一小时前已经退过的款项的再次退款——某种意义上这才是更糟的那个。你没法通过看代码来区分它们，因为让其中一次成为错误的那个因素，根本不在调用本身里。
爆炸半径是目标的属性，不是命令的属性
强制推送的例子之所以成立，是因为危险藏在动词里。强制推送在几乎所有场景下都是危险的。你真正需要它的场景少到可以枚举，所以一条规则就能覆盖它，而且这条规则大致上一直成立。
带金额的API调用，其危险性取决于另一侧的状态。那次退款是否安全，取决于调用方根本拿不到的信息：
- 这笔支付是否已经被退过款，全额还是部分？
- 商户余额是否覆盖，还是会让它变成负数？
- 这个操作者今天已经动过多少资金？
- 原始支付是否处于争议中——这种情况下退款对最终责任方的影响完全不同？
- pay_9f2c14 到底是不是这个商户的支付？
坐在智能体进程里的钩子，这些全都不知道。它能读到意图。成本不是意图的属性。
“行，让钩子去查一下”
这是显而易见的下一步，而且不蠢。让守卫去调用API，拉取支付信息，看看余额，然后做决定。
真去构建的时候，你就会发现自己签了什么协议。
你的钩子现在需要读取支付状态的凭证，这意味着智能体宿主为了防范智能体宿主，反而持有了你账本的读权限。它需要理解退款语义、争议状态和结算时机才能做出判断，所以你的退款规则现在活在两个必须永远保持一致的代码库里。而且它在检查和执行之间有一个时间窗口——
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
