ClawdBot多租户：单实例支持多个Telegram Bot Token的隔离运行

1. ClawdBot 是什么？一个能装进你家树莓派的AI管家

ClawdBot 不是又一个云端 SaaS 服务，也不是需要注册、绑卡、等审核的“智能助手”。它是一个你可以完全掌控的本地 AI 网关——像安装一个家庭路由器那样，下载、运行、配置，然后它就安静地待在你的设备里，为你和你的多个 Telegram 机器人提供稳定、隔离、可定制的后端能力。

它的核心定位很朴素：把大模型能力变成一种可插拔、可复用、可分权的基础服务。你不需要为每个 Bot 单独部署一套 vLLM + API 服务 + 鉴权网关；ClawdBot 让你只启动一次，就能同时支撑多个 Bot 实例，彼此之间互不干扰、资源可控、配置独立。

这背后的关键技术不是炫酷的新算法，而是扎实的工程设计：进程隔离、上下文路由、Token 级别策略控制、模型路由分流。它不追求参数量最大，但追求“开箱即用不踩坑”、“改一行配置就生效”、“出问题能快速定位到是哪个 Bot 搞的鬼”。

更实际一点说：如果你有三个 Telegram 机器人——一个给家人翻译菜谱，一个给同事同步会议纪要，一个给客户做多语言客服——以前你得跑三套环境、维护三份日志、担心模型加载冲突；现在，它们共享同一个 ClawdBot 实例，却像住在同一栋楼不同单元的邻居，门禁卡（Bot Token）各不相同，水电表（API 调用计数、并发限制）各自独立，连物业（管理员）都看不出它们共用一个锅炉房。

2. 多租户不是概念，是真实可运行的 Telegram 翻译官集群

我们拿 MoltBot 这个真实项目来验证——它正是 ClawdBot 多租户能力最典型的落地场景。

MoltBot 是 2025 年开源的「多语言、多平台、零配置」Telegram 翻译机器人。一句话概括它的能力：把用户任意消息实时翻译成 100+ 语言，支持群聊自动识别、语音转写、图片 OCR 翻译，并内置汇率、天气、维基快捷查询。它不是玩具，是实测能在树莓派 4 上稳定服务 15 用户并发的生产级工具。

而它的部署方式，就是 ClawdBot 多租户能力的教科书式示范：

  • 你不需要为“英语→中文翻译 Bot”、“日语→韩语翻译 Bot”、“法语→西班牙语翻译 Bot”分别部署三个 MoltBot 容器；
  • 你只需部署一个 ClawdBot 实例，然后在它的配置中，定义多个 Telegram Channel 配置段，每个段绑定一个独立的 Bot Token；
  • 每个 Token 对应一个逻辑上的“租户”，拥有自己专属的：
    • 模型选择（比如 A 租户用 Qwen3-4B，B 租户用 Phi-3-mini）
    • 并发上限（A 租户限 2 并发，B 租户限 8 并发）
    • 代理设置（A 租户走 SOCKS5，B 租户直连）
    • 功能开关（A 租户禁用 OCR，B 租户开启天气查询）

这种设计带来的好处是肉眼可见的：

  • 运维成本降为 1/3：不用反复拉镜像、查端口、调日志，所有 Bot 的健康状态、调用量、错误率，在 ClawdBot Dashboard 一个页面全览；
  • 资源利用更高效：vLLM 模型只加载一次，多个 Bot 共享推理引擎，显存占用不随 Bot 数量线性增长；
  • 安全边界更清晰：某个 Bot 的 Token 泄露或被滥用，影响范围仅限于该租户，不会波及其它 Bot 的会话上下文或模型权重；
  • 灰度发布变简单：想给新 Bot 上线测试版模型？只需修改对应 Token 的 models.primary 字段，不影响其它租户。

这不是理论推演，而是 MoltBot 社区已验证的实践路径：GitHub 上已有用户基于 ClawdBot 多租户能力，为不同国家的 Telegram 群组部署了 7 个语言方向各异的翻译 Bot，全部由同一台 4GB 内存的云服务器承载。

3. 如何让多个 Bot 在一个 ClawdBot 实例里“和平共处”

3.1 核心配置：每个 Bot Token 对应一份独立 channel 配置

ClawdBot 的多租户能力，全部藏在 clawdbot.json 的 channels.telegram 配置块中。关键在于：它支持数组形式的多个 Telegram 配置项，而非单一对象。

正确写法如下（注意 telegram 是一个对象数组）：

{
  "channels": {
    "telegram": [
      {
        "id": "translator-en-zh",
        "enabled": true,
        "botToken": "123456789:ABCdefGhIjKlmNoPqRsTuVwXyZ",
        "dmPolicy": "pairing",
        "groupPolicy": "allowlist",
        "streamMode": "partial",
        "proxy": "http://127.0.0.1:7890"
      },
      {
        "id": "translator-ja-ko",
        "enabled": true,
        "botToken": "987654321:ZYXwVuTsRqPoNmLkJiHgFeDcBa",
        "dmPolicy": "open",
        "groupPolicy": "denylist",
        "streamMode": "full",
        "model": {
          "primary": "vllm/Phi-3-mini-4k-instruct"
        }
      },
      {
        "id": "weather-bot",
        "enabled": true,
        "botToken": "555555555:AAAAA-BBBBB-CCCCC-DDDDD",
        "dmPolicy": "open",
        "groupPolicy": "open",
        "streamMode": "none",
        "features": {
          "ocr": false,
          "whisper": false,
          "weather": true,
          "fx": true
        }
      }
    ]
  }
}

这里有几个必须掌握的要点：

  • id 字段是租户唯一标识，用于日志追踪、监控指标打标、CLI 命令筛选（如 clawdbot channels status --id translator-en-zh）；
  • botToken 是真正的隔离钥匙，ClawdBot 启动后会为每个 Token 建立独立的 Telegram Bot 实例，消息路由、会话管理、错误重试全部隔离；
  • model.primary 可以按租户覆盖，默认继承全局 agents.defaults.model.primary，实现“同实例、不同模型”；
  • features 是 MoltBot 特有的租户级功能开关，允许你在同一套代码上，为不同 Bot 开启/关闭 OCR、Whisper、天气等模块。

重要提醒：不要把多个 Token 写成一个字符串（如 "botToken": "token1,token2"），这是常见错误。ClawdBot 会将其识别为非法 Token 并静默跳过该配置。

3.2 验证是否真正生效：三步确认法

配置写完不等于跑通。请务必执行以下三步验证：

第一步：检查配置语法与结构

clawdbot config validate

输出类似 Config is valid and ready to load 才算通过。如果报错，重点检查 telegram 是否为数组、每个元素是否有 botToken、JSON 是否有逗号遗漏。

第二步：查看通道状态

clawdbot channels status

正常输出应包含多行，每行对应一个 id：

- Telegram translator-en-zh: enabled, configured, mode:polling, token:config
- Telegram translator-ja-ko: enabled, configured, mode:polling, token:config
- Telegram weather-bot: enabled, configured, mode:polling, token:config

如果只看到一行，说明数组解析失败，大概率是 JSON 格式错误。

第三步：观察实时日志（最关键的一步）

启动 ClawdBot 后，发送一条 /start 消息给任意一个 Bot，然后执行：

clawdbot logs --tail 50 | grep "telegram.*received"

你应该看到类似日志：

[2026-01-25 10:22:33] INFO  telegram.translator-en-zh received message from @user123
[2026-01-25 10:22:35] INFO  telegram.translator-ja-ko received message from @user456

注意日志前缀中的 translator-en-zh 和 translator-ja-ko —— 这证明消息已按 Token 正确路由到对应租户实例。如果所有日志都显示同一个 id，说明路由失效，需回查配置。

3.3 模型与资源的租户级精细控制

多租户的价值不仅在于“能跑多个”，更在于“能管好每个”。ClawdBot 提供两层控制能力：

第一层：模型路由（Model Routing）

在 clawdbot.json 中，你可以为每个 Telegram 租户指定专属模型：

"telegram": [
  {
    "id": "high-accuracy",
    "botToken": "...",
    "model": {
      "primary": "vllm/Qwen3-4B-Instruct-2507",
      "fallback": "vllm/Phi-3-mini-4k-instruct"
    }
  }
]

这意味着：

  • high-accuracy 租户的请求，优先走 Qwen3-4B 模型；
  • 如果 Qwen3 加载失败或超时，自动 fallback 到 Phi-3-mini，保证服务不中断；
  • 其它租户不受影响，仍使用默认模型。

第二层：资源配额（Resource Quota）

在 agents 配置中，可为租户设置并发与内存限制：

"agents": {
  "defaults": {
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  },
  "overrides": {
    "translator-en-zh": {
      "maxConcurrent": 6,
      "memoryLimitMB": 2048
    }
  }
}
  • 全局默认最多 4 并发；
  • 但 translator-en-zh 租户被特别允许 6 并发，并限制其子任务内存不超过 2GB；
  • 这种细粒度控制，让高负载租户不会挤占低负载租户的资源。

4. 避坑指南：国内环境下最常遇到的 3 个“看似正常实则失效”的问题

4.1 问题一：Dashboard 打不开，但 clawdbot dashboard 显示链接

这是最典型的网络环境误解。clawdbot dashboard 输出的 http://localhost:7860/ 是 ClawdBot 进程所在机器的本地地址。如果你是在云服务器上运行 ClawdBot，这个地址只能在服务器内部访问。

正确做法：

  • 方案 A（推荐）：用 SSH 端口转发，在你本地电脑执行：

    ssh -N -L 7860:127.0.0.1:7860 user@your-server-ip

    然后在本地浏览器打开 http://localhost:7860/。

  • 方案 B：修改 ClawdBot 绑定地址（不推荐，存在安全风险）： 在 clawdbot.json 中添加：

    "web": {
  "host": "0.0.0.0",
  "port": 7860
}

    并确保服务器防火墙放行 7860 端口。切勿在公网暴露此端口，Dashboard 无密码保护！

4.2 问题二：Telegram Bot 收不到消息，channels status 显示 Gateway not reachable

错误日志中的 Gateway not reachable: Error: gateway closed (1006) 并非网络不通，而是 ClawdBot 的 WebSocket 网关未成功启动。

根本原因通常是：vLLM 后端服务未就绪，ClawdBot 等待超时后主动关闭了网关连接。

排查顺序：

  1. 先确认 vLLM 是否真的在运行：

    curl http://localhost:8000/v1/models
# 应返回模型列表，否则 vLLM 未启动或端口错误

  2. 检查 clawdbot.json 中 models.providers.vllm.baseUrl 是否与 vLLM 实际地址一致（注意：不能写 http://127.0.0.1:8000/v1，如果 ClawdBot 和 vLLM 在不同容器，需用容器名或宿主机 IP）；

  3. 查看完整日志：

    clawdbot logs --tail 100 | grep -E "(vllm|gateway|error)"

绝大多数情况，修复 vLLM 地址后重启 ClawdBot 即可解决。

4.3 问题三：多个 Bot Token 配置成功，但所有消息都路由到第一个租户

这是 JSON 解析的经典陷阱。当你把 telegram 写成对象而非数组时，ClawdBot 会将整个对象视为单个配置项，后续的 botToken 字段会被忽略或覆盖。

错误示例（致命）：

"telegram": {
  "botToken": "token1",
  "id": "a"
},
{
  "botToken": "token2",
  "id": "b"
}

正确写法（必须是数组）：

"telegram": [
  {
    "botToken": "token1",
    "id": "a"
  },
  {
    "botToken": "token2",
    "id": "b"
  }
]

验证方法：执行 clawdbot config dump | jq '.channels.telegram'，输出必须是 [ {...}, {...} ] 形式，而非 {...}。

5. 总结：多租户不是银弹，但它是走向专业 AI 运维的第一步

ClawdBot 的多租户能力，本质上是一次对“AI 服务化”理念的务实践行。它没有堆砌分布式、微服务、Service Mesh 等宏大词汇，而是用最直接的方式回答了一个工程师每天都会问的问题：“我能不能少部署一个服务？”

  • 它让你从“为每个 Bot 搞一套环境”的重复劳动中解脱出来；
  • 它把模型、渠道、功能、资源这些原本散落在各处的配置，收束到一个 JSON 文件里，用清晰的层级表达租户关系；
  • 它让故障排查从“大海捞针”变成“按 ID 锁定”，日志里 telegram.weather-bot 的报错，绝不会混在 telegram.translator-en-zh 的日志流中；
  • 它为未来扩展留出空间：当你要接入 Discord、Slack、微信公众号时，只需在 channels 下新增对应数组项，无需改动核心逻辑。

当然，它也有明确的适用边界：它适合中小规模、对成本和运维效率敏感的个人开发者与小团队；如果你需要跨机房容灾、毫秒级 SLA 保障、PB 级日志分析，那应该考虑更重型的平台方案。

但对绝大多数想认真用好 AI、又不想被运维拖垮的开发者来说，ClawdBot 多租户提供的，正是一种恰到好处的“专业感”——不复杂，但可靠；不昂贵，但够用；不炫技，但解决问题。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

第13课：OpenClaw｜邮件自动化处理【让AI成为你的“收件箱管家”】

avatar 龙虾开发者社区
cover

深度拆解——Google 工程总监如何把“资深工程师纪律“封装成 22 个可执行 Skill

avatar 龙虾开发者社区
cover

GenericAgent 源码级拆解——3K 行种子如何长成全系统控制 Agent，Token 消耗仅 1/6

avatar 龙虾开发者社区