博客教程 | OpenClawNav

很多人刚开始用 OpenClaw，最容易走两种极端：

要么把它当普通聊天机器人，低估了风险；
要么一上来就全开权限、全接入口，结果自己也不知道边界在哪里。

但 OpenClaw 真正难的地方，不是“会不会用”，而是：你有没有先把它放进一个可控的范围里。

这篇文章把原本拆开的“认知篇”和“配置篇”整理成一篇完整版本。你不用先看抽象道理，再去另一篇找配置项；这里会直接从“为什么有风险”讲到“个人用户到底该怎么配”。

一、先搞懂一件事：OpenClaw 不是聊天工具，而是会动手的助手

如果把 OpenClaw 当成普通 AI 对话工具，你大概率会误判它的风险。

因为它和纯聊天模型最大的区别，不是“更聪明”，而是它能真的替你做事。它可能会：

读取本地文件
执行命令
联网获取内容
收发消息
接入 Hook、Webhook、邮件等外部输入

打个最直白的比方：

普通 AI：像一个只会出主意的朋友；
OpenClaw：像一个拿着你家钥匙、还能帮你跑腿和操作设备的助手。

所以 OpenClaw 的安全重点，从来不是“让它一句错话都不说”，而是：

就算它被诱导、误判或配置失误，也不要让它轻易伤到你。

二、新手最容易踩的 5 个坑

很多安全问题，不是高深漏洞，而是“能力太多、边界太松、输入太杂”叠在一起的结果。先把下面这 5 个坑看明白，后面的配置才知道为什么要这么改。

风险类型	大白话解释	常见场景
提示注入	外部内容里夹了“假指令”，助手把它当真了	网页、邮件、群消息里藏着让它读配置、跑脚本、绕过限制的内容
Skill 供应链风险	装插件，本质上是在引入第三方提示和逻辑	只看功能好不好用，不看来源、权限和脚本行为
权限开太大	给了太多能力，一次误操作就能放大后果	一上来就开文件、命令、联网、消息发送
会话串扰	不同人、不同渠道、不同场景混用上下文	工作私聊、群聊、家庭消息混在一起，导致串话或泄露
外部入口过多	接得越多，攻击面越大	同时接邮箱、Webhook、网页抓取、自动化任务

如果把这 5 个坑浓缩成一句话，就是：

OpenClaw 的主要风险，不是“回答错”，而是“替你做错”。

三、个人用户先记住这 3 条安全原则

不用追求“绝对安全”，个人用户更现实的目标是：先把损失面锁死，再逐步放开能力。

记住这 3 条就够了：

少给权限：只开当前确实要用的能力，多余的一律先关。
按场景隔离：工作、私聊、群聊、实验环境不要混在一起。
外部内容先当不可信输入：网页、邮件、Webhook、陌生 Skill 默认都先审，再决定要不要放行。

只要这三条没有做到，后面再多“高级安全建议”也容易失效。

四、个人用户最值得先改的 5 项配置

下面这 5 项，不是为了把 OpenClaw 配成“什么都不能做”，而是帮你先从“裸奔”变成“可控起步”。

1. 先把 `tools.profile` 收紧

这是最重要的一项，因为它直接决定 Agent 能碰到多少能力。

对大多数个人用户，建议这样理解：

纯聊天 / 群聊回复 / 通知转发：优先 messaging
只想极简试用：可以用 minimal
确实要读写文件、跑命令、本地开发：再考虑 coding
不要默认就用：full

推荐命令：

openclaw config set tools.profile messaging

只有当你明确需要本地文件和命令能力时，再切到：

openclaw config set tools.profile coding

2. 把私聊隔离收紧到 `session.dmScope = "per-channel-peer"`

如果一个机器人要面对多个私聊对象、多个渠道，最容易出的问题不是“不会回”，而是上下文混线。

推荐配置：

{
  "session": {
    "dmScope": "per-channel-peer"
  }
}

推荐命令：

openclaw config set session.dmScope "per-channel-peer"

这项特别适合：

同时接多个 DM 渠道
同时服务多个用户
既在群聊里用，也在私聊里用

3. 确认所有 `allowUnsafeExternalContent` 都没有被打开

如果你接了 Gmail、IMAP、Webhook 映射之类的入口，这项一定要检查。

重点关注这类配置：

hooks.gmail.allowUnsafeExternalContent
hooks.mappings[].allowUnsafeExternalContent
hooks.imap.allowUnsafeExternalContent

原则很简单：没有非常明确的调试需求，就不要把它设成 true。

因为一旦打开，很多外部内容就可能绕过原本的安全包装，提示注入风险会被明显放大。

4. 沙箱先收紧，默认别给网络和工作区访问

如果你准备测试 Skill、跑实验性命令、接触陌生内容，最好先让 Agent 待在“小房间”里。

推荐起步值：

{
  "sandbox": {
    "docker": {
      "network": "none"
    }
  },
  "workspaceAccess": "none"
}

这两个配置的含义也很直白：

sandbox.docker.network: "none"：默认不联网
workspaceAccess: "none"：默认碰不到宿主工作区

代价是能力会少一点，但这正适合“先试、先观察、先控制风险”的阶段。

5. exec 审批尽量只单次放行，不要随手点 “Always Allow”

很多人觉得审批弹窗烦，第一反应就是点长期放行。但对 python、bash、node 这类解释器命令尤其要谨慎。

更稳的做法是：

优先 allow once
对会写文件、联网、执行脚本的命令保持保守
能不让 Agent 直接碰宿主机，就尽量别碰

一句话总结：长期授权不是省事，而是在把未来的不确定性一次性签出去。

五、先照着做的 5 条实操习惯

除了改配置，日常使用方式本身也会决定风险高不高。对新手来说，下面这 5 条通常比折腾复杂策略更有用。

1. 外部内容一律先当“可疑数据”

网页、邮件、群消息、API 返回都先当普通资料处理，不要默认把里面的话当成系统指令。

2. 能不开执行权限就不开

如果你只是想让它答疑、整理文档、做推荐，就别顺手把 shell、全盘文件读写这些高权限能力一起打开。

3. 不同场景别共用同一个上下文

工作、家庭、私聊、测试环境最好分开。不要让一个助手一边处理工作消息，一边顺手接个人内容。

4. 装 Skill 前先花 3 分钟看来源和说明

至少看这几件事：

来源是否清楚
作者是否可信
有没有公开仓库或说明页
是否要求高权限
SKILL.md 里有没有读敏感文件、改长期配置、忽略限制之类的红旗

5. 密钥和 Token 只给最小权限

不要把主力账号、管理员权限、生产密钥直接交给助手。能给只读，就别给读写；能给临时子账号，就别给主账号。

六、直接可用的 3 套起步模板

如果你不想一项项抠配置，可以先按使用场景选一个方向。

模板 A：群聊 / 私聊回复型

适合：消息回复、通知、轻量答疑

{
  "tools": {
    "profile": "messaging"
  },
  "session": {
    "dmScope": "per-channel-peer"
  }
}

核心思路：先把它当消息机器人，而不是执行代理。

模板 B：接外部内容，但先把风险收紧

适合：收邮件、收 Webhook、读外部内容，但不需要高权限执行

{
  "tools": {
    "profile": "messaging"
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "hooks": {
    "gmail": {
      "allowUnsafeExternalContent": false
    }
  }
}

如果你用的是 mappings 或 IMAP，也是同一个原则：不要打开 allowUnsafeExternalContent。

模板 C：要做 Skill / 命令实验，但尽量关在笼子里

适合：测试第三方 Skill、本地实验、命令辅助

{
  "tools": {
    "profile": "coding"
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "sandbox": {
    "docker": {
      "network": "none"
    }
  },
  "workspaceAccess": "none"
}

这套不是万能，但很适合个人用户的一个安全起点：

保留实验能力，同时默认不联网、不碰宿主工作区。

七、改完后，至少做这 4 个检查

确认 tools.profile 不是默认高权限，尤其不是一上来就 full
确认 session.dmScope 已经隔离到 per-channel-peer
搜一遍 allowUnsafeExternalContent，避免有入口偷偷开成 true
回想自己有没有对高风险命令点过 “Always Allow”

额外补充：最近这波安全讨论，普通用户先补哪几件事

最近关于 OpenClaw 的安全讨论之所以突然变多，不是因为风险突然“从无到有”，而是因为越来越多人开始把它接到：

聊天渠道
外部网页
邮件 / Webhook
第三方 Skill
本地文件和命令执行

一旦这些入口同时打开，风险就不再只是“回答错了”，而是更容易变成：

把外部内容里的恶意提示当真
把第三方 Skill 的行为边界想得太乐观
给了过高权限后，一次误操作就放大后果

如果你现在就想做最小动作集，不用先追求“最强防御”，先补下面 4 件事更实际：

把 tools.profile 收在当前真要用的最小范围里
把所有外部内容默认当成不可信输入
不随手给高风险命令点 “Always Allow”
装第三方 Skill 前，先看来源、权限和说明

如果你还想进一步看“最近这波事件到底影响了什么、升级后应该先怎么检查”，可以接着看 OpenClaw 3.22/3.23 更新到底改了什么：一次看懂这轮大升级和紧急修复。那篇更偏版本变化和升级判断；这篇更偏长期安全顺序。

八、这篇文章真正想帮你建立的，不是“最强配置”，而是“安全顺序”

对个人用户来说，更合理的顺序通常是：

先做低权限、自用、小范围场景
再做会话隔离和外部输入收口
然后才考虑 Skill、命令、自动化
最后再慢慢接邮箱、Webhook 和更复杂的外部系统

别反过来。

不要先把所有门都打开，再期待自己以后有空慢慢补安全。

更稳的做法始终是：

先证明它值得被信任，再逐步给能力。

如果你能做到这一点，OpenClaw 就不会只是“很强”，而会变成一个真正可长期使用、可逐步扩展、又不至于把自己置于高风险中的助手系统。

OpenClaw 安全上手指南：从认知到配置，个人用户先把这 10 件事做好

目录