企业级 OpenClaw 实战：多用户身份映射与权限隔离架构指南

在将 OpenClaw（龙虾）引入企业内部，构建业财一体化或跨部门协作的智能体平台时，我们面临的首要挑战就是"多用户环境下的安全与隔离"。OpenClaw 原生设计偏向个人助手，但在企业场景中，我们必须确保 A 员工绝对看不到 B 员工的财务数据，且销售部的 AI 无法执行运维部的删库指令。

本文将深入解析如何利用 peerId、dmScope、identityLinks 以及底层的 Skill/Docker 沙箱机制，搭建一个既方便多人使用，又符合企业级安全标准的智能体平台。

🆔 第一道防线：基于 peerId 与 dmScope 的会话隔离

在多用户通过企业微信、钉钉或 WebUI 接入同一个 OpenClaw 网关时，系统首先需要解决的是"谁在说话"以及"如何防止串台"的问题。

1. peerId（对端 ID）：用户的数字指纹

OpenClaw 依靠 peerId 来识别每一个独立的访问者。当消息从外部渠道（如企业微信机器人）传入时，OpenClaw 会自动提取发送者的唯一标识（如企微的 UserID、飞书的 OpenID 或 Telegram 的 ChatID）作为 peerId。这个 ID 是后续所有权限校验和会话绑定的基石。

2. dmScope：杜绝"记忆串台"的核心配置

如果配置不当，不同用户的对话上下文可能会被错误地共享，导致严重的隐私泄露（例如 Bob 问进度，AI 却回答了 Alice 刚刚查询的机密财报）。为了彻底隔离聊天上下文，必须在 OpenClaw 的配置文件中将 dmScope 设置为 "per-channel-peer"。

json 复制代码

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

在该模式下，OpenClaw 会为每个用户在每个渠道生成完全独立的会话键（Session Key），格式通常为 agent:<agentId>:<channel>:direct:<peerId>。这意味着，即使两个员工在同一天向 AI 提问，他们的历史聊天记录、短期记忆也是物理隔离的，互不可见。

🔗 第二道防线：通过 identityLinks 实现业务身份映射

仅有平台的 peerId（如一串乱码般的 OpenID）是不够的，企业的业财系统需要知道这个 ID 背后对应的是"财务部-张三"还是"销售部-李四"。这里我们需要利用 identityLinks 建立"渠道账号"与"企业内部员工 ID"的映射关系。

场景示例：

员工张三在公司内部拥有唯一的工号 EMP_001，但他可能同时通过企业微信、钉钉和内部 Web 门户访问 AI。为了保证他在不同平台上都能获得连续的业务体验（比如在上个平台问了库存，换个平台接着问物流），我们可以配置如下映射：

json 复制代码

{
  "session": {
    "dmScope": "per-channel-peer",
    "identityLinks": {
      "EMP_001": [
        "wechat:zhangsan_wxid",
        "dingtalk:zhangsan_dingid",
        "webui:zhangsan@company.com"
      ]
    }
  }
}

落地策略：

在实际生产中，建议开发一个简单的中间件或在首次交互时让 AI 引导用户完成绑定。一旦绑定成功，无论张三从哪个入口进来，OpenClaw 都会将其统一识别为 EMP_001，从而无缝对接后端的 ERP 权限系统。

🛡️ 第三道防线：基于 Agent 与 Skill 的精细化权限控制

OpenClaw 并没有传统意义上复杂的 RBAC（基于角色的访问控制）系统，但我们可以通过"多 Agent 隔离"与"Skill 白名单"的组合拳，完美模拟出企业级的权限管控。

1. 按角色创建隔离的 Agent（代理）

不要试图用一个全能型 Agent 服务全公司。最佳实践是为不同部门创建专属的 Agent，并分配独立的工作空间（Workspace）。

财务 Agent ：工作空间指向 ~/.openclaw/workspaces/finance，仅挂载财务报表分析、付款审批等 Skill。
运维 Agent ：工作空间指向 ~/.openclaw/workspaces/devops，挂载服务器巡检、日志排查等 Skill。

通过路由配置，将 EMP_001（财务张三）的消息自动转发给"财务 Agent"，而将运维人员的消息转发给"运维 Agent"。由于文件系统工作空间是物理隔离的，财务人员无论如何诱导 AI，都无法读取到运维目录下的服务器密钥。

2. Skill 白名单与高危操作拦截

在 Agent 的配置中，必须显式声明该 Agent 允许调用的工具列表（Allowlist）。

最小权限原则 ：普通员工的 Agent 仅开启 read_only（只读）类技能，严禁开启 bash_execution（系统命令执行）或数据库写入权限。
供应链安全：严禁多人共用全局的 Skills 目录。应为每个 Agent 配置私有的 Skills 路径，并设置严格的目录权限（如 Linux 的 700 权限），防止恶意用户上传带毒的 Skill 脚本影响整个团队。

⚙️ 终极兜底：Docker 沙箱与环境隔离

即便做好了上述应用层的隔离，为了防止 AI 产生幻觉执行了毁灭性的代码（如 rm -rf /），或者某个 Skill 存在未知的安全漏洞，我们必须在底层启用 Docker 沙箱模式。

当 Agent 需要执行 Python 脚本、处理敏感 Excel 报表或调用本地 CLI 工具时，强制要求这些操作在临时的 Docker 容器中运行。

无特权运行：容器内不使用 root 权限。
资源限制：限制容器的 CPU 和内存占用，防止单个用户的死循环指令拖垮整台服务器。
网络隔离：容器默认无法访问公司内网的核心生产数据库，仅能通过预设的 API 网关进行受控的数据交换。

📌 总结

构建企业级 OpenClaw 平台的核心逻辑可以概括为： "认对人、分好组、锁好门" 。

认对人 ：利用 peerId 结合 identityLinks，将杂乱的渠道账号映射为清晰的企业员工身份。
分好组 ：通过 dmScope 隔离会话记忆，通过多 Agent 架构隔离业务职能与工作空间。
锁好门：利用 Skill 白名单限制能力边界，并最终通过 Docker 沙箱兜底，确保任何异常操作都被限制在安全的牢笼之内。

通过这套组合架构，你不仅能替代繁琐的小程序开发，更能让企业在享受 AI 自动化红利的同时，牢牢守住数据安全与合规的底线。