夜雨聆风OpenClaw（小龙虾🦞）是一个开源的 AI Agent 网关，能把 Discord、飞书、Telegram、企业微信、Slack 等消息平台统一接入 AI 智能体。但对企业来说，从"个人玩玩"到"真正生产可用"，中间隔着十几个必须回答的问题。本文从架构设计到落地实践，逐一拆解。
一、整体架构：龙虾池怎么建？
企业落地 OpenClaw，首先要理解它的核心架构——单网关多通道多智能体模型。
┌─────────────────────────────────────────────────┐
│ 企业用户层 │
│ 飞书 / 企业微信 / Slack / Teams / Telegram │
└──────────────────┬──────────────────────────────┘
│ 消息通道
▼
┌─────────────────────────────────────────────────┐
│ OpenClaw Gateway（网关） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Agent-A │ │ Agent-B │ │ Agent-C │ │
│ │ (客服) │ │ (研发) │ │ (运维) │ │
│ │ workspace│ │ workspace│ │ workspace│ │
│ │ sessions │ │ sessions │ │ sessions │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ 安全 & 沙箱层 │ │
│ │ Docker/SSH 沙箱 · 权限管控 · 审计 │ │
│ └──────────────────────────────────────┘ │
└──────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ 大模型服务层 │
│ GPT-4o / Claude / 通义千问 / GLM / 本地模型 │
│ 火山引擎 / 智谱 / Azure / AWS Bedrock │
└─────────────────────────────────────────────────┘核心原则：
- • 一个 Gateway 实例跑在一台主机上，管理所有消息通道
- • 多个 Agent各自独立工作区、独立会话、独立人格
- • 沙箱隔离防止 Agent 执行越权操作
- • 多模型支持，可按 Agent 或场景灵活切换
二、安全与权限：龙虾不能乱跑
这是企业最关心的问题。OpenClaw 的安全模型基于个人助手信任边界（Personal Assistant Trust Model），企业落地时需要做针对性的加固。
2.1 信任模型：一人一边界
OpenClaw 默认假设一个 Gateway 对应一个可信操作者。企业场景下这意味着：
| 场景 | 推荐做法 |
|---|---|
| 单人使用（CEO/CTO 个人助手） | 默认配置即可，开启安全审计 |
| 团队共享（5-10人部门） | 按信任边界拆分 Gateway，或严格沙箱化 |
| 全公司开放（100+人） | 必须拆分多个 Gateway + 独立主机 |
核心原则： 如果多个互不信任的用户能操控同一个 Agent，就等同于他们都拥有了该 Agent 的全部工具权限。
2.2 安全审计：第一条命令
# 基础审计
openclaw security audit
# 深度审计（会探测网络和认证）
openclaw security audit --deep
# 自动修复常见问题
openclaw security audit --fix审计会检查：
- • Gateway 认证是否暴露在公网
- • 浏览器控制是否被非法访问
- • 文件系统权限是否过于宽松
- • 沙箱配置是否合理
- • Webhook 入口是否安全
- • npm 插件是否有完整性校验
2.3 DM 访问控制
OpenClaw 提供四种 DM（私信）模式：
┌──────────────┐
│ pairing │ ← 设备配对认证（最安全）
├──────────────┤
│ allowlist │ ← 白名单模式
├──────────────┤
│ open │ ← 开放模式（企业慎用）
├──────────────┤
│ disabled │ ← 禁止私信
└──────────────┘企业推荐： pairing 或 allowlist 模式，严格限制谁能和 Agent 对话。
2.4 网络暴露面控制
# 配置示例：只绑定本地
{
"gateway": {
"bind": "127.0.0.1",
"port": 18789,
"auth": {
"mode": "password",
"password": "强密码-用SecretRef管理"
}
}
}如果需要远程访问，推荐通过 Tailscale / WireGuard 等零信任网络隧道，而不是直接暴露端口。
三、沙箱隔离：龙虾的笼子
OpenClaw 的沙箱机制是保护宿主机的最后一道防线。Agent 执行的 exec、read、write 等工具操作都可以被限制在沙箱内。
3.1 沙箱模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
off | 无沙箱，工具直接跑在宿主机 | 个人开发/调试 |
non-main | 仅非主会话跑沙箱 | 主会话自由操作，群聊/自动化受限 |
all | 所有会话都跑沙箱 | 企业推荐 |
3.2 沙箱范围
| 范围 | 说明 | 资源消耗 |
|---|---|---|
agent | 每个 Agent 一个容器 | 平衡之选 |
session | 每个会话一个容器 | 最安全，资源消耗大 |
shared | 所有共享一个容器 | 最省资源 |
3.3 沙箱后端
┌─────────────────────────────────────────┐
│ Docker（推荐） │
│ 本地容器，开箱即用，网络可隔离 │
├─────────────────────────────────────────┤
│ SSH │
│ 远程主机，适合分布式部署 │
├─────────────────────────────────────────┤
│ OpenShell │
│ 托管沙箱服务，免运维 │
└─────────────────────────────────────────┘企业配置示例：
{
"agents": {
"defaults": {
"sandbox": {
"mode": "all",
"scope": "agent",
"backend": "docker",
"docker": {
"network": "none"
},
"browser": {
"autoStart": true,
"network": "openclaw-sandbox-browser",
"cdpSourceRange": "172.21.0.1/32"
}
}
}
}
}四、用户认证与账号管理
企业场景下，"谁能用龙虾"是第一个要回答的问题。
4.1 当前认证机制
OpenClaw 的认证是通道级别的：
- • 飞书/企业微信： 通过应用审核机制控制谁能添加机器人
- • Telegram： 通过 Bot Token + 白名单控制
- • Discord： 通过服务器权限 + Bot 配置控制
- • WebChat： 通过 Gateway 认证（密码/Token）控制
4.2 多用户场景的最佳实践
企业组织架构
├── 部门A（研发）
│ └── Gateway-1 (Docker/VPS-1)
│ ├── Agent: 代码审查助手
│ └── Agent: 技术文档助手
├── 部门B（市场）
│ └── Gateway-2 (Docker/VPS-2)
│ ├── Agent: 内容创作助手
│ └── Agent: 数据分析助手
└── 管理层
└── Gateway-3 (私有服务器)
└── Agent: CEO私人助手为什么不推荐一个 Gateway 服务全公司？
- 1. 安全边界模糊——一个用户越权可能影响所有人
- 2. 会话隔离不够——sessionKey 是路由选择器，不是授权令牌
- 3. 资源竞争——共享 Agent 可能被某个用户的长任务阻塞
4.3 SSO / LDAP 集成建议
OpenClaw 目前不直接支持 SSO/LDAP，但可以通过以下方式间接实现：
- 1. 飞书/企业微信集成： 利用平台自身的 SSO 能力，只有通过企业认证的用户才能添加 Bot
- 2. Tailscale Auth： 利用 Tailscale 的身份认证作为网络层准入
- 3. 反向代理认证： 在 Gateway 前面放 Nginx + OAuth2 Proxy
五、技能管理：教龙虾干活
技能（Skills）是 OpenClaw 的核心扩展机制。企业需要建立技能全生命周期管理。
5.1 技能架构
技能来源
├── ClawHub 社区市场 (clawhub.com)
├── 企业自研技能 (内部 Git 仓库)
└── Agent 工作区内置技能 (workspace/skills/)
技能加载链
├── Agent 工作区技能（优先级最高）
├── 共享技能目录 (~/.openclaw/skills/)
└── 插件注册的技能5.2 技能安全审查
企业自建技能时，必须审查：
✅ 检查清单：
- [ ] SKILL.md 是否声明了所需权限
- [ ] 脚本是否有外部网络请求（数据泄露风险）
- [ ] 是否读取了敏感文件路径
- [ ] 依赖的 npm 包是否可信
- [ ] 是否有完整性校验（integrity hash）
- [ ] 是否支持 SecretRef 管理密钥5.3 技能分发管理
# 从社区市场安装
openclaw skills install <skill-name>
# 查看已安装技能
openclaw skills list
# 企业内部：从 Git 仓库同步
cd ~/.openclaw/skills/
git clone <internal-skill-repo>企业建议： 建立内部技能仓库，所有技能经过安全审查后统一分发，禁止 Agent 自行安装未审查技能。
六、大模型选型与计费
这是企业落地最现实的问题——龙虾吃多少饲料（Token）？
6.1 模型选型矩阵
| 场景 | 推荐模型 | 月成本估算 | 说明 |
|---|---|---|---|
| 日常对话/问答 | GLM-4-Flash | ≈¥0 | 免费额度够用 |
| 文档写作 | Claude Sonnet / GLM-5 | ¥500-2000 | 质量优先 |
| 代码审查 | GPT-4o / Claude | ¥1000-3000 | 准确率优先 |
| 简单分类/提取 | GLM-4-Flash / 通义Lite | ≈¥0 | 性价比最高 |
| 本地隐私场景 | Qwen2.5-7B (本地) | ¥0 | 数据不出境 |
6.2 多模型 Failover 配置
{
"models": {
"providers": {
"zhipu": {
"apiKey": "使用SecretRef管理",
"models": [
{ "id": "glm-5.1", "contextWindow": 128000 }
]
},
"anthropic": {
"apiKey": "使用SecretRef管理"
}
}
},
"agents": {
"defaults": {
"models": ["zhipu/glm-5.1", "anthropic/claude-sonnet-4"]
}
}
}OpenClaw 支持模型降级链：主模型不可用时自动切换到备用模型，配合冷却探测机制避免无限重试。
6.3 成本控制策略
成本控制金字塔
┌─────────┐
│ 模型选型 │ ← 按场景选最合适的模型
├─────────┤
│ Token控制 │ ← 上下文裁剪、会话压缩
├─────────┤
│ 缓存策略 │ ← 相同 Prompt 复用结果
├─────────┤
│ 本地模型 │ ← 高频低复杂度任务走本地
└─────────┘实用建议：
- • 90% 的日常任务用免费/低成本模型就够了
- • 只有需要高质量输出的场景才用贵模型
- • 开启会话压缩（Compaction）减少 Token 消耗
- • 定期查看
openclaw models status --probe监控用量
七、弹性部署与资源管理
7.1 部署架构选择
方案一：单机多容器（小团队）
┌──────────────────────────────┐
│ 宿主机 (VPS) │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ GW-A │ │ GW-B │ │ GW-C │ │
│ │Dept-A│ │Dept-B│ │Admin │ │
│ └──────┘ └──────┘ └──────┘ │
│ Docker 网络隔离 │
└──────────────────────────────┘
方案二：多云分布式（中大型企业）
┌──────┐ ┌──────┐ ┌──────┐
│ 腾讯云 │ │ 阿里云 │ │ 本地 │
│ GW-A │────│ GW-B │────│ 总控 │
│Dept-A │ │Dept-B │ │GW-Mgr│
└──────┘ └──────┘ └──────┘
Tailscale / WireGuard 互联
方案三：K8s 编排（大规模）
┌──────────────────────────────┐
│ K8s 集群 │
│ Pod-GW-A × N (HPA扩缩容) │
│ Pod-GW-B × N │
│ + Redis 会话持久化 │
│ + PVC 工作区存储 │
└──────────────────────────────┘7.2 资源配置建议
| 规模 | CPU | 内存 | 磁盘 | 月成本 |
|---|---|---|---|---|
| 个人/试用 | 2核 | 4GB | 40GB SSD | ¥50-100 |
| 小团队(5-10人) | 4核 | 8GB | 100GB SSD | ¥200-400 |
| 中型(50人) | 8核 | 16GB | 200GB SSD | ¥500-1000 |
| 大型(200+) | 16核+ | 32GB+ | 500GB+ | ¥2000+ |
7.3 Python 依赖管理
Agent 执行的 Python 脚本经常需要额外依赖。企业环境下的最佳实践：
{
"sandbox": {
"backend": "docker",
"docker": {
"image": "企业自建镜像",
"preInstall": [
"pandas", "numpy", "requests",
"beautifulsoup4", "openpyxl"
]
}
}
}建议： 构建企业标准 Docker 镜像，预装常用依赖，定期更新。
八、配置管理：让普通人也能养龙虾
OpenClaw 的配置文件是 openclaw.json，这是最难的部分——普通人确实不太会配。
8.1 可视化配置方案
现有工具：
- •
openclaw onboard—— 交互式引导配置 - • Web Control UI —— 浏览器管理面板
- •
openclaw configure—— 命令行配置向导
企业建议： 提供预制配置模板
# 为不同角色提供预制配置
openclaw agents add --template=customer-service # 客服模板
openclaw agents add --template=dev-assistant # 研发模板
openclaw agents add --template=data-analyst # 数据分析模板8.2 配置即代码
# 配置文件纳入 Git 管理
cd ~/.openclaw/
git init
git add openclaw.json models.json
git commit -m "baseline config"
# 变更可追溯、可回滚九、监控与运维：龙虾的健康检查
9.1 心跳机制
{
"heartbeat": {
"intervalMinutes": 30,
"prompt": "检查系统状态，有异常主动汇报"
}
}9.2 定时任务管理
# 查看所有定时任务
openclaw cron list
# 添加定时巡检
openclaw cron add --schedule "0 9 * * 1-5" \
--task "检查各Agent状态，汇总异常"9.3 日志与审计
# 查看 Gateway 日志
openclaw logs --follow
# 安全审计报告
openclaw security audit --json > audit-report.json十、落地的 12 步检查清单
企业启动 OpenClaw 落地时，按这个顺序走：
□ 1. 确定信任边界 —— 哪些人共用一个 Gateway
□ 2. 规划部署架构 —— 单机 / 多机 / 多云
□ 3. 网络安全加固 —— 端口绑定、VPN、零信任
□ 4. 配置沙箱隔离 —— Docker 沙箱 + 网络隔离
□ 5. 设置认证机制 —— 通道白名单 + Gateway 认证
□ 6. 选型大模型 —— 按场景选模型，配置 Failover
□ 7. 审查技能安全 —— 只安装经过审查的技能
□ 8. 构建标准镜像 —— 预装依赖的企业 Docker 镜像
□ 9. 配置监控告警 —— 心跳 + 定时巡检 + 日志审计
□ 10. 建立配置管理 —— Git 管理配置，模板化分发
□ 11. 制定运维手册 —— 故障恢复、升级、扩容流程
□ 12. 安全审计上线 —— `openclaw security audit --deep`总结
养龙虾这件事，说简单也简单——npm install -g openclaw 装上就能跑。说复杂也复杂——企业落地要考虑安全、权限、成本、可维护性等十几个维度。
核心思路就三条：
- 1. 信任边界先行 —— 先搞清楚"谁能用"，再搞"怎么用"
- 2. 沙箱必开 —— 生产环境无沙箱等于裸奔
- 3. 按场景选模型 —— 不是所有任务都需要 GPT-4，90% 的场景便宜模型就够了
OpenClaw 目前还在快速迭代中，安全模型、企业功能都在持续完善。对企业来说，现在入场既是机遇（先发优势、深度定制），也有风险（API 变化、功能不成熟）。建议从小团队试点开始，验证价值后再逐步推广。
龙虾好不好养，取决于池子建得好不好。先把基础设施搭扎实，再往里放龙虾。🦞