1. OpenClaw 3.31 审批卡住到底卡在哪OpenClaw 3.31 升级之后审批流程频繁卡住是很多做自动化审批的开发者遇到的头号问题。简单说OpenClaw 是一个把大模型能力接进本地工作流的自动化代理框架它能让你用自然语言驱动 shell 命令、文件操作、定时任务适合做新闻抓取、Telegram 机器人、内容管理等场景。而 3.31 这次升级官方把安全审批机制从「按工具名覆盖」改成了「语义审批类」配置项的名字和行为对不上了于是你明明写了ask: offgateway 还是弹审批。我先把结论摆出来3.31 之后审批相关的配置必须在主配置里显式声明否则 gateway 会回退到内部默认值而内部默认值比你写的更严格。这不是缓存问题重启 gateway 没用改exec-approvals.json也可能被覆盖。下面我会给出可复制的config.toml与settings.json骨架再演示怎么通过 TaoToken 统一 Key/API 通道把审批链路验证跑通最后把几个高频报错逐个拆掉。适合谁看正在用 OpenClaw 做自动化审批、刚从 3.28 或更早版本升到 3.31、被allowlist execution plan unavailable或「每次 exec 都弹审批」卡住的开发者。如果你还没升级看完再决定动不动。2. 先把 TaoToken 通道准备好审批链路要验证绕不开模型调用。OpenClaw 的 agent 在执行命令前很多审批判断和语义分类是要走模型推理的所以你得先有一条稳定的 API 通道。我用 TaoToken 做统一入口原因是它把 Key 管理和模型调用收敛到一个地方OpenClaw 这边只要填一个 base_url 和一个 Key不用在多个供应商之间来回切。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点固定为 https://taotoken.net/api 注意这个地址后面不加任何 UTM 参数配置里直接写它就行。拿 Key 的路径是进控制台在 API Keys 页面新建一个。控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。新建的时候建议按用途命名比如openclaw-approval方便后面排查是哪个 Key 在调。如果你只是想先验证模型通不通可以用模型对话页面直接发一条消息试试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。这一步能排除「Key 本身有问题」和「OpenClaw 配置有问题」这两类故障很多人一上来就怀疑 OpenClaw其实是 Key 没生效。长期跑编码和 Agent 任务的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面把 base_url、鉴权头、模型名格式都列清楚了照着填不会错。注意Key 只放在本地配置文件或环境变量里别写进会提交到 git 的仓库。OpenClaw 的配置文件经常被同步到多台机器这点尤其要小心。3. 可复制的 config.toml 与 settings.json 骨架OpenClaw 3.31 的配置分两层一层是主配置~/.openclaw/openclaw.json一层是审批专用~/.openclaw/exec-approvals.json。3.31 之前写哪个都行3.31 之后必须在主配置里显式声明tools.exec否则 gateway 用内部默认值。下面这份config.toml是我实测能跑通的骨架字段含义我逐条标了。# ~/.openclaw/config.toml # OpenClaw 3.31 审批链路配置骨架 [gateway] # gateway 监听地址本地调试用 127.0.0.1 即可 host 127.0.0.1 port 8787 # 3.31 新增显式声明审批策略来源避免回退到内部默认值 approval_source config [model] # 统一走 TaoToken 通道 provider openai-compatible base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 模型名按接入文档里的格式填 model claude-sonnet-4-20250514 timeout_seconds 60 [tools.exec] # 关键security 和 ask 两个字段必须同时写 security full ask off # 3.31 新增语义审批类留空表示不额外限制 approval_class # 允许的命令前缀按需增删 allowlist [ls, cat, grep, curl, python3] [logging] level info # 审批相关日志单独落盘排查时直接看这个文件 approval_log ~/.openclaw/logs/approval.log对应的settings.json骨架主要管运行时行为和审批弹窗{ openclaw: { version: 3.31, gateway: { approval_source: config, fallback_to_default: false }, tools: { exec: { security: full, ask: off, approval_class: , allowlist: [ls, cat, grep, curl, python3] } }, model: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY } } }两个文件的关系是config.toml管 gateway 和模型通道settings.json管运行时行为。3.31 的坑在于如果你只在exec-approvals.json里配了 allowlist主配置里没写tools.execgateway 会认为你没声明直接上内部默认值也就是「每次都要审批」。所以两个文件里的tools.exec段要保持一致别只改一个。环境变量这样设别把 Key 硬编码进文件export TAOTOKEN_API_KEY你的Key # 验证环境变量生效 echo $TAOTOKEN_API_KEY | head -c 8改完配置重启 gatewayopenclaw gateway restart # 确认 gateway 读到了新配置 openclaw gateway status --verbose | grep approval_source如果输出里approval_source是config而不是default说明主配置生效了。这一步是分水岭很多人卡住就是因为这里还是default。4. 验证审批链路是否真的通了配置写完不算完得实际跑一条命令看审批还弹不弹。我用的验证方式是让 agent 执行一个ls因为ls在 allowlist 里正常情况下不该弹审批。# 触发一次 agent 执行 openclaw agent run --task 列出当前目录文件 --exec ls -la预期结果是直接返回文件列表不出现审批请求。如果还是弹审批先看审批日志tail -n 50 ~/.openclaw/logs/approval.log日志里会写清楚这次审批是哪个字段触发的。常见的有两种一种是ask field missing, fallback to default说明你的ask字段没被读到另一种是approval_class mismatch说明语义审批类把你的命令重新分类了。再验证模型通道是否真的走了 TaoTokencurl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY | head -c 200能返回模型列表说明 Key 和通道没问题。这一步能帮你把「OpenClaw 配置问题」和「API 通道问题」分开。我试过很多人以为是 OpenClaw 卡审批其实是 Key 过期了模型调用失败agent 卡在等待推理结果看起来像审批卡住。审批链路完整跑通的标志是agent 执行 allowlist 内的命令直接返回执行 allowlist 外的命令才弹审批且审批日志里能看到approval_sourceconfig。三个条件都满足才算真的绕开了 3.31 的配置陷阱。5. 本篇常见错排查5.1 报错 allowlist execution plan unavailable (unsupported platform)这个报错在 Windows 上远程使用时特别常见。3.31 的语义审批类在部分平台上还没实现完整的 allowlist 执行计划于是直接报平台不支持。绕开方式是把审批判断从平台侧挪到配置侧也就是把approval_class留空靠allowlist和ask: off来控制。[tools.exec] security full ask off approval_class # 留空避免触发平台侧执行计划 allowlist [ls, cat, grep]改完重启 gateway再跑一次验证命令。如果还报检查settings.json里fallback_to_default是不是false这个字段设成true会让 gateway 在平台不支持时回退到默认审批反而更容易卡。5.2 改了 exec-approvals.json 但没生效3.31 之后exec-approvals.json的优先级低于主配置里的tools.exec。如果你只在exec-approvals.json里改了 allowlist主配置没动gateway 会以主配置为准。解决方式是两边保持一致或者干脆把审批配置全部收敛到主配置exec-approvals.json只留空壳。{ exec_approvals: { enabled: false, note: 审批配置已迁移至 openclaw.json 的 tools.exec 段 } }5.3 只写了 security: full 没写 ask: off这是最高频的坑。ask字段缺失时gateway 会回退到内部默认值也就是「每次都要审批」。security和ask必须成对出现缺一不可。检查方式grep -A 5 exec ~/.openclaw/openclaw.json确认security和ask都在。如果用的是 TOML检查[tools.exec]段下两个字段是否都写了。5.4 升级后 allowlist 里的命令被重新分类3.31 的语义审批类会把你 allowlist 里的命令重新分类导致你以为允许的命令实际被拦。比如curl可能被归到「网络访问」类需要额外声明。解决方式是在approval_class里显式声明允许的类别或者把命令拆细。[tools.exec] approval_class file_read,network_read allowlist [ls, cat, grep, curl]改完记得重启 gateway并且清一次审批缓存rm -f ~/.openclaw/cache/approval_cache.json openclaw gateway restart5.5 gateway 重启后配置又回退了如果你用 systemd 或类似方式托管 gateway重启时可能读的是另一份配置。检查启动脚本里的--config参数指向哪个文件确保和你改的是同一个。ps aux | grep openclaw | grep config输出里能看到实际加载的配置文件路径。如果指向的不是你改的那个改启动脚本或者把配置软链过去。6. 把审批链路固定下来的几个动作审批链路验证通过之后别急着收工。3.31 这个问题大概率会在后续版本修复但在此之前把配置固定下来能省很多事。我的做法是把config.toml和settings.json纳入版本管理每次升级前先 diff 一遍重点看tools.exec段有没有被覆盖。模型通道这边长期跑 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 里面把 base_url 和鉴权方式都写清楚了。Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建议给 OpenClaw 单独建一个 Key方便按用途排查。最后留一个我常用的自检脚本升级后跑一遍能快速定位审批配置有没有被回退#!/bin/bash # openclaw-approval-check.sh CONFIG~/.openclaw/openclaw.json echo 检查 tools.exec 段 grep -A 5 exec $CONFIG echo 检查 gateway 审批来源 openclaw gateway status --verbose | grep approval_source echo 检查审批日志最近 10 行 tail -n 10 ~/.openclaw/logs/approval.log echo 验证 TaoToken 通道 curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY | head -c 100跑完这四步审批卡住的原因基本能定位到具体字段。3.31 的坑说到底就是配置优先级和字段完整性把security和ask成对写全把审批配置收敛到主配置再配合 TaoToken 统一通道验证模型调用审批链路就能稳定跑起来。
