提示词指令没能阻止我的 Agent，但调用时的检查做到了。四个经受住验证的模式

过去几周里，我在我 Agent 的每一次工具调用前面都加了一道硬性检查，并用我自己两个月的 Claude Code 历史记录进行了测试。我学到的主要一点是：你写进提示词的任何内容都只是一种请求，而处于压力下的模型完全可能说服自己绕过它。而针对调用本身的检查（在执行之前检查工具名称及其参数）是没法被说服绕过的。四个经受住验证的模式： 约束参数，而不仅仅是工具。"允许退款"毫无用处。"允许退款，amount_usd 上限 500，且 amount_usd 必须存在"这才是一条规则。如果某个参数可以通过省略来绕过限制，那它就不算限制。而且，如果规则列出了一个工具可以接受的参数，那么任何其他参数都应该被拒绝。 顺序比预期的更重要。"只有在本会话中更早调用过带有相同 order_id 的 lookup_order 之后，才允许退款"——这条规则能拦住那种跳过检查、直接执行操作的 Agent。保留被比较过的值的摘要，而不是值本身，这样就不会存储任何敏感信息。 对于成本，在调用前预留最坏情况，调用结束后再结算。每次调用之后再统计开销，无法阻止三次并行调用——每次单独看都在剩余预算之内，但合在一起就超了。而对每一次调用在其执行过程中预留其最大值，就能阻止这种情况。如果一次调用中途失败，就按最坏情况计费：它可能已经被扣费了。 把拒绝信息写成一条指令。"已拒绝：金额超过 500。不要换个方式重试；告诉用户你本来想做什么"会让下一步动作与"错误：已拒绝"截然不同。一个简单的拒绝会促使模型去寻找其他途径。 用一份简短的禁止清单（递归删除、强制推送、reset --hard、修改 Agent 自身的设置）回放我自己的历史记录，本可以阻止 8,176 次工具调用中的 117 次 rm -rf。这些并不全是错误，但我宁愿它当时来问我。 你的 Agent 绝不应该在不询问的情况下采取的那一个动作是什么？你今天又是如何强制执行它的？