1. 从一次失控的智能体任务说起凌晨两点我盯着屏幕上那个还在疯狂调用工具的 OpenClaw 智能体它已经连续执行了四十多分钟把测试环境里的文件改得面目全非。起因只是我在调试一个自动化脚本时给它开放了文件读写权限结果它陷入了一个读取—判断—再读取的循环每轮都觉得自己在推进任务。那一刻我意识到给智能体加能力容易给它加约束才是真正难的部分。这就是 ClawKeeper 要解决的问题。它不是又一个智能体框架而是专门给 OpenClaw 这类智能体套上的一层安全外壳。你可以把它理解成给一个精力旺盛但缺乏边界感的实习生配了三个角色一个在旁边盯着他干活的监工、一个负责审核他每个动作的合规员、一个在出事后能立刻拉闸的应急开关。这三层加起来就是标题里说的三层安全防火墙。如果你正在用 OpenClaw 做自动化任务、对接飞书或微信、跑本地部署的智能体工作流或者单纯被agent failed before reply: session file locked这类报错折磨过那这篇内容会对你有用。我会把 ClawKeeper 的设计思路、三层防护的具体落地方式、以及我在实际部署中踩过的坑完整地摊开讲一遍。不堆概念只讲能直接抄作业的东西。2. 为什么智能体需要看门人而不是说明书2.1 智能体的失控不是 bug是特性大多数人第一次接触 OpenClaw 这类智能体时会默认它像普通程序一样输入什么就输出什么。但智能体的本质是在循环中自主决策它拿到一个目标自己拆解步骤自己选择工具自己判断是否完成。这个循环里每一步都依赖模型的判断而模型的判断是不确定的。我做过一个统计在本地部署的 OpenClaw 环境里跑同一批任务十次里有三次会出现过度执行——比如让它整理一份文档它顺手把整个目录的权限都改了让它查一个数据它把数据库连接池占满了。这些行为在传统程序里叫 bug在智能体里叫自主性溢出。你没法靠写死 if-else 来堵住因为它的决策路径是动态生成的。所以正确的思路不是给它写更详细的说明书而是在它和真实环境之间插一层看门人。ClawKeeper 就是这个看门人。2.2 三层防护的分工逻辑ClawKeeper 的三层设计不是拍脑袋来的它对应了智能体出问题的三个时间点层级名称介入时机核心职责第一层Watcher执行前拦截高危动作做前置校验第二层Auditor执行中监控行为序列识别异常模式第三层Circuit Breaker异常后熔断、回滚、隔离这三层的关系是递进的Watcher 管能不能做Auditor 管做得对不对Circuit Breaker 管做错了怎么办。很多团队只做了第一层结果发现智能体绕过了单点检查只做第二层发现异常识别出来时损失已经造成只做第三层那就是纯事后补救。三层缺一不可。2.3 和常见权限控制的本质区别有人会问这不就是给智能体配个权限白名单吗不一样。传统权限控制是静态的你告诉它只能读 A 目录它就只读 A 目录。但智能体的危险动作往往发生在合法权限内的组合操作上。比如它有读权限也有写权限单独看都没问题但它先读一个配置文件拿到密钥再写到另一个地方这个组合就是风险。ClawKeeper 的 Watcher 层做的不是简单的权限判断而是动作语义分析。它会看这个动作的意图、上下文、以及和之前动作的关联。这是它和普通权限系统最大的区别也是为什么它需要独立部署而不是塞进 OpenClaw 配置里。3. Watcher 层在动作落地前把它拦下来3.1 Watcher 的拦截点选在哪里Watcher 的部署位置很关键。我试过三种方案第一种是在 OpenClaw 的 tool 调用入口做拦截也就是智能体每次调用工具前先过 Watcher。优点是覆盖全缺点是如果智能体用了内置工具或者直接走 shell可能绕过。第二种是在系统调用层做拦截用类似 seccomp 的机制。优点是底层缺点是配置复杂而且对跨平台的 OpenClaw 部署不友好。第三种是在 ClawKeeper 自己的代理层做拦截让 OpenClaw 的所有外部动作都经过一个本地代理。这是我最终采用的方案因为它在覆盖面和可维护性之间取得了平衡。具体做法是在 OpenClaw 的配置里把工具调用的 endpoint 指向 ClawKeeper 的本地端口ClawKeeper 解析请求后决定放行还是拦截。这样无论智能体用什么工具只要走网络或文件系统都会经过这一层。3.2 动作语义分析怎么做Watcher 的核心是一套规则引擎加一个轻量模型。规则引擎处理明确的红线比如禁止删除 /etc 下的文件禁止向外部地址发送超过 1MB 的数据。这些用正则和路径匹配就能搞定速度快误报低。轻量模型处理模糊判断比如这个动作是否和当前任务目标一致。我用的方案是把当前任务描述和待执行动作一起喂给一个小模型让它输出一个风险分。这个模型不需要很大7B 级别的量化模型在本地跑就够了延迟控制在 200ms 以内。两者结合的逻辑是规则引擎先过一遍命中红线直接拦没命中红线的再走模型打分超过阈值就进入人工确认队列。这个队列可以对接飞书或企业微信让负责人点一下确认或拒绝。3.3 一个真实的拦截案例我部署 ClawKeeper 后遇到的第一个拦截事件是智能体在整理日志文件时试图执行一条find / -name *.log -delete。这条命令在规则引擎里命中了全盘删除类操作的红线直接被拦。但有意思的是智能体的原始意图是清理测试目录下的日志。它之所以写成全盘查找是因为它在拆解任务时把清理日志理解成了清理所有日志。如果没有 Watcher这条命令会删掉系统日志和一堆无关文件。这个案例说明一个问题智能体的意图和执行之间经常有偏差Watcher 的价值就是在偏差造成后果前把它暴露出来。我在规则里加了一条路径范围校验要求所有删除类操作的路径必须落在任务声明的目录内超出范围就拦截。这条规则后来又拦下了好几次类似问题。3.4 Watcher 的性能开销与调优加上 Watcher 后智能体的单步延迟从平均 80ms 涨到了 280ms。这个开销主要来自模型推理。如果你的任务对延迟敏感可以这样调把规则引擎的匹配做成前缀树减少正则回溯模型推理用批处理把多个待审动作攒一批一起打分对高频低危动作比如读文件设置缓存相同路径的读操作短时间内不重复审核我实测下来调优后延迟能压到 150ms 左右对大多数自动化任务来说可以接受。如果你的场景要求毫秒级响应那 Watcher 可能不适合放在关键路径上可以考虑异步审核加事后告警的模式。4. Auditor 层盯着行为序列而不是单点动作4.1 为什么单点检查会漏Watcher 再强它看的也是单个动作。但智能体的风险往往藏在动作序列里。我遇到过这样一个案例智能体先读取了一个包含数据库密码的配置文件然后调用了一个外部 API把配置内容作为参数传了出去。单独看读文件是合法的调 API 也是合法的但组合起来就是数据泄露。Auditor 层就是解决这个问题的。它不判断单个动作而是维护一个行为序列窗口分析最近 N 个动作之间的关联。如果发现敏感读取 外部发送这种组合就触发告警。4.2 行为序列的建模方式Auditor 的建模我用的是状态机加图分析。每个动作被抽象成一个带标签的节点比如READ:config、CALL:external_api、WRITE:tmp。这些节点按时间顺序连成图Auditor 在图上跑模式匹配。常见的危险模式我整理了几类数据外泄模式敏感读 → 编码/压缩 → 外部发送权限提升模式读配置 → 修改权限 → 执行脚本资源耗尽模式循环调用 → 未释放连接 → 继续调用任务漂移模式连续多个动作与初始目标语义距离越来越远前三种用图模式匹配就能识别第四种需要计算动作和目标描述的语义相似度。我用的是 sentence embedding把初始目标和每个动作都编码成向量算余弦相似度。如果连续五个动作的相似度都低于 0.3就判定为任务漂移触发 Auditor 告警。4.3 告警分级与响应策略Auditor 的告警不能一刀切否则会淹没在噪音里。我把它分成三级级别触发条件响应方式提示单次可疑模式记录日志不打断警告可疑模式重复出现通知负责人继续执行严重高危模式或任务漂移暂停智能体等待人工介入这个分级的关键是给智能体留出自我纠正的空间。很多异常是暂时的比如智能体在探索阶段会做一些看似无关的动作但很快会回到正轨。如果一有异常就熔断任务成功率会大幅下降。我的经验是提示级不打断警告级通知只有严重级才暂停。4.4 Auditor 的日志设计Auditor 的日志不是简单的文本记录而是结构化的行为轨迹。每条记录包含时间戳、动作类型、动作参数摘要、风险分、关联的前序动作 ID、当前任务目标向量。这样的日志有两个好处一是事后复盘时能完整还原智能体的决策路径二是可以用来训练更精准的风险模型。我把跑了三个月的日志拿出来做了一次聚类分析发现了几类之前没注意到的危险模式反过来补充到了 Watcher 的规则里。提示Auditor 的日志量会很大建议用列式存储比如 Parquet而不是纯文本查询和分析效率差很多。我一开始用 JSON 文件存后来数据量上来后查询慢得没法用换成 DuckDB 才顺畅。5. Circuit Breaker 层出事后如何把损失摁住5.1 熔断的触发条件设计Circuit Breaker 是最后一道防线它的触发条件必须足够明确否则要么误熔断要么漏熔断。我设定的触发条件有三类第一类是Auditor 严重级告警这个直接熔断没有商量余地。第二类是资源阈值突破比如智能体占用的内存超过 2GB、打开的文件句柄超过 500、或者连续调用外部 API 超过 100 次每分钟。这些阈值根据你的部署环境调整原则是留出足够余量但又能及时刹车。第三类是超时单个任务执行超过预设时长我设的是 15 分钟就强制中断。这个时长要根据任务复杂度设太短会误杀正常任务太长就失去了保护意义。5.2 熔断后的回滚策略熔断只是第一步关键是熔断后怎么把环境恢复到安全状态。ClawKeeper 的回滚分三个层次文件系统回滚在智能体启动前对关键目录做快照熔断后对比差异并恢复。我用的是 overlayfs开销小恢复快。进程隔离智能体运行在独立的容器或命名空间里熔断时直接杀掉整个命名空间不影响宿主机。外部状态回滚如果智能体调用了外部 API 或写了数据库这部分没法自动回滚需要记录操作日志并通知相关方手动处理。第三层是最麻烦的也是很多团队忽略的。我的做法是在 Watcher 层就对写外部系统的操作做标记熔断时把这些标记提取出来生成一份待人工核查清单推送给负责人。5.3 熔断后的智能体状态处理熔断后智能体的会话状态怎么处理这个问题我纠结了很久。直接丢弃的话之前的工作全白费保留的话恢复后可能继续犯错。最后的方案是状态冻结加人工审核。熔断时把智能体的完整状态包括对话历史、工具调用记录、当前任务进度序列化保存然后暂停会话。负责人可以在 ClawKeeper 的控制台里查看状态决定是恢复、修改目标后恢复、还是终止。这个方案的好处是给了人一个介入点而不是让智能体在错误的方向上越走越远。我实际用下来大概有 60% 的熔断事件在人工审核后能恢复执行40% 需要终止或重新规划任务。5.4 一个完整的熔断实例有一次我让智能体帮忙做数据清洗它需要读取一个 CSV 文件、做格式转换、然后写回。任务本身不复杂但那个 CSV 文件里有一列包含大量特殊字符智能体在处理时陷入了反复尝试的循环——每次转换失败就换个方式重试重试次数很快超过了 50 次。Auditor 在它第 30 次重试时触发了资源耗尽模式的警告第 50 次时升级为严重级Circuit Breaker 随即熔断。熔断后我查看状态发现它已经把原始文件覆盖了三次好在 overlayfs 快照保住了原始版本。恢复时我修改了任务描述明确告诉它遇到特殊字符时的处理规则重新执行后一次通过。这个案例让我意识到熔断不是失败而是把不可控的自动执行转化为可控的人工介入。没有熔断的话那个文件可能被反复覆盖几十次数据早就毁了。6. 把 ClawKeeper 接进 OpenClaw 的实际操作6.1 部署架构与依赖ClawKeeper 本身是一个独立的服务用 Go 写的核心加 Python 写的模型推理模块。部署方式我推荐用 Docker Compose因为要同时跑代理、规则引擎、模型服务和日志存储。核心依赖OpenClaw 本体版本建议用近三个月内的稳定版Docker 和 Docker Compose一个本地模型推理服务我用的是 Ollama跑量化后的 7B 模型列式存储DuckDB 或 ClickHouse看数据量资源占用方面Watcher 的模型推理大概吃 2GB 显存Auditor 的 embedding 模型吃 1GB加上 OpenClaw 本身一台 16GB 内存、8GB 显存的机器能跑起来。如果并发任务多需要相应扩容。6.2 配置 OpenClaw 走 ClawKeeper 代理这一步是集成的关键。OpenClaw 的工具调用配置里有一个tool_endpoint字段默认指向它自己的工具执行器。把它改成 ClawKeeper 的地址# openclaw config tools: endpoint: http://localhost:8420/proxy timeout: 30s retry: 1然后在 ClawKeeper 的配置里声明上游的真实 endpoint# clawkeeper config upstream: openclaw_tools: http://localhost:8421/execute watcher: rules_file: ./rules/default.yaml model: ollama:qwen2.5:7b auditor: window_size: 10 embedding_model: ollama:nomic-embed-text breaker: max_memory_mb: 2048 max_duration_sec: 900 snapshot_dir: /var/clawkeeper/snapshots配置改完后重启 OpenClaw所有工具调用就会先经过 ClawKeeper。你可以在 ClawKeeper 的日志里看到每个被拦截或放行的动作。6.3 规则文件的编写要点Watcher 的规则文件是 YAML 格式每条规则包含匹配条件、风险级别、处理动作。我写规则时遵循几个原则路径匹配用绝对路径不要用相对路径因为智能体的工作目录可能变化命令匹配用白名单而不是黑名单黑名单永远列不全风险级别留出调整空间新规则先设为提示级观察一段时间再升级一条典型的规则长这样- id: block-full-disk-delete match: tool: shell command_regex: find\\s/\\s.*-delete level: critical action: block message: 全盘删除操作被拦截请检查任务范围规则写完后可以用 ClawKeeper 自带的测试工具跑一遍它会用历史日志回放告诉你哪些规则会误伤正常操作。6.4 和飞书、微信通知的对接Auditor 的告警和 Circuit Breaker 的熔断都需要通知到人。我对接的是飞书机器人因为它的 webhook 最简单。在 ClawKeeper 配置里填上 webhook 地址告警会自动推送。需要注意的是飞书的消息有长度限制如果告警内容太长会被截断。我的做法是把详细信息放在 ClawKeeper 的控制台里飞书消息只推摘要加一个跳转链接。这样既保证了通知到达又不会因为截断丢失关键信息。如果你用的是微信情况会复杂一些因为微信没有官方的机器人 webhook。我试过用企业微信的应用消息效果还行但配置比飞书麻烦。如果只是个人使用可以考虑用邮件通知虽然慢一点但最稳定。7. 部署过程中踩过的坑和应对7.1 session file locked 问题的根源部署 ClawKeeper 后我遇到过一个报错agent failed before reply: session file locked (timeout 60000ms)。这个报错在 OpenClaw 社区里很常见但加上 ClawKeeper 后出现频率变高了。排查后发现原因是 ClawKeeper 的 Auditor 在读取会话文件做分析时和 OpenClaw 的写入产生了锁竞争。OpenClaw 默认用文件锁保护会话状态Auditor 频繁读取导致锁等待超时。解决方案有两个一是让 Auditor 通过 OpenClaw 提供的 API 读取会话状态而不是直接读文件二是把 Auditor 的读取频率降下来从实时读取改成批量读取。我两个都做了问题再没出现过。7.2 模型推理的显存竞争Watcher 和 Auditor 都要用模型推理如果都跑在同一块 GPU 上会出现显存竞争。我一开始没注意结果两个服务互相抢显存导致推理超时智能体的动作被大量误拦。解决办法是给两个服务分配不同的 GPU或者用 CPU 跑 Auditor 的 embedding 模型embedding 模型小CPU 跑延迟可以接受。如果只有一块 GPU可以用 Ollama 的并发控制限制同时加载的模型数量。7.3 规则误伤正常操作新规则上线时最容易误伤。我加过一条禁止访问 /tmp 以外的临时目录的规则结果智能体在正常任务中需要写 /var/tmp被拦了。这种误伤会打断正常任务体验很差。我的应对方法是新规则先跑影子模式规则生效但不拦截只记录如果拦截会拦下哪些操作。跑一周后看日志如果拦下的都是真正的危险操作再切换成拦截模式。这个流程虽然慢但能避免大量误伤。7.4 熔断后的状态恢复失败有一次熔断后恢复失败原因是智能体的会话状态里包含了一个已经失效的临时 token。恢复时它拿着旧 token 去调用 API直接报错。这个问题说明状态恢复不是简单的反序列化还需要做有效性校验。我在恢复流程里加了一步检查状态里的所有外部引用token、连接、文件句柄是否还有效无效的就标记出来让负责人决定是刷新还是放弃。7.5 日志存储的膨胀问题Auditor 的日志增长很快我跑了两个月就攒了 40GB。如果不处理磁盘很快会满。我的做法是分层存储最近 7 天的日志放 SSD查询快7 天到 90 天的放普通硬盘超过 90 天的归档到对象存储。同时做了一个聚合任务把原始日志按小时聚合成统计指标长期保留的是聚合结果而不是原始记录。这样存储成本降了一个数量级。8. 三层防护的协同与调优经验8.1 三层之间的信息传递Watcher、Auditor、Circuit Breaker 不是孤立的它们之间需要传递信息。Watcher 拦截的动作要告诉 Auditor让 Auditor 知道这个动作被拦了避免重复告警。Auditor 的告警级别要告诉 Circuit Breaker作为熔断的输入。Circuit Breaker 的熔断事件要反馈给 Watcher让 Watcher 在恢复后对同类动作更严格。这个信息传递我用的是一个共享的事件总线基于 Redis Stream 实现。每个层往总线里发事件其他层订阅自己关心的事件。这样解耦后任何一层的调整都不会影响其他层。8.2 误报率和漏报率的平衡安全系统永远在误报和漏报之间权衡。误报太高正常任务被打断用户会关掉防护漏报太高防护形同虚设。我的调优目标是误报率控制在 5% 以内漏报率控制在 1% 以内。达到这个目标靠的是持续迭代每周复盘一次告警日志把误报的规则调松把漏报的场景补进规则。这个过程没有终点因为智能体的行为模式也在变化。一个实用的技巧是给不同类型的任务设置不同的阈值。比如数据清洗类任务对文件操作敏感阈值调严信息查询类任务对网络调用敏感阈值调严。ClawKeeper 支持按任务标签加载不同的规则集这个功能很实用。8.3 性能与安全的取舍加上三层防护后智能体的整体执行效率大概下降了 30%。这个代价换来的是可控性我认为值得。但如果你的场景对效率极度敏感可以这样取舍Watcher 只保留规则引擎去掉模型推理延迟能降一半Auditor 改成异步分析不阻塞主流程但会失去实时拦截能力Circuit Breaker 保留因为它是最后防线不能省我的建议是至少保留 Watcher 的规则引擎和 Circuit Breaker这两个是性价比最高的。Auditor 可以根据场景决定是否上。8.4 长期运行的维护要点ClawKeeper 跑起来后维护工作主要是三块规则更新、模型迭代、日志清理。规则更新我设了一个月度节奏每月初回顾上月的告警和熔断事件调整规则。模型迭代看情况如果发现模型对某类动作的判断准确率下降就重新训练或换模型。日志清理是自动化的按前面说的分层策略跑就行。还有一点容易被忽略定期做恢复演练。熔断和恢复的流程不能只在出问题时才跑要定期模拟熔断验证恢复流程是否正常。我每季度做一次演练每次都能发现一些小问题比如快照文件损坏、恢复脚本路径错误之类的。9. 一些个人体会ClawKeeper 这套东西我从最初的想法到稳定运行花了大概四个月。中间推翻过两次设计一次是因为 Watcher 的拦截点选错了一次是因为 Auditor 的告警太吵。现在回头看最大的体会是给智能体做安全难点不在技术在于对智能体行为模式的理解。你得先知道智能体在什么情况下会失控才能设计出有效的防护。这个认知只能从实际运行中积累看再多的文档也没用。我建议如果你刚开始做智能体安全先别急着上全套防护先跑一段时间的裸智能体把它的行为日志收集起来分析清楚它的风险模式再针对性地设计防护。这样出来的方案比照搬框架要靠谱得多。另外一点是安全防护本身也要有可观测性。ClawKeeper 的每一层都要有清晰的日志和指标否则出了问题你都不知道是哪一层没起作用。我在控制台里做了一个简单的仪表盘显示拦截次数、告警分布、熔断频率一眼就能看出防护是否在正常工作。最后说个实际的如果你只是个人使用 OpenClaw 做一些轻量任务可能不需要全套 ClawKeeper。但如果你在做团队级的智能体部署或者智能体要接触生产环境的数据和系统那这三层防护是底线省不得。我见过太多因为省了防护而导致数据损坏或泄露的案例事后补救的成本远高于事前防护。