后续：关于我那篇「通话前检查」帖子的 22 条回复，比我写它时学到的还多。六条经验，注明出处。

三天前我发了一篇帖子，介绍在 Agent 的每次工具调用前都加一道硬检查的四种模式（链接见评论）。这些回复比原帖更好，所以在此一并整理，注明出处。**指名规则，而非数字。**（u/QuanTradin）一句「金额必须低于 500」的拒绝，等于邀请对方试试 499。应说明触发了哪条规则、下一步该做什么（「询问用户」），而任何关于如何修改策略的内容，都留给人工在日志里处理。**按工具名拦截，一旦 Agent 能执行 shell 就会泄露。**（u/mastafied）屏蔽 send_mail，一个铁了心的模型会写十行 Python 调用同一个 API。真正的解法是咽喉点（choke point）：凭证只存在于它之后，shell 就无从触及。至于强制推送，远程仓库的分支保护胜过任何模式匹配。**替换危险参数，而非校验它们。**（u/AdministrativeBad752）URL 几乎不可能做白名单：重定向、像 [email protected] 这样的 userinfo、十六进制 IP、以及校验后才给出不同结果的 DNS。应传递一个不透明句柄，映射到经过审核的上游，然后把剩下的任何参数都视为恶意。**在参数解析之后检查，而不是按用户输入的原文检查。**（u/ianreboot）「./build/../.env」或一个名为 notes.txt 的符号链接能通过字面校验，但写入却落在别处。**检查事实来源，而不是 Agent 的记忆。**（u/federicodonatone）他们的外发邮件检查在每次发送前读取已发送文件夹，因为草稿、定时发送和撤销窗口从 Agent 的视角看都像「已发送」。**预占（hold）需要幂等键。**（u/Excellent-Nebula-313）如果预占成功但回复丢失，重试应该恢复同一个预占，而不是重复预留两次。而一个无人处理的预占，会按最坏情况计费：「不确定它是否执行过」不等于「它没有执行过」。贯穿全帖的一条主线：模式检查是护栏，不是沙箱。它能以低成本捕捉常见情况，并且应该如实说明这一点。**披露：**原帖的四种模式是我一直在构建的库 Paveo 的核心，今天它正式公开了。对照这个帖子，如实评估：**能做的：** 拒绝时会指名规则并让模型停下、去询问，不会泄露策略中的数字或如何修改策略（#1）。无人处理的预占按最坏情况计费（#6 后半部分）。按工具限制速率和重复次数。**尚不能做的：** 在比较前解析路径（#4）。这是我接下来要构建的，因为有两个人问了。它在你的进程内运行，因此是一道检查，而非持有凭证的咽喉点（#2）：应当配合使用，而非替代。**注意：** 它的速率限制统计的是它所见到的调用数，这正是 #5 警告的 Agent 侧视角。凡是有真实事实来源的地方，也要一并检查。Python 3.11+，进程内运行，不发起网络调用，最多两个 Agent 免费，源码开放。链接见评论。你会在这份清单上加什么？