OpenClaw生产级部署指南：权限隔离、流量管控、用量追踪全方案

前言

这篇我把自己踩了N个坑总结的OpenClaw安全管控方案全分享：容器化部署隔离权限、IP白名单控制面板访问、token用量告警、行为日志全追溯，所有配置代码直接复制就能用，自托管玩家必看！

权限问题

1）openclaw可以修改主机上的文件，拿笔者的环境来说，一台debian 13的操作系统上安装的openclaw，安装完成之后它可以随意修改操作系统的文件：

要是别有用心之人能与openclaw对话，直接给你来个 rm -rf /*

2）可以修改自己的配置文件

配置文件也只不过是操作系统上的一个普通文件而已

3）重启某些服务

该服务并不是systemctl托管的，它自己去ps去查找相关信息，并且完成了重启

迁移至容器

刚才的演示中，已经暴露了openclaw的权限问题，如果不加以控制，那openclaw有可能成为潜在的风险，损害电脑上的重要资料

那怎么解决这个问题呢？将openclaw限制在容器当中，可执行的命令、可以修改的文件都受到了限制

将本机的~/.openclaw，全部复制到新的路径，为docker启动作为数据目录，也是将原有的配置全部迁移到docker中
bash 复制代码
```
cp -rf ~/.openclaw /data/openclaw_docker
```

docker启动脚本

bash 复制代码

docker run --name openclaw \
  -p 18789:18789 \
  -u 1000:1000 \
  -v ./openclaw_docker:/home/node/.openclaw \
  ghcr.io/openclaw/openclaw:latest

迁移完成之后验证
bash 复制代码
```
docker exec -it openclaw openclaw tui
```
修改web访问
bash 复制代码
```
> cat openclaw.json | jq '.gateway.bind'
"lan" # 原为localhost
```
改了之后要小心了，整个lan都可以访问gateway页面，还是很危险的

明确指定哪些地址可以访问 Web 控制台。这提供了最好的安全性

bash 复制代码

  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "lan",
    "controlUi": {
      "allowedOrigins": [
        "http://localhost:18789",
        "http://127.0.0.1:18789"
      ]
    },
    ...
  }

笔者配置了只允许127.0.0.1来访问gateway页面

token限制

多模型接入之后，最容易踩的坑就是token超量，笔者之前开着verbose模式跑了个文档梳理任务，一晚上刷了几十万token，账单直接起飞，所以一定要加限制。

1）会话级token上限

防止单次对话无限生成、或者反复调用工具刷token，直接在配置里加会话token阈值：

json5 复制代码

{
  "agents": {
    "defaults": {
      "compaction": {
        "reserveTokensFloor": 20000, // 上下文窗口剩余20k token时自动压缩
        "maxSessionTokens": 100000 // 单个会话最多累计10万token，超过自动重置
      }
    }
  }
}

超过阈值之后会话会自动触发压缩，或者直接重置，避免无限累加。

2）单模型每日配额限制

如果你用的是收费模型，可以给每个模型加单日最大token限制，超了自动切到备用模型：

json5 复制代码

{
  "models": {
    "providers": {
      "litellm": {
        "api": "openai-completions",
        "baseUrl": "http://localhost:4000/v1",
        "apiKey": "xxx",
        "maxTokensPerDay": 500000, // 单日最多用50万token
        "fallbackModel": "litellm/qwen-plus" // 超量自动切到通义千问
      }
    }
  }
}

笔者亲测这个配置救了好多次，再也不用担心跑任务跑超支了。

3）litellm跟踪token

如果是通过litellm来管理大模型key，那使用litellm来跟踪token是最好的

首先是观察整体的token消耗，以及不同模型的情况
其次是查看每一次会话的token消耗

跟踪openclaw行为

可以查看~/.openclaw/agents/<id>/sessions/*.jsonl日志，Agent 做了什么？调了哪些工具？传了什么参数？都可以在该文件中找到。

笔者习惯加个定时任务，每天把日志导出一份到备份目录，万一出了问题直接回溯，连操作时间点都对得上，非常方便。

缩减memory，避免过度联想

记忆多了也有副作用：笔者之前遇到过，给A项目配置的服务器地址，过了半个月问B项目的配置，助手直接把A项目的地址搬出来了，还说得有鼻子有眼，差点踩了线上事故。就是因为记忆库里的内容太多，语义检索的时候把相关的内容都拉出来了，导致回答串了。

所以一定要限制记忆的范围，避免过度联想：

1）限制自动加载的记忆天数

默认启动会加载今天+昨天的记忆，可以改成只加载今天的，或者完全不自动加载历史记忆：

json5 复制代码

{
  "agents": {
    "defaults": {
      "memory": {
        "loadRecentDays": 1 // 只加载当天的记忆，历史记忆需要手动查询
      }
    }
  }
}

如果你的场景不需要长期记忆，直接设成0，启动完全不加载历史记录，最清爽。

2）关闭会话历史索引

默认记忆搜索会把所有历史会话记录都索引进去，不想让旧会话的内容被检索到，可以关闭：

json5 复制代码

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "sources": ["memory"] // 只索引MEMORY.md和memory/下的文件，不索引会话日志
      }
    }
  }
}

改完之后只有你手动写到记忆文件里的内容才会被检索，会话里的临时内容不会进索引，避免串扰。

3）定期清理过期记忆

写个脚本定时删除超过30天的记忆文件，还有清理向量索引：

bash 复制代码

#!/bin/bash
# 清理30天以上的记忆
find ~/.openclaw/workspace/memory/ -name "*.md" -mtime +30 -delete
# 重建向量索引
sqlite3 ~/.openclaw/memory/main.sqlite "VACUUM;"

加个cron每周跑一次，记忆库永远都是最新的内容，不会有陈年旧料出来捣乱。

4）按项目拆分记忆

不同项目的记忆不要都堆在根MEMORY.md里，新建子目录拆分：

复制代码

memory/
├── project-a/
│   └── config.md
├── project-b/
│   └── config.md
└── 2026-03-17.md

查询的时候指定路径，就不会把两个项目的配置搞混了。

联系我

联系我，做深入的交流

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...