OpenClaw 审批机制全解：allow-once、allow-always、deny 到底该怎么选？

如果你在 OpenClaw 里开过 exec，那你大概率见过这样的提示：

/approve bb5b3c5b allow-once
/approve bb5b3c5b allow-always
/approve bb5b3c5b deny

很多新手第一次看到，会把它当成"某种命令大全"。

其实不是。

它的本质很简单：

这是 OpenClaw 给真实主机执行命令加的一道人工闸门。

官方文档把这套机制叫 Exec approvals。它的作用是：当一个沙箱里的 Agent 想在真实主机（gateway 或 node）上执行命令时，只有在 策略、allowlist 和可选用户审批 都同意的情况下，命令才会真正落地执行。

这篇文章不讲空话，只讲你最关心的 5 件事：

allow-once、allow-always、deny 分别是什么意思
什么时候该选哪个
它们和 security、ask、askFallback 的关系
为什么你明明选了 allow-always，后面还可能继续弹审批
怎么把审批机制配得既安全又不烦人

一、先搞清楚：OpenClaw 的审批，不是"聊天动作"，而是"执行护栏"

OpenClaw 的审批并不是单纯为了好看，也不是一个"UI 交互层的小功能"。

它控制的是 真实命令执行。

官方明确说明，Exec approvals 适用于主机侧执行，也就是：

gateway host
node host

而且它是在执行主机本地生效的，不是只在聊天界面里"问一下"。真正的约束来源，是主机上的 ~/.openclaw/exec-approvals.json 加上当前请求的 tools.exec.* 策略，最终取更严格的那一层。

所以你可以把审批机制理解成：

OpenClaw 允许 Agent 做事，但不会默认允许它在真机上乱跑命令。

这就是为什么审批这么重要。

二、三个决定到底是什么意思？

OpenClaw 的官方动作就这三个：

/approve <id> allow-once
/approve <id> allow-always
/approve <id> deny

官方文档给出的定义非常直白：

Allow once → 现在执行一次
Always allow → 加入 allowlist，然后执行
Deny → 阻止这次执行

翻译成人话就是：

1）allow-once

这次我同意，但只限这次。

2）allow-always

这次我同意，而且以后类似命令也按长期信任处理。

3）deny

这次不准跑。

如果你只记一句话，那就记这句：

allow-once 是临时放行，allow-always 是建立长期信任，deny 是直接拦截。

三、这三个动作，最核心的区别不在"这次过不过"，而在"以后还问不问"

这才是很多人真正容易搞混的地方。

allow-once

只解决当前这一笔审批
适合你"先让它做一次，我再观察"

allow-always

不是单纯"这次也放"，而是会把可持久化的结果写进 allowlist
也就是说，它不只是一次动作，更是在修改这台主机对这个 Agent 的长期信任边界

deny

直接结束
这次不执行，也不会新增长期信任

所以真正的判断题不是：

"这次让不让它跑？"

而是：

"我愿不愿意以后也少看见这类审批？"

这就是 allow-once 和 allow-always 的真正分水岭。

四、什么时候该选 allow-once？

这是最适合新手的默认选项。

因为它风险最小，决策成本也最低。

适合 allow-once 的场景

1. 你第一次看到这个命令

你还不熟这个命令的用途、参数、影响范围，那就先放一次，别急着长期信任。

2. 参数变化很大

有些命令虽然可执行文件相同，但参数不同，风险差很多。这时先用 allow-once 更稳。

3. 你只想完成当前任务

今天只是让它看个状态、跑个检查，不代表你以后都希望它自动过。

4. 你还在调试 Agent 的行为边界

很多时候不是命令本身危险，而是你还不确定这个 Agent 会不会越来越"胆大"。这时保留一次一审，能看得更清楚。

如果让我给一个最实用的建议，那就是：

看不懂、第一次见、参数复杂、行为还没摸清时，优先用 allow-once。

五、什么时候才该用 allow-always？

allow-always 不是不能用，但它应该是一个"想清楚之后的选择"，而不是一个"嫌烦直接点掉"的按钮。

官方文档说明，allowlist 是 按 Agent 分开维护的，而且匹配是基于路径模式的长期规则。allow-always 的意义，就是把当前这类可识别的执行对象纳入这个 Agent 的长期信任范围。

适合 allow-always 的场景

1. 稳定、低风险、重复率高的命令

例如反复查看状态、打印系统信息、读取版本号这类命令：

bash

pm2 status
systemctl status nginx
uname -a
uptime

2. 你已经知道这个 Agent 经常要做这件事

例如运维 Agent 经常检查服务状态，开发 Agent 经常跑某个固定测试脚本。

3. 你明确想减少后续审批噪音

你不想每次都人工点确认，那就把高频低风险动作长期放行。

不过这里有一个非常关键的官方细节：

即使你选了 allow-always，如果有效的 ask 模式是 always，后面仍然会继续提示。

也就是说，allow-always 不是"从此再也不问"。它只是"把它纳入长期信任名单"，但最终还要看审批策略是不是要求 每次都问。

这也是很多人最容易误解的点。

六、什么时候必须选 deny？

deny 不是"保守的人才用"，而是 OpenClaw 审批链里非常正常的一步。

适合 deny 的场景

1. 你看不懂命令目的

看不懂就别放，尤其不是你的环境、不是你的流程、不是你的操作习惯时。

2. 命令带删除、覆盖、批量改动倾向

例如涉及：

删除文件
覆盖配置
重启关键服务
批量移动或替换内容
带 shell 链式执行

3. 命令和当前任务目标不一致

比如你只是让它查状态，它却想动文件、改系统、装东西，那就该拦。

4. 你怀疑 Agent 在"跑偏"

审批最大的意义之一，就是让你能在模型偏离目标时踩刹车。

一句话：

deny 不是否定 Agent，而是在保护你的主机、你的流程、你的边界。

七、决定这三个动作体验的，其实是背后的 3 个策略旋钮

光会点按钮还不够。你要真正理解 OpenClaw 审批机制，必须看懂这三个配置：

security
ask
askFallback

官方定义如下：

1）security

控制主机执行的总边界：

deny：全部阻止 host exec
allowlist：只允许 allowlist 命中的命令
full：全部允许

2）ask

控制是否提示审批：

off：从不提示
on-miss：allowlist 没命中才提示
always：每一条都提示

3）askFallback

控制"该问但没人能批"时怎么处理：

deny：直接拒绝
allowlist：只有 allowlist 命中才放
full：直接允许

这三个旋钮组合起来，才是你每天真实体感里的审批行为。

八、最常见的 4 种审批风格

风格一：严格保守型

适合生产环境、重要机器、刚开始上手。

json

{
  "defaults": {
    "security": "allowlist",
    "ask": "on-miss",
    "askFallback": "deny"
  }
}

含义：

allowlist 内的放行
allowlist 外的都要问
没人能批就拒绝

这是最稳的默认思路。

风格二：每次都确认型

适合高风险机器、你想强审计的环境。

json

{
  "defaults": {
    "security": "allowlist",
    "ask": "always",
    "askFallback": "deny"
  }
}

含义：

就算是长期信任的命令，也每次确认
allow-always 也不能让提示消失

这种模式下，allow-always 的作用更多是维护 allowlist，而不是取消弹窗。

风格三：效率优先型

适合你已经非常熟悉环境，并且想减少打断。

json

{
  "defaults": {
    "security": "allowlist",
    "ask": "off",
    "askFallback": "allowlist"
  }
}

含义：

allowlist 内的直接过
不做实时审批
allowlist 外的不会乱放

这种适合成熟团队和固定流程。

风格四：YOLO 型

官方 CLI 文档明确给了"Never prompt / YOLO example"：

把主机审批默认设成 security=full、ask=off、askFallback=full，就会变成几乎不拦的模式。

bash

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

这类模式不是不能用，但更适合你完全清楚后果的时候。它追求的是效率，不是保守。

九、为什么我已经 allow-always 了，还是继续弹？

这是最常见误区，必须单独说。

官方文档写得很明确：

allow-always 的持久信任，不会在 ask=always 时阻止继续提示。

所以出现这种情况，并不代表失败了，也不代表 allowlist 没写进去，而是因为：

你把命令长期信任了
但系统策略仍然要求"每次都确认"

这两件事不冲突。

解决办法

先查当前生效策略：

bash

openclaw approvals get
openclaw approvals get --gateway
openclaw approvals get --node <id|name|ip>

官方 CLI 文档说明，approvals get 会显示：

请求侧的 tools.exec 策略
主机 approvals file 策略
最终生效的结果

如果你发现 host 本地是 ask: "always"，那它就是继续弹的根因。

十、审批到底该在聊天里做，还是在主机上配？

答案是：真正的门在主机上，聊天只是入口之一。

官方 FAQ 说得非常清楚：

approvals.exec：控制是否把审批提示转发到聊天目标
channels.<channel>.execApprovals：让该渠道作为原生审批客户端

但无论怎么转发，真正的批准门槛仍然是 host exec policy。

所以：

聊天里的 /approve 是"我来处理这笔请求"
主机上的 approvals file 决定"这台机器到底允许到什么程度"

这两个层级不能混。

十一、给你一个最实用的选择口诀

如果你懒得记整篇文章，只记下面这个就够了：

先看熟不熟
  不熟：allow-once
  熟：继续往下看

再看是不是高频低风险
  是：allow-always
  不是：allow-once

最后看有没有疑点
  有疑点：deny

再压缩成一句：

第一次见、没把握、参数复杂，用 allow-once；稳定重复、低风险、常用动作，才考虑 allow-always；看不懂或不该跑，直接 deny。

十二、推荐给大多数人的默认策略

如果你问我，OpenClaw 最适合大多数人的审批思路是什么，我会给你这一套：

配置层

用保守默认：

json

{
  "defaults": {
    "security": "allowlist",
    "ask": "on-miss",
    "askFallback": "deny"
  }
}

操作层

新命令：先 allow-once
高频低风险命令：再转 allow-always
可疑动作：直接 deny

这套方案的好处是：

不会一上来就 YOLO
不会每一条都烦你
也不会轻易把长期信任边界放太松

对绝大多数 OpenClaw 用户来说，这是最平衡的一种用法。

十三、最后总结

OpenClaw 的审批机制，真正要回答的问题从来不是：

"这条命令能不能跑？"

而是：

"这条命令这次能不能跑、以后还要不要继续问、我愿意把它信任到什么程度？"

所以你可以这样理解三个动作：

allow-once：这次过，但我还在观察你
allow-always：这类动作以后可以更顺畅
deny：这次到此为止

如果你把它们用对了，审批机制不会拖慢 OpenClaw，反而会让它更像一个可控、可审计、可长期协作的系统。

最后送你一句最实用的话：

allow-once 是试用，allow-always 是签约，deny 是踩刹车。

只要你把这三件事分清，OpenClaw 的审批机制就不难了。

问题求助

没能解决你的问题？直接问我

如果你遇到任何技术问题无法解决，可以在这里提交求助。我会尽快查看并回复你。

支持作者

如果这篇文章帮到了你，可以支持我

扫码打赏，支持我持续更新原创排障文章。