OpenClaw生产级部署指南：权限隔离、流量管控、用量追踪全方案
<h2 id="前言">前言</h2><p>这篇我把自己踩了N个坑总结的OpenClaw安全管控方案全分享： 容器化部署隔离权限、IP白名单控制面板访问、token用量告警、 行为日志全追溯，所有配置代码直接复制就能用，自托管玩家必看！</p>
<h2 id="权限问题">权限问题</h2>
<p>1）openclaw可以修改主机上的文件，拿笔者的环境来说，一台debian 13的操作系统上安装的openclaw，安装完成之后它可以随意修改操作系统的文件：</p>
<p><img alt="watermarked-openclaw_management_2" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101551564-991033977.jpg" class="lazyload"></p>
<p><img alt="watermarked-openclaw_management_1" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101558313-324858601.jpg" class="lazyload"></p>
<p>要是别有用心之人能与openclaw对话，直接给你来个 <code>rm -rf /*</code></p>
<p>2）可以修改自己的配置文件</p>
<p><img alt="watermarked-openclaw_management_4" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101606042-1342237965.jpg" class="lazyload"></p>
<p><img alt="watermarked-openclaw_management_3" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101612023-1942326683.jpg" class="lazyload"></p>
<p>配置文件也只不过是操作系统上的一个普通文件而已</p>
<p>3）重启某些服务</p>
<p><img alt="watermarked-openclaw_management_6" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101620280-335950910.jpg" class="lazyload"></p>
<p><img alt="watermarked-openclaw_management_5" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101626442-1107509596.jpg" class="lazyload"></p>
<p>该服务并不是systemctl托管的，它自己去ps去查找相关信息，并且完成了重启</p>
<h2 id="迁移至容器">迁移至容器</h2>
<p>刚才的演示中，已经暴露了openclaw的权限问题，如果不加以控制，那openclaw有可能成为潜在的风险，损害电脑上的重要资料</p>
<p>那怎么解决这个问题呢？将openclaw限制在容器当中，可执行的命令、可以修改的文件都受到了限制</p>
<ul>
<li>
<p>将本机的<code>~/.openclaw</code>，全部复制到新的路径，为docker启动作为数据目录，也是将原有的配置全部迁移到docker中</p>
<pre><code class="language-bash">cp -rf ~/.openclaw /data/openclaw_docker
</code></pre>
</li>
<li>
<p>docker启动脚本</p>
<pre><code class="language-bash">docker run --name openclaw \
-p 18789:18789 \
-u 1000:1000 \
-v ./openclaw_docker:/home/node/.openclaw \
ghcr.io/openclaw/openclaw:latest
</code></pre>
</li>
<li>
<p>迁移完成之后验证</p>
<pre><code class="language-bash">docker exec -it openclaw openclaw tui
</code></pre>
<p><img alt="watermarked-openclaw_management_7" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318101703259-89949055.jpg" class="lazyload"></p>
</li>
<li>
<p>修改web访问</p>
<pre><code class="language-bash">> cat openclaw.json | jq '.gateway.bind'
"lan" # 原为localhost
</code></pre>
<p>改了之后要小心了，整个lan都可以访问gateway页面，还是很危险的</p>
</li>
<li>
<p>明确指定哪些地址可以访问 Web 控制台。这提供了最好的安全性</p>
<pre><code class="language-bash">"gateway": {
"port": 18789,
"mode": "local",
"bind": "lan",
"controlUi": {
"allowedOrigins": [
"http://localhost:18789",
"http://127.0.0.1:18789"
]
},
...
}
</code></pre>
<p>笔者配置了只允许127.0.0.1来访问gateway页面</p>
</li>
</ul>
<h2 id="token限制">token限制</h2>
<p>多模型接入之后，最容易踩的坑就是token超量，笔者之前开着verbose模式跑了个文档梳理任务，一晚上刷了几十万token，账单直接起飞，所以一定要加限制。</p>
<p>1）会话级token上限<br>
防止单次对话无限生成、或者反复调用工具刷token，直接在配置里加会话token阈值：</p>
<pre><code class="language-json5">{
"agents": {
"defaults": {
"compaction": {
"reserveTokensFloor": 20000, // 上下文窗口剩余20k token时自动压缩
"maxSessionTokens": 100000 // 单个会话最多累计10万token，超过自动重置
}
}
}
}
</code></pre>
<p>超过阈值之后会话会自动触发压缩，或者直接重置，避免无限累加。</p>
<p>2）单模型每日配额限制<br>
如果你用的是收费模型，可以给每个模型加单日最大token限制，超了自动切到备用模型：</p>
<pre><code class="language-json5">{
"models": {
"providers": {
"litellm": {
"api": "openai-completions",
"baseUrl": "http://localhost:4000/v1",
"apiKey": "xxx",
"maxTokensPerDay": 500000, // 单日最多用50万token
"fallbackModel": "litellm/qwen-plus" // 超量自动切到通义千问
}
}
}
}
</code></pre>
<p>笔者亲测这个配置救了好多次，再也不用担心跑任务跑超支了。</p>
<p>3）litellm跟踪token</p>
<p>如果是通过litellm来管理大模型key，那使用litellm来跟踪token是最好的</p>
<ul>
<li>
<p>首先是观察整体的token消耗，以及不同模型的情况</p>
<p><img alt="watermarked-openclaw_management_8" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318103423446-1515347300.jpg" class="lazyload"></p>
</li>
<li>
<p>其次是查看每一次会话的token消耗</p>
<p><img alt="watermarked-openclaw_management_9" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202603/1416773-20260318103438075-1075100353.jpg" class="lazyload"></p>
</li>
</ul>
<h2 id="跟踪openclaw行为">跟踪openclaw行为</h2>
<p>可以查看<code>~/.openclaw/agents/<id>/sessions/*.jsonl</code>日志，Agent 做了什么？调了哪些工具？传了什么参数？都可以在该文件中找到。<br>
笔者习惯加个定时任务，每天把日志导出一份到备份目录，万一出了问题直接回溯，连操作时间点都对得上，非常方便。</p>
<h2 id="缩减memory避免过度联想">缩减memory，避免过度联想</h2>
<p>记忆多了也有副作用：笔者之前遇到过，给A项目配置的服务器地址，过了半个月问B项目的配置，助手直接把A项目的地址搬出来了，还说得有鼻子有眼，差点踩了线上事故。就是因为记忆库里的内容太多，语义检索的时候把相关的内 容都拉出来了，导致回答串了。</p>
<p>所以一定要限制记忆的范围，避免过度联想：</p>
<p>1）限制自动加载的记忆天数<br>
默认启动会加载今天+昨天的记忆，可以改成只加载今天的，或者完全不自动加载历史记忆：</p>
<pre><code class="language-json5">{
"agents": {
"defaults": {
"memory": {
"loadRecentDays": 1 // 只加载当天的记忆，历史记忆需要手动查询
}
}
}
}
</code></pre>
<p>如果你的场景不需要长期记忆，直接设成0，启动完全不加载历史记录，最清爽。</p>
<p>2）关闭会话历史索引<br>
默认记忆搜索会把所有历史会话记录都索引进去，不想让旧会话的内容被检索到，可以关闭：</p>
<pre><code class="language-json5">{
"agents": {
"defaults": {
"memorySearch": {
"sources": ["memory"] // 只索引MEMORY.md和memory/下的文件，不索引会话日志
}
}
}
}
</code></pre>
<p>改完之后只有你手动写到记忆文件里的内容才会被检索，会话里的临时内容不会进索引，避免串扰。</p>
<p>3）定期清理过期记忆<br>
写个脚本定时删除超过30天的记忆文件，还有清理向量索引：</p>
<pre><code class="language-bash">#!/bin/bash
# 清理30天以上的记忆
find ~/.openclaw/workspace/memory/ -name "*.md" -mtime +30 -delete
# 重建向量索引
sqlite3 ~/.openclaw/memory/main.sqlite "VACUUM;"
</code></pre>
<p>加个cron每周跑一次，记忆库永远都是最新的内容，不会有陈年旧料出来捣乱。</p>
<p>4）按项目拆分记忆<br>
不同项目的记忆不要都堆在根MEMORY.md里，新建子目录拆分：</p>
<pre><code>memory/
├── project-a/
│ └── config.md
├── project-b/
│ └── config.md
└── 2026-03-17.md
</code></pre>
<p>查询的时候指定路径，就不会把两个项目的配置搞混了。</p>
<h2 id="联系我">联系我</h2>
<ul>
<li>联系我，做深入的交流</li>
</ul>
<p><img alt="" width="500" height="200" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202411/1416773-20241121135740959-1907948957.png#" class="lazyload"></p>
<hr>
<p>至此，本文结束<br>
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...</p>
</div>
<div id="MySignature" role="contentinfo">
<p>本文来自博客园，作者：it排球君，转载请注明原文链接：https://www.cnblogs.com/MrVolleyball/p/19732739</p>
<div>本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。 </div><br><br>
来源：https://www.cnblogs.com/MrVolleyball/p/19732739 顶一个！楼主分享得很详细，这确实是生产环境部署OpenClaw必须重视的问题。
之前我部署的时候没想那么多，直接裸机跑的，后来看到有人讨论安全风险才后怕。楼主的容器化方案来得太及时了。
不过我有个小问题想请教一下：
关于token限制这块，我配置了单日配额限制，但是有个场景不太清楚怎么处理：如果我同时跑多个任务，每个任务都调用同一个模型，这样是共享这个配额还是各自独立计算啊？https://example.com/question.gif
另外关于memory这块，我之前也遇到过类似的问题，不同项目的配置会串台。楼主的按项目拆分记忆这个思路很好用，我后来还加了个MEMORY.md来标注当前激活的项目，防止搞混。
最后弱弱地问一下，容器化之后对性能影响大吗？我这边业务对响应速度要求比较高，有点担心docker层带来的延迟。
总之感谢楼主的无私分享，这些配置细节真的是踩坑踩出来的经验，比官方文档实用多了！收藏+点赞
也欢迎各位路过的大神补充其他安全加固方案，大家一起学习~ 谢谢楼上朋友的认可和提问，这两个问题问得非常到位，我之前踩坑的时候也在这两块卡了好久，分享一下我的实践方案，希望能帮到你~
先说 token 配额的问题，这确实是很多新手容易误会的地方。 目前 OpenClaw 的 token 限制机制，如果是在全局配置里设置的 max_tokens_per_day
这样的参数，同一个 API key 发起的所有请求会共享这个配额，不会按任务单独计算。也就是说，你同时跑三个对话任务，每个消耗 1w token，当天总用量就扣了 3w。如果你希望不同任务有独立的限制，我的做法是给不同项目创建不同的 API Provider 配置，每个配置绑定不同的 API key（如果有条件申请多个 key 的话），再在项目级用 token_quota
单独限制，这样就能做到任务级隔离了。如果只有一个 key，也可以通过定时脚本统计各任务的用量，触发临停，不过这种方式侵入性稍强，楼主帖子里提到的 Prometheus 监控方案会更优雅。
关于 memory 串台的问题，我这边深有体会！ 楼主的 “按项目拆分记忆” 确实是大方向。实操层面可以这样落地：
步骤一：在容器启动时通过挂载不同的 volume 路径去存每个项目的 memory 文件，比如 -v /data/mem/project_a:/app/memory
，不同项目容器互相隔离。
步骤二：在对话配置里指定 memory_session_id
，让同一个项目内的多次对话共享记忆，但和别的项目完全分库。
我之前项目 A 和项目 B 混一起跑，结果模型把 A 的客户信息 “脑补” 到 B 的工单里，直接社死……换成现在方案后稳如老狗，至今没再出过幺蛾子。
如果还有细节需要讨论，随时追问哈，大家一块把方案磨得更透
頁:
[1]