Github 原文：shareAI-lab/learn-claude-code
上一篇文章中，我们制作的 Agent 有 5 个工具。其中有一个工具——file tools 受 safe_path 保护，但 bash 不受限制。让它”清理一下项目”，可能执行 rm -rf /。
安全不能靠信任模型，要靠代码——在工具执行之前做判断。
解决方案
我们上篇文章设计的循环完全保留。
唯一的变动在工具执行前插入 check_permission()——每个工具调用经过三道闸门，顺序固定：硬拒绝优先，软询问次之，都没命中就放行。
啥意思？简单来说就是：
| 闸门 | 作用 | 命中后 |
|---|---|---|
| 1. 拒绝列表 | 永远禁止的操作（rm -rf /、sudo） | 直接拒绝，不执行 |
| 2. 规则匹配 | 取决于上下文的操作（写工作区外、rm 文件） | 交给闸门 3 |
| 3. 用户审批 | 闸门 2 命中后，暂停等用户确认 | 用户决定允许或拒绝 |
当然还有一种情况，那就是三道都没命中，那就直接执行，大部分日常操作走这条路。
看到这里，你是不是一下就懂了你在使用 codex 和 cc 的时候，会询问你同意这个东西到底是怎么来的了？
工作原理
我们这里来详细讲讲这三个“闸门”。
闸门一：绝对不允许做的事
你也不希望 Agent 操作 bash 给你数据库全删了吧？
那么这个就需要闸门一，它有一张硬拒绝表，先查，命中就返回阻止信息。（简单字符串匹配不是可靠安全机制，命令变体和 shell 展开可能绕过，所以在实际的实战落地中，会有更加复杂的方式）
闸门二：不必事事过问的贴心管家
闸门二就像个贴心的管家，它走规则匹配——描述”什么时候需要问用户”，毕竟每条都来问你，打断效率，得一直看着，也挺烦的不是吗？因此闸门二就存在了，它让每条规则指定工具和检查条件。
不是闸门一不允许的一条调用请求，如果闸门二觉得没事的，安全的很，那么就直接放行，如果闸门二觉得，不行有点危险，我得问问用户，那他就把这个提交到了闸门三。
闸门三：用户输入触点
闸门三就是那个你在 CC、Codex 等一众工具中老是能看到的那个询问你是否允许的东西，等待你是否同意执行这个命令，但有一说一，这部分目前各家在人性化方面做的都不好，多数人问了也没用，完全看不懂，只会点同意。。。
漫画详解
这里方便理解，我依然用 AI 做了个小漫画，来解释这个部分。
