OpenClaw 跑得越顺我心里反而越没底。这句话听起来有点反直觉但凡是把 OpenClaw 从个人实验搬到团队生产环境的人多半能对上这个感觉代理的执行力越强越没人敢给它在生产环境里完全放开手脚。OpenClaw v2026.3.28 这一版我拿到手后第一时间研究的不是新技能包也不是调度性能而是 requireApproval 这个看似低调的审批插件。它把 Human-in-the-loop人在回路从一句停留在 PPT 上的口号变成了真正可配置、可审计、可落地的工程能力。我打算在这篇文章里完整拆一遍 requireApproval 的设计思路、配置方法、实际接入过程以及我在真实项目里踩过的那些坑。这篇文章适合正在把 OpenClaw 推向团队协作场景、或者已经在生产环境里跑着多条自动化任务、但对代理做错事越来越焦虑的开发者。1. 先说一个让我下定决心做审批机制的深夜事故1.1 一次误触发的自动化指令差点把测试库当成生产库事情的起因很平淡。某天夜里十一点多我接了一个数据同步任务给它配了定时触发OpenClaw 的调度器按计划开始跑。凌晨两点代理在执行一个历史遗留任务时错误解析了配置文件里的路径把本该写入测试副本的数据推到了生产归档目录。好在那条任务执行前保留了一条完整的 webhook 通知虽然当时没人看但第二天早上我花了十分钟就回滚了全部变更数据没有受损。但是后怕一直没散。代理没有恶意它只是把看起来最合理的下一步执行完了。真正的问题不在于模型判断错没错而在于系统从设计上就没有给人类留一个否决或者确认的位置。任何自动化系统只要它执行的动作满足三个特征——影响范围大、自动回滚难、出错后损失不可控——就必须在动作真正落地之前存在一道人工闸门。这就是 requireApproval 插件存在的全部理由它不是用来限制代理能力的而是用来给代理的盲区兜底。1.2 那晚之后我整理出的三层信任模型复盘到凌晨三点我给自己整理了一套三层信任模型后来成了我配置 OpenClaw 所有策略的底层框架。第一层是权限边界代理能访问哪些资源。比如它能读哪些目录、能调哪些 API、能操作哪些数据库。这一层通常由 OpenClaw 的凭证与资源绑定机制解决做的是能不能碰到的问题。第二层是行为边界代理被允许执行哪些类别的操作。比如允许读文件、允许发送普通邮件、不允许删除任何线上存储路径。这一层对应的是 OpenClaw 的权限策略和技能白名单做的是允许做什么动作的问题。第三层是关键动作确认就算前两层都通过了某些特定操作仍然必须临时停下来征求人的意见。例如删除操作、批量写入生产库、对外发送高影响通知、修改基础设施配置。这层不关心代理权限有多大只关心这个动作一旦做错人能不能承受。requireApproval 插件处理的正是第三层。1.3 requireApproval 插件解决的恰好是第三层问题OpenClaw 的策略引擎里requireApproval 是一个驻留在技能执行前的钩子插件。它不直接干涉代理的推理过程而是在代理已经做出我要执行动作 X的决定之后、真正调用外部工具之前插入一个审批环节。这样做有一个很关键的收益审批只针对确定要发生的动作而不是针对模糊的意图。也就是说代理的推理照常进行任务拆解照常进行只有当它拿起工具准备动手的一瞬间审批机制才会介入。这种做法避免了每走一步都要问人的低效也把人工注意力集中在最高风险的动作上。v2026.3.28 版本里requireApproval 在架构上的定位更清晰了——它被抽象成了策略引擎里的一个标准插件接口开发者可以基于它编写自定义审批逻辑。自定义插件可以决定什么动作需要审批审批请求发给谁审批结果怎么回传给代理而核心插件只负责最通用的一条链路。我自己后来就在这个接口上写了一个小型审批面板接入效果比预期好得多。2. requireApproval 的工作方式请求、裁决、回执一个都不能少2.1 一次完整审批流的状态流转与时机理解了为什么需要它之后最该搞清楚的就是它到底怎么工作。这里我不打算肤浅地介绍功能列表而是完整走一遍请求的生命周期。在 v2026.3.28 里一条审批请求从产生到结束会经历这几种状态PENDING、APPROVED、REJECTED、EXPIRED、CANCELLED。代理准备执行一个命中审批规则的动作时OpenClaw 会立即暂停该动作生成一条审批请求状态置为 PENDING同时把请求推送给配置好的通知渠道。审批人收到消息后可以通过预设的按钮或接口做出 APPROVED 或 REJECTED 的裁决。如果超时没人处理请求会按配置进入 EXPIRED 流程如果代理任务因为其他原因被取消关联的审批请求也会被置为 CANCELLED。这里有一个实操中容易忽视的时机问题审批拦截发生在动作即将执行的瞬间而不是任务开始规划的瞬间。有同事问我为什么不在一开始解析出任务计划时就把所有需要审批的动作列出来我的经验是代理在真正执行前的每一步都可能根据环境反馈调整计划提前生成审批单很容易作废反而造成大量无效打扰。等到动作即将执行时再拦审批单的上下文是最准确的误判率也最低。2.2 审批上下文里必须打包的五个字段审批请求不只是发一条代理请求删除文件的消息那太粗暴了。我在 v2026.3.28 的文档里看到官方推荐的审批上下文模板包含五个核心字段缺一个都容易让审批人做出错误判断。第一个是操作者标识也就是 agent_identity。同一个 OpenClaw 实例上可能跑着多个不同职责的代理审批人必须知道是哪一个代理发来的请求。第二个是动作描述要求用结构化语言说明要做什么而不是只给一个工具名。比如调用对象存储删除接口删除临时目录下的过期备份文件就比执行 delete_object清晰得多。第三个是操作对象也就是影响的资源范围。这里最好带上具体的资源标识、数量、目录路径或数据库名。我自己的经验是把影响范围估算字段一起放进去会更有效比如预计影响 200 个对象均属于临时目录不涉及生产数据。第四个是触发规则也就是这条请求为什么被拦截。显示命中的规则 ID 和模式能让审批人快速判断是本就该人工确认的操作还是规则误伤。第五个是影响评估与回滚建议这是我自己实践后坚持追加的字段。一个合格的审批请求应该告诉人类审批者如果这个操作出了问题回滚方案是什么。没有回滚方案的操作即使批准了也要在记录里留下风险标记。2.3 回执机制审批结果如何回到代理手里很多第一次接 requireApproval 的人都会搞混一件事审批人点了批准不等于代理就自动继续执行。中间还需要一条回执链路把结果送回正在等待的代理进程。v2026.3.28 的回执机制走的是 OpenClaw 的内部事件总线。审批插件收到裁决后会生成一条回执事件事件里包含审批单号、裁决结果、裁决人、时间戳和备注信息。代理端的策略钩子会在暂停点等待这个事件拿到 APPROVED 后恢复动作执行拿到 REJECTED 后按照预先定义好的降级逻辑处理——通常是把该动作标记为跳过并在任务结果里明确记录该步骤被人工否决。这里我要特别提醒一个细节回执必须是幂等的。也就是说如果代理因为网络抖动没有及时收到事件重新拉起请求时不能导致审批动作被执行两次。我的做法是基于审批单号做幂等校验代理恢复执行前先检查该单号对应的执行状态已经处理过的直接复用结果。这个设计在长时间运行的批处理任务里救过我很多次。3. 审批策略不是开关而是一组可以调优的规则3.1 strict、moderate、smart 三种模式怎么选requireApproval 的配置核心是策略而不是一个全局开关。v2026.3.28 里内置了三种预设模式我把它理解成三种不同松紧度的阀门。strict 模式要求命中规则的动作每次都必须人工审批没有任何自动放行逻辑。它适合高影响、低频次的操作比如删库、批量修改权限、对外发布公告。moderate 模式会结合频率进行判断如果某个动作在一段时间内已经被批准过多次并且运行结果正常后续同类动作可以自动放行。smart 模式则更进一步它会参考该动作的历史审批率、任务类型、资源敏感度做一个综合打分分数低于阈值时才放行。我用一张表来总结三种模式的核心区别方便你直接对照选型模式适用场景自动放行条件人工介入频率推荐使用层strict删除操作、生产库写入、基础设施变更无每次必须审批高关键动作层moderate批量邮件、大文件迁移、数据转换相同动作在统计窗口内曾被连续批准 N 次且结果正常中常规风险层smart临时目录清理、测试数据生成、低危 API 调用综合风险评分低于动态阈值低低风险高频层不要试图给整个 OpenClaw 实例只套一种模式。我的建议是按动作维度去挂不同模式破坏性动作用 strict重复性高但有风险的动作用 moderate纯粹低危的哑操作用 smart。三种模式混配在一个策略文件里才能既守住风险又不至于把审批人累垮。3.2 白名单与频控让常用操作安静通过strict 模式最容易被吐槽的点就是人变成了代理的确认按钮。解决这个问题的思路不是降低风险标准而是把真正安全的动作从审批名单里摘出去。白名单机制允许你声明一组不需要审批的条件。比如某个代理只负责读取公共数据集它的所有只读操作可以直接在白名单里放行。又比如设定仅针对测试命名空间下的删除操作同一天内已批准超过 3 次后续不再触发审批。我在生产环境里通常会把代理对自身工作目录的读写放在白名单里因为这类操作的影响边界非常清晰出了问题也能低成本恢复。频控是另一个容易被忽略的维度。OpenClaw 的统计窗口默认按时间划分但我的经验是最好再加上连续成功次数的约束。比如一个数据清洗任务每晚运行前两周每次都成功那后续运行时的中间步骤就不需要反复审批但一旦某天出现了执行异常频控统计应当自动清零重新进入需要人工确认的状态。v2026.3.28 提供了自定义条件回调接口我就是在这一步做了成功则加权、失败则重置的逻辑。3.3 超时、熔断、升级审批链路必须考虑的三条退路审批机制设计得再好也架不住审批人正在开会或者晚上没有值班的人。所以我在任何项目里都坚持给审批链路配三条退路。第一条是超时策略。每条审批规则都可以单独设定超时时间超时后的默认动作建议设为否决并通知而不是自动批准。不要因为怕麻烦而设成超时自动通过那等于把审批机制架空了。第二条是升级路径。超时之后请求可以升级给更高层级的审批人或备用审批组升级策略需要提前配置好接收人。第三条是熔断机制。当某个集群里同时挂起的审批请求数量超过阈值说明代理可能进入了某种异常循环此时应当暂停该代理的新任务下发而不是让更多请求涌进来。这个阈值我用过 5 条超过了基本意味着任务规划出了问题。4. v2026.3.28 接入 requireApproval 的完整操作记录4.1 初始化插件与生成策略文件下面这段是我在一台干净的 OpenClaw 实例上从零接入 requireApproval 的操作过程按顺序记录你可以直接照着走。首先确认版本。在 shell 里执行 cla version确保运行的是 v2026.3.28 或更新的补丁版本。然后初始化插件cla policy add require-approval插件初始化后会出现两个东西一个是策略插件本身处于 enabled 状态另一个是生成了一份默认策略文件通常位于 ~/.openclaw/policies/approval.toml。建议先不改配置直接跑一次 cla policy list 确认插件已被加载cla policy list # 输出里应能看到 require-approval 插件以及它的默认规则组这个初始化的过程本质上是把插件注册到策略引擎的钩子链里也就是让技能执行前这个节点多出一道检查工序。如果你用了容器化部署记得把策略文件目录挂载到持久化存储不然后续改配置会因为容器重建而丢失。4.2 编写第一组审批规则的完整配置下面是我实际用过的一个配置片段包含三个不同模式的规则分别覆盖了删除对象存储文件批量写入线上库清理测试临时目录三类动作。文件格式是 TOMLv2026.3.28 的配置解析器对注释和数组的兼容性做得比老版本好很多。[[approval.rules]] id storage-delete-protect comment 删除对象存储内文件必须人工确认 match.action storage.delete_object match.resource * mode strict timeout 15m notify [ops-oncall, data-owner] [[approval.rules]] id db-prod-batch-write comment 批量写入生产库按频控放行 match.action db.execute_many match.resource prod* mode moderate statistics_window 24h auto_approve_after 3 auto_approve_reset_on_error true timeout 10m notify [db-owner] [[approval.rules]] id tmp-cleanup-smart comment 临时目录清理低风险自动通过 match.action storage.delete_object match.resource tmp/* mode smart risk_score_threshold 0.4 timeout 30m notify []配置完成后运行 cla policy reload 让策略生效。这里我要强调一个检查技巧reload 之后不要直接跑真实任务去验证先进入沙箱模式模拟一次命中规则的动作确认审批请求能正确生成。沙箱验证通过后再切到真实环境这个习惯帮我避开了至少三次配置半天却发现规则根本没生效的尴尬。4.3 对接通知渠道把审批请求送到对的人手里v2026.3.28 的 requireApproval 通知层支持邮件、通用 webhook以及企业微信、钉钉这类聊天工具的 webhook 机器人。官方插件默认读取配置里的 notify 字段向对应渠道发送一条带审批动作按钮的卡片消息。我建议优先使用 webhook 方式因为聊天工具里的按钮交互对审批人最友好。配置方式是在 OpenClaw 的配置中心里添加一个通知目标然后在规则里引用[notification.webhook] name team-bot url https://example.internal/hooks/openclaw-approval method POST headers { X-Token your-secret-token }如果你所在的团队有内部审批平台也可以禁用内置通知改用自定义处理器接收审批事件。下面是一个极简的 HTTP 回调处理示意用 Python 写成实现的功能是接收到审批事件后写入企业内部的待办表from flask import Flask, request, jsonify app Flask(__name__) app.route(/hooks/openclaw-approval, methods[POST]) def receive_approval(): event request.json approval_id event[approval_id] action event[action][description] resource event[action][resource] # 写入待办表状态初始为 pending insert_todo(approval_id, action, resource) return jsonify({ok: True}) if __name__ __main__: app.run(port8899)审批人处理完待办后需要将结果回传给 OpenClaw。最简单的做法是在企业内部页面调用 OpenClaw 提供的裁决接口传入 approval_id 和 verdict。这里提醒一句回调接口务必设置访问鉴权不要暴露在公网。审批接口一旦被滥用等于给攻击者一个批量否决你所有自动化任务的入口。5. 我在真实项目里踩过的审批流九个坑5.1 只开 strict 模式把人变成了人工确认按钮我见过最多的错误配置是把所有命中规则的动作全部设为 strict。结果就是每天数百条审批请求审批人从早上点到晚上点到最后已经分不清自己在批什么纯粹靠惯性操作。这种状态下的人工审批质量比不审批还差。后来的调整思路是给低频高险动作保留 strict把常规重复性动作挪到 moderate再给真正无害的动作挂白名单。审批量的下降幅度非常明显日均请求从两百条降到了二十条左右而真正需要人判断的高危操作一个也没漏。5.2 审批超时设了 30 秒凌晨任务集体失败有过一次把超时时间压得太短的经历。当时图效率所有规则的 timeout 都配成了 30 秒本意是不想让代理卡太久。结果夜间有值班同事没注意到通知审批人迟迟不点凌晨任务一批接一批地 EXPIRED。更糟的是有些任务没写降级逻辑EXPIRED 之后直接重试重试又产生新的审批请求形成恶性循环。后来我把工作时间内的规则设为 10 分钟夜间规则统一设为 2 小时并配了升级组。不要和审批人的响应节奏对着干超时设置要贴合人的习惯而不是机器的习惯。5.3 上下文太长被截断审批人看不到关键信息就点了批准这个坑非常隐蔽。我在早期没有限制审批上下文长度动作描述里塞了一长串 SQL 和错误堆栈结果发送到聊天工具时被截断成几段。审批人看到的只有代理请求执行如下操作……后面全是省略号他凭感觉点了同意。后来我把上下文模板改成五字段摘要 折叠详情的方式关键信息永远在最前面详情内容需要展开才能看到。这里强烈建议不要偷懒自定义一个摘要模板把操作对象、影响范围、回滚建议放在最显眼的位置。5.4 回执丢失代理傻等一个小时还有一次问题是回执事件在内部总线上丢了。代理等待事件时设置了 60 秒超时超时后因为代码里没有写重试逻辑整个任务挂起了一个小时才被监控发现。给所有等待审批结果的代理加上轮询和幂等处理是所有接 requireApproval 的项目都必须做的功课。我现在的做法是代理每 15 秒检查一次审批状态最多检查 40 次之后自动放弃并上报异常。这样既不会疯狂占用系统资源也能在合理时间内给上层一个明确的结果。5.5 剩下五个容易忽略的坑除了上面四个还有五个我认为值得记下来的小坑一是多审批人并行操作同一个审批单导致状态覆盖、后提交的裁决覆盖先提交的二是冷却期缺失同一个任务反复触发审批打扰审批人多次三是审计日志没有定期导出等要做季度复盘时发现原始数据已经被滚动清理四是从 smart 切到 strict 时没有提前通知团队审批人手中积压了大量旧请求五是忽略审批人身份管理用共享账号审批导致出了事故追查不到具体责任人。这些坑大多不是 requireApproval 本身的问题而是接入时工程细节没有做到位。6. 审批数据是治理资产复盘、调优与规模化放权6.1 从审批日志里能读出的隐藏信号一旦把审批流稳定跑起来OpenClaw 的策略引擎就开始沉淀大量审计数据。这些数据不只是用来出事了翻记录它是后续放权决策的核心依据。我最关注的四个指标是误拒绝率、漏批准率、审批响应时延、按小时维度的请求分布。误拒绝率指的是那些被规则或审批人否决、但事后证明是安全且必要的操作占比这个指标高了说明策略太激进。漏批准率则相反指的是被放行但后来出问题的操作占比它比误拒绝更危险需要用事后回滚记录来反推。审批响应时延主要影响用户体验P95 超过 15 分钟就要考虑增加审批人或调整升级策略。按小时维度的请求分布常常透露意外信息。我统计后发现凌晨两点的审批请求中有相当一部分是历史遗留任务的存量操作并不真的紧急完全可以通过把规则调成 moderate 配合频控来减少人工介入。把数据可视化出来之后很多感觉哪里不对的问题都能变成明确的指标。6.2 用数据把模式从 smart 平滑过渡到白名单我的最终目标从来不是让审批一直存在而是让系统在足够安全的条件下学会放权。这里说的放权不是直接删掉规则而是用数据支持逐步调整。举个例子某条清理临时目录的规则在 smart 模式下运行了一个月累计触发 500 次人工介入率只有 2%且没有任何一次操作引发异常回滚。那么我可以把这条规则从 smart 升级为 moderate把 auto_approve_after 设为 5再过一个月如果数据依然平稳再进一步把这批资源纳入白名单。每一步都有历史数据背书即使出了问题也能精确回溯到是哪一步放权引入的回滚也只是改一行配置的事。调优时要小步快跑不要一次性改几十条规则。我通常一次只调整两到三条相关规则观察至少一周的审批日志确认没有异常波动后再进入下一轮。这种节奏虽然慢但每一轮放权都是可解释、可回退、可交接的。6.3 我目前在用的推荐配置模板说了这么多理论最后给你一份我目前在 v2026.3.28 上实际运行的参考配置。这套配置的整体思路是高危必批、中危频控、低危放行、异常熔断# 全局默认模式谨慎兜底 default_mode strict [[approval.rules]] id infra-change-protect match.action infra.* match.resource * mode strict timeout 15m notify [infra-owner, ops-oncall] [[approval.rules]] id storage-delete-protect match.action storage.delete_object match.resource * mode strict timeout 15m notify [data-owner] [[approval.rules]] id data-pipeline-moderate match.action db.execute_many match.resource prod* mode moderate statistics_window 24h auto_approve_after 3 auto_approve_reset_on_error true timeout 10m notify [db-owner] [[approval.rules]] id tmp-lowrisk-smart match.action * match.resource tmp/* mode smart risk_score_threshold 0.4 timeout 30m notify [] [approval.circuit_breaker] max_pending 5 pause_new_jobs true alert_channel ops-oncall [approval.escalation] after_timeout true escalate_to [engineering-lead]这套配置并不是什么标准答案但它是我经历过十几个项目之后沉淀出来的一个稳妥起点。你完全可以根据自己团队的职责划分和风险偏好去调整 notify 和超时参数。7. 最后再分享一点我的操作体会接 requireApproval 这件事最难的部分其实不是理解它的状态机也不是写几段 TOML 配置而是想清楚该把审批的粒度放在哪一层。粒度太粗审批单里混杂着大量无关信息审批人很难判断粒度太细代理每走一步都要停下来等人自动化的价值就打了折扣。我的经验是从动作类型和资源范围两个维度去切粒度动作越危险、资源越核心审批粒度就越细反过来低危资源和常规操作就尽量合并到白名单或频控逻辑里让审批人把精力省给真正需要人的时刻。另一个让我反复触动的体会是审批不只是流程控制它其实是系统在向人学习。每一次 APPROVED 和 REJECTED 都是在告诉策略引擎这一类动作在我的团队里被如何看待。如果团队没有人愿意认真对待审批请求那不管模式配得多智能这个回路仍然是空的。所以别把 requireApproval 当成一个丢给机器就完事的插件——它真正的运行环境是人和代理之间相互建立信任的那个过程。如果你正准备把 OpenClaw 接入团队生产环境我建议你从最小范围开始挑一条你夜里最睡不着的自动化任务给它挂上 strict 模式的审批规则跑一个月看看数据和团队感受再决定下一步放权到哪。相信我那种代理在动手前会先问你一句的感觉比任何仪表盘都能给你安全感。