OpenClaw实战(六):安全设置、性能优化与最佳实践

部署只是开始，用好才是关键。

前几篇聊了 OpenClaw 的核心操作、Skills 系统、多 Agent 编排、记忆系统和自动化机制。

有人问：”跑起来了，但总觉得不太踏实——安全吗？会不会太烧钱？怎么让它更稳定？”

这篇聊聊 OpenClaw 的三大运维课题：安全设置、性能优化和最佳实践。

安全设置：守住边界

OpenClaw 是一个个人助手信任模型——一个 Gateway 对应一个可信用户。

它不是为”多个人共用一个 Agent”设计的。Agent 的权限是全局的，没有按用户隔离；所有人的对话共享同一份记忆，没有隐私隔离。如果多人共享，每个人都能触发 Agent 的全部能力，无法细粒度控制。

但这并不意味着有安全问题。在这个模型范围内，安全配置做好，完全可以放心用于生产环境。

核心原则：最小权限

从最小的访问权限开始，能工作就行。逐步放宽，而不是一开始就全开。

OpenClaw 的安全体系围绕三个问题展开：

• 谁能跟你的机器人说话？
  
  ——入站访问
• 机器人被允许做什么？
  
  ——工具策略
• 机器人能碰到什么？
  
  ——沙箱与文件系统

一、Gateway 访问控制

Gateway 是 OpenClaw 的核心进程。所有消息、工具调用、Agent 调度都经过它。

默认端口 18789，默认绑定 127.0.0.1（仅本地）。

推荐配置：

{  gateway:{    bind:"loopback",    port:18789,    auth:{      mode:"token",      token:"用长随机字符串替换"}}}

三个要点：

• 不要绑定 0.0.0.0
  
  ——这意味着任何 IP 都能访问，除非你有强 token + 防火墙
• 远程访问用 SSH 隧道或 Tailscale
  
  ——OpenClaw 支持 Tailscale Serve 模式，通过内网穿透安全暴露 UI，比直接开公网端口安全得多
• 定期更换 token
  
  ——换了设备或怀疑泄露时更换。注意：token 更换后需要重新配置所有连接的客户端

二、工具权限策略

OpenClaw 的工具权限通过 allowlist（白名单）控制。只有明确允许的工具才能执行，deny 优先级高于 allow。

保守配置示例：

{tools: {profile:"messaging",deny: ["group:automation", "group:runtime", "group:fs","sessions_spawn", "sessions_send"],fs: { workspaceOnly:true },exec: { security:"deny", ask:"always" },elevated: { enabled:false }  }}

渐进式放开策略：

四个关键概念：

• security: "deny"
  
  ——默认拒绝所有 exec
• security: "allowlist"
  
  ——仅允许白名单中的命令。需要明确列出，例如 exec.allow: ["git", "npm", "cat", "ls"]
• security: "full"
  
  ——允许所有（默认值，适合单机单用户）。官方文档明确说明这是”有意的设计选择，不是漏洞本身”
• ask: "always"
  
  ——每次执行前需人工确认

三、沙箱模式

沙箱（Sandbox）把工具调用隔离在 Docker 容器中执行，防止 Agent 直接访问宿主机。

三级配置：

{  sandbox:{    mode:"non-main",    workspace:"readonly"}}

提权工具（Elevated tools）： 标记为 elevated 的工具即使在沙箱模式下也在宿主机执行。

这是有意设计——某些命令需要直接主机访问。常见的 elevated 工具包括 exec（需要直接执行系统命令）、browser（需要控制浏览器进程）等。

elevated 不绕过工具策略，仍需 allowlist 允许。

四、频道访问控制

每个频道的入站消息都有独立策略：

{channels: {whatsapp: {dmPolicy:"pairing",groups: {"*": { requireMention:true }      }    }  }}

dmPolicy 选项：

• "pairing"
  
  ——首次对话需输入配对码（推荐）。配对码是 OpenClaw 自动生成的随机码
• "allowlist"
  
  ——仅允许指定用户
• "open"
  
  ——任何人都能对话（不推荐）

群聊原则： 始终设置 requireMention: true，避免机器人响应群内所有消息。

五、安全审计

OpenClaw 内置安全审计命令，建议定期运行：

# 基础审计openclaw security audit# 深度审计（含 Gateway 实时探测）openclaw security audit --deep# 自动修复常见问题openclaw security audit --fix# JSON 格式输出（适合集成到 CI）openclaw security audit --json

审计会检查：

• 入站访问（DM 策略、群策略、白名单）
• 工具爆炸半径（提权工具 + 开放频道）
• 执行审批漂移（security="full" 等）
• 网络暴露（Gateway 绑定、认证 token）
• 浏览器控制暴露
• 本地磁盘权限
• 插件配置

每次修改配置或安装新 Skill 后，运行一次 openclaw security audit。

六、共享场景的风险

一个 Gateway 对应一个信任边界。

如果多个人都能跟同一个 Agent 对话，每个人都继承了该 Agent 的完整工具权限。这不是漏洞，而是信任模型的设计。

如果 Agent 有 exec 权限，任何能跟它对话的人都能让它执行任意命令。

多人共享一个 Agent 时，确保所有人都在同一个信任边界内。

性能优化：省钱就是省心得

OpenClaw 的主要成本来自 AI 模型的 token 消耗。优化得当，月成本可以降低 50%-75%。

一、Heartbeat 优化（最大成本项）

Heartbeat 是 token 消耗的大头。

默认每 30 分钟触发一次，每天 48 次。HEARTBEAT.md 写得太长，每次都在烧钱。

优化前 vs 优化后对比：

优化步骤：

第一步：审计 HEARTBEAT.md

标记每一项——哪些是 Heartbeat 该做的，哪些该交给 Cron。

第二步：把 Cron 能做的事移出去

❌ HEARTBEAT.md 里不应该有的：

• 验证 Cron 任务是否运行（Cron 自己会处理）
• 生成日报/周报（用 Cron 定时触发）
• 读取和整理笔记（用 Cron 或手动触发）

✅ HEARTBEAT.md 应该保留的：

• 邮箱检查（仅紧急邮件）
• 日历检查（近期会议提醒）
• 异常检测（数据波动、系统告警）

第三步：精简指令

# HEARTBEAT.md## 工作时间（周一至周五 9:00-18:00）- 检查邮箱，仅标记紧急邮件- 检查日历，2 小时内有会议则提醒## 非工作时间- 直接回复 HEARTBEAT_OK

第四步：延长间隔

{  gateway: {    heartbeat: {      interval: "60m"    }  }}

成本对比：

注：token 消耗为参考值，实际消耗因模型、上下文长度、配置内容而异。月成本按 0.003 元/千 token 估算。

二、模型选择策略

不同任务用不同模型，是成本优化的另一条主线。

但首先要搞清楚：哪些场景能指定模型，哪些不能。

Cron 任务指定模型：

Cron 任务有两种执行方式：主会话任务和孤立任务。只有孤立任务（--session isolated）可以指定模型：

openclaw cron add \  --name "周报生成" \  --cron "0 17 * * 5" \  --session isolated \  --message "生成周报" \  --model anthropic/claude-haiku-3.5

通过对话创建 Cron 任务时，OpenClaw 默认创建的是主会话任务，无法指定模型。如果需要指定模型，需要手动创建孤立任务。

模型选择优先级：Cron 任务的 --model 参数 > 用户为该任务保存的模型覆盖 > Agent 的默认模型。

Heartbeat 不能单独指定模型：

Heartbeat 运行在主会话中，使用主会话当前的模型。没有独立的模型参数。

如果主会话用主力模型，Heartbeat 也就用主力模型。想给 Heartbeat 省钱，只能把主会话也换成轻量模型——但这样主会话对话也会受影响。

对话中切换模型：

/model anthropic/claude-haiku-3.5// 切换到轻量模型/model anthropic/claude-opus-4-6// 切换到强推理模型

/model 命令切换的是当前会话的模型，只对当前会话生效。

实际的成本优化做法：

• 把 Cron 任务设为孤立会话 + 指定轻量模型——最省钱的方式
• 主会话保持主力模型，Heartbeat 自然也用主力模型
• 复杂分析用主会话 + 强推理模型

三、上下文窗口管理

上下文越长，token 消耗越大。管理上下文就是管理成本。

控制上下文长度的方法：

1. 精简系统提示
   
   ——SOUL.md、USER.md 只保留必要信息
2. 定期清理记忆
   
   ——memory/ 下的旧文件可以归档
3. 合理设置会话重置
   
   ——会话会在每天或空闲超时后自动重置，避免上下文无限增长。具体配置可通过 openclaw configure 查看
4. MEMORY.md 定期整理
   
   ——去掉过时信息，只保留精华

四、Skill 性能影响

每个安装的 Skill 都会在每次会话启动时加载。Skill 越多、SKILL.md 越长，启动开销越大。

性能影响估算： 每个 Skill 的 SKILL.md 会被注入到每次会话的上下文中。如果安装了 10 个 Skill，每个 SKILL.md 平均 2KB，那每次会话启动就会多消耗约 20KB 的上下文 token。

优化建议：

• 只安装需要的 Skill
  
  ——定期审查 skills/ 目录
• 精简 SKILL.md
  
  ——只保留必要的指令和示例
• 按需加载
  
  ——不常用的 Skill 可以临时安装

最佳实践：稳定运行的日常

一、日常运维清单

每天：

• 检查 Gateway 运行状态：openclaw status
• 查看任务执行记录：openclaw tasks list

每周：

• 运行安全审计：openclaw security audit
• 检查磁盘空间（会话历史会增长）
• 审查 HEARTBEAT.md 是否膨胀

每月：

• 更新 OpenClaw 版本
• 审查和清理旧 Skill
• 整理 MEMORY.md 和记忆文件
• 更换 Gateway token（可选）

二、配置管理

配置文件位置：~/.openclaw/openclaw.json

最佳实践：

• 用 openclaw configure 交互式修改
  
  ——比直接编辑文件安全
• 修改前备份
  
  ——cp openclaw.json openclaw.json.bak
• Gateway 自动热加载
  
  ——配置变更后自动生效，无需重启
• 非法配置会被拒绝
  
  ——Gateway 启动前校验 JSON Schema

常用诊断命令：

# 系统健康检查openclaw doctor# 深度检查openclaw doctor --deep

三、磁盘空间管理

会话历史和记忆文件会持续增长。定期清理避免磁盘爆满：

# 查看 OpenClaw 目录占用du -sh ~/.openclaw/# 查看各部分占用du -sh ~/.openclaw/agents/*/sessions/du -sh ~/.openclaw/workspace/memory/

清理策略：

• 旧会话历史可以定期归档或删除
• memory/
  
   下超过 30 天的日志可以压缩归档
• MEMORY.md 保持精简（建议不超过 5KB）

四、备份与恢复

需要备份的关键文件：

推荐备份方式：

# 简单备份tar czf openclaw-backup-$(date +%Y%m%d).tar.gz ~/.openclaw/# 定期备份（加入 crontab）0 3 * * * tar czf /backup/openclaw-$(date +\%Y\%m\%d).tar.gz ~/.openclaw/

当然以上这些内容完全都可以以对话的方式指挥OpenClaw自己来实现。

五、常见避坑

问题一：Gateway 绑定 0.0.0.0 不设 token

Gateway 暴露到公网，任何人都能访问。始终设置 bind: "loopback" 或强 token + 防火墙。

问题二：dmPolicy 设为 “open”

任何人都能给机器人发消息，触发工具调用。至少设为 "pairing"，推荐 "allowlist"。

问题三：HEARTBEAT.md 写成任务清单

每次 Heartbeat 都执行大量操作，token 消耗爆炸。Heartbeat 只负责”看情况”，重任务交给 Cron。

问题四：Skill 来者不拒

安装了来路不明的 Skill，可能包含恶意代码。安装前审查 Skill 内容，优先使用官方或可信来源。

问题五：一个 Gateway 给多个人用

多人共享一个 Agent，每个人都继承了完整工具权限。按信任边界拆分 Gateway，每人一个独立实例。

最后

安全、性能、稳定。

这三个词听起来像运维老生常谈，但在 AI Agent 时代有了新含义。

安全不再是防火墙和端口，而是”谁能控制我的 AI”。

性能不再是 CPU 和内存，而是 token 消耗和模型选择。

稳定不再是 uptime 和负载均衡，而是”AI 的行为是否符合预期”。

OpenClaw 把这些问题摊开在你面前。因为它是自托管的，你拥有完全的控制权，也承担完全的责任。

最好的安全配置，不是锁死一切，而是知道该放开什么。最好的性能优化，不是省掉一切，而是把钱花在刀刃上。

（完）