ClawHost 深度研究：用 Kubernetes 把 OpenClaw 变成多租户 Bot 平台

> GitHub: fastclaw-ai/clawhost

> 组织: fastclaw-ai

> License: Apache 2.0

> 技术栈: Go + PostgreSQL + Kubernetes + Next.js

> 研究时间: 2026-03-24

🎯 一句话版本

一个用 Kubernetes 管理 OpenClaw 实例的平台——每个 Bot 跑在独立的 K8s Pod 里，通过 API 创建/启停/升级/删除，子域名自动路由，多租户隔离。适合想把 OpenClaw 做成 SaaS 服务的团队。

🧠 它解决什么问题？

OpenClaw 默认是"一台机器跑一个 Agent"。如果你想：

• 给 100 个用户每人一个独立的 OpenClaw Bot
• 通过 API 批量管理这些 Bot
• 每个 Bot 隔离（数据、配置、IM 频道互不干扰）
• 统一入口 + 子域名路由

手动管理就是噩梦。ClawHost 把这个编排层标准化了。

🏗️ 架构

┌────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│ Client │────▶│     ClawHost        │────▶│    K8s Cluster      │
└────────┘     │                     │     │                     │
               │  ┌──────┐ ┌──────┐ │     │  ┌───────────────┐  │
  Subdomain    │  │Bot   │ │Admin │ │     │  │ OpenClaw Pod  │  │
  Routing ────▶│  │ API  │ │ API  │ │     │  │  Gateway      │  │
               │  └──────┘ └──────┘ │     │  │  IM Channels  │  │
               │  ┌────────────────┐│     │  │  Devices      │  │
               │  │ Proxy (HTTP/WS)│├────▶│  └───────────────┘  │
               │  └────────────────┘│     │  ┌───────────────┐  │
               └─────────┬──────────┘     │  │ Shared PVC    │  │
                         │                │  └───────────────┘  │
                  ┌──────┴──────┐         └─────────────────────┘
                  │ PostgreSQL  │
                  └─────────────┘

核心设计：

• 每个 Bot = 一个 K8s Pod（Deployment + Service）
• ClawHost 不跑在 K8s 里也行——只需要 kubeconfig 能访问集群
• 子域名路由：my-bot.clawhost.ai 自动路由到对应 Pod，不需要每个 bot 单独配 Ingress
• 双向配置同步：PostgreSQL ↔ Pod

📦 功能清单

Bot 生命周期

# 创建 App（每个 App 有独立 API Token）
curl -X POST /bot/api/v1/admin/apps -d '{"name": "my-app"}'

# 创建 Bot
curl -X POST /bot/api/v1/bots -d '{
  "user_id": "user-001",
  "name": "my-bot",
  "config": {"model": "claude-sonnet-4-20250514", "api_key": "sk-ant-xxx"}
}'

# 启动（创建 K8s Pod）→ 停止 → 重启 → 升级 → 删除
POST /bots/:id/start
POST /bots/:id/stop
POST /bots/:id/restart
POST /bots/:id/upgrade   # 升级 OpenClaw 版本
DELETE /bots/:id

IM 频道管理

# 给 Bot 添加 Telegram 频道
POST /bots/:id/channels -d '{"channel": "telegram", "config": {...}}'
# 列出频道 / 删除频道
GET /bots/:id/channels
DELETE /bots/:id/channels/telegram

支持：Telegram, Slack, Discord, Teams, LINE, Feishu 等。

Skills 动态管理

# 给运行中的 Bot 安装/更新 Skill
PUT /bots/:id/skills/weather
# 删除 Skill
DELETE /bots/:id/skills/weather

设备配对

# 列出待审批设备
GET /bots/:id/devices
# 审批 / 撤销
POST /bots/:id/devices/:request_id/approve
DELETE /bots/:id/devices/:device_id

Model Provider 配置

# 添加多个 AI 供应商
POST /bots/:id/config/models -d '{"provider": "anthropic", "api_key": "..."}'
POST /bots/:id/config/models -d '{"provider": "openai", "api_key": "..."}'

Admin Panel

内置 Next.js + shadcn/ui 管理面板（/admin），嵌入 Go binary：

• Apps 管理（创建/编辑/Token 重置）
• Bots 管理（列表/启停/升级/删除/查看域名）
• 响应式（桌面表格/移动端卡片）

🚀 部署方式

1. Helm Chart（推荐）

docker build -t clawhost:latest .

helm install clawhost deploy/helm/clawhost \
  -n clawhost --create-namespace \
  --set adminToken="my-admin-token" \
  --set domain.botDomain="clawhost.ai"

2. 手动 K8s Manifests

kubectl apply -f deploy/k8s/namespace.yaml
kubectl apply -f deploy/k8s/rbac.yaml
kubectl apply -f deploy/k8s/pvc.yaml
kubectl apply -f deploy/k8s/postgres.yaml
kubectl apply -f deploy/k8s/deployment.yaml

3. 本地开发

make build        # 编译 admin UI + Go binary
./clawhost server  # 连接外部 K8s cluster

资源配额

🆚 OpenClaw 托管生态

💡 与我们的关联

1. 我们不需要

我们当前是单用户单实例——一台 VPS 跑一个 OpenClaw。ClawHost 解决的是多租户平台问题，不是我们的痛点。

2. 但设计值得学习

• API 全覆盖：Bot/Skills/Channels/Devices/Models 全部 RESTful API 化。如果未来我们需要远程管理多个 Agent，这套 API 设计可以参考。
• 子域名路由：不需要每个 bot 配 Ingress，统一 proxy 层处理。架构优雅。
• 双向配置同步：PostgreSQL ↔ Pod 的同步机制，比单纯挂载 ConfigMap 灵活。

3. 如果我们未来做 Agent 平台

假设要给其他人提供 OpenClaw Bot（比如做个"AI 助手即服务"），ClawHost 就是现成的底座：

用户注册 → 创建 Bot → 选 IM 频道 → 配置模型 → 一键启动

整个流程 API 已经全部实现了。

4. 与 openclaw-operator 的区别

• ClawHost：API server 架构，适合做 SaaS 面板
• openclaw-operator：K8s Operator/CRD 方式，适合 GitOps 运维

两者互补，不冲突。

5. 短期价值

可以参考它的 Helm Chart 结构——如果未来想把我们的 VPS 迁移到 K8s，这套 chart 可以直接用。

⚠️ 注意事项

1. K8s 门槛：需要 K8s 1.28+ 集群，不适合小白

2. 资源消耗：每个 Bot 默认 2 核 + 4G 内存，10 个 Bot 就要 20 核 + 40G

3. 早期项目：commit 历史不长，社区小，生产稳定性待验证

4. Bot Image 固定：默认用 1panel/openclaw:latest，不是官方 npm 安装

5. 存储共享：所有 Bot 共享一个 10Gi PVC，大规模部署需要调整

📊 评分

🆚 与小虾 (xiaoxia.app) 的对比

ClawHost 和小虾都是"让很多人用上 AI"，但解决的问题完全不同：

本质区别

• ClawHost 是"Bot 即服务" — 用户不碰底层，只通过 API 说"我要一个 Bot"，平台创建 Pod、配路由、接 IM 频道。用户拿到的是一个会说话的 Agent。
• 小虾是"环境即服务" — 用户拿到一个容器，里面能跑 AI 工具链。用户自己决定干什么——跑 LLM、写代码、搭 Agent。

对小虾的启发

1. API 设计值得参考 — ClawHost 的 Bot/Skills/Channels/Models 全 RESTful API 化，如果小虾未来加 Agent 托管功能，这套 API 结构是现成参考。

2. 不需要 K8s — 小虾的 Worker Agent 架构（单机 Docker）比 K8s 轻太多，成本优势明显，适合 $5/月定价。

3. 产品层次互补 — 小虾可以是三层产品：容器层（已有）→ LLM 代理层（llmproxy + 内置工具，设计中）→ Agent 层（未来可参考 ClawHost）。

4. 子域名路由 — ClawHost 的统一 proxy 层 + 子域名自动路由设计优雅，小虾做多用户时可以借鉴。

🔬 源码级深度对比：小虾 vs ClawHost

> 基于小虾 (github.com/xiaojay/xx) 最新代码 ~3,300 行 Go 和 ClawHost 源码的逐模块对比。

代码规模

架构核心差异

小虾独有优势（ClawHost 没有的）

1. LLM Proxy — 最大差异化

小虾的 llmproxy 是整个产品的核心竞争力：

用户容器 → llmproxy（智能路由 + fallback + usage 统计）→ 上游 Provider

• Selector 分类器：根据 prompt 内容自动判断复杂度（SIMPLE/MEDIUM/COMPLEX/REASONING），路由到对应 tier 的模型
• Profile 系统：auto（质量优先）和 eco（省钱优先）两套策略，TOML 声明式配置
• Fallback 链：主模型 429/5xx 时自动切下一个候选模型
• Capability 过滤：有图片自动选 vision 模型，有 tools 自动选支持 function calling 的
• 用量记录：每个请求记录 model_requested vs model_resolved、prompt/completion tokens、延迟、错误码
• 流式支持：SSE stream 透传 + 流式 usage 记录

ClawHost 完全没有这层——用户必须自己搞 API key 和模型配置，成本不可控。

2. 容器安全加固

小虾的 hostConfig 在 Docker 层做了完整的安全措施：

• no-new-privileges: true（防提权）
• CapDrop: NET_RAW（防容器内网络嗅探）
• tmpfs 限制（/run 16MB, /tmp 64MB）
• PidsLimit: 256（防 fork bomb）
• Memory + CPU 硬限制
• init: true（正确回收僵尸进程）
• Healthcheck（30s 间隔，检测 OpenClaw gateway 是否存活）

ClawHost 将这些交给 K8s Pod Security Standards 处理，但小虾在应用层就做好了防护。

3. 从架构层控制成本

• 单机 Docker，不需要 K8s 集群（运维成本低一个数量级）
• SQLite 开发/小规模部署零额外成本
• eco profile 自动选便宜模型（DeepSeek > Flash > Sonnet）
• 每用户 512MB（vs ClawHost 4GB），同一台机器能装更多用户

ClawHost 有但小虾缺的

结论

定位差异：ClawHost 是"Bot 编排平台"（管生命周期），小虾是"带智能 LLM 路由的容器托管"（管使用成本）。

小虾的护城河是 llmproxy + selector——用户不需要懂模型选择、不需要管 API key、不需要配 fallback，交 $5/月就有智能路由的 AI 能力。ClawHost 给你一个 Bot，但模型成本你自己扛。

下一步建议：

1. IM 频道扩展：QQ 之外加微信/TG（参考 ClawHost 的 channel API 设计）

2. Tool-Augmented 层：proxy 拦截 tool_call 并执行，差异化更大

3. 子域名路由：等多机 Worker Agent 架构时再加

4. ClawHost 的 API 设计（Skills/Channels/Devices RESTful 化）可做远期参考

报告由深度研究助手自动生成 | 2026-03-24

来源: GitHub