核心原理

Gateway 是 OpenClaw 的核心，负责接收消息、调用大语言模型、返回结果，可以理解为 AI 的本地代理服务器。一个 Gateway 可以托管多个 Agent，每个 Agent 通过「群组路由」绑定到不同的 Telegram 群。

你在群 A 发消息，Gateway 知道该交给「产品经理 Agent」处理；你在群 B 发消息，Gateway 知道该交给「工程师 Agent」处理。关键在于：它们共享同一个 Bot 账号，但拥有独立的记忆、权限和工作空间。

这个架构设计的精妙之处在于——它把「角色隔离」的成本降到了接近零。以前你想做场景分离，得维护多套环境；现在只需要多建几个群。

两种架构，按需选择

架构一：单 Bot 多群组（推荐入门）

  • 配置简单，一个 Bot 搞定一切
  • 适用于个人使用、小团队

架构二：多 Bot 多群组

  • 每个 Bot 独立人格，记忆隔离，场景分离
  • 适用于多场景、多角色、需要严格隔离记忆的情况

对大多数独立开发者来说，架构一就够了。不要为了「看起来专业」而过度配置，根据实际业务需求来选择。

五步完成配置

第一步：创建主 Bot

在 Telegram 搜索 BotFather，发送 /newbot，按提示操作：

  • 给 Bot 起个名字（比如 lifezhushou）
  • 设置用户名（必须以 bot 结尾，比如 lifezhushou_bot）
  • 复制返回的 Token（格式类似 123456:ABC-DEF...）

拿到 Token 后把 Bot 接入 OpenClaw。你甚至可以直接把 Token 发给 OpenClaw，让它帮你完成接入配置。

最后完成 Pairing Code 配对——类似验证码，用于确认你有权限操作这个 Bot，一次配对，永久生效。

注意：Token 是你 Bot 的钥匙，不要泄露。

第二步：开启群组权限

这是最容易踩坑的地方。默认情况下，Bot 开启了「隐私模式」，只能看到被提及的消息。不关掉这个设置，Bot 在群里就是个聋子。

操作路径：BotFather → Bot Settings → Group Privacy → 关闭隐私模式。

重点：改完之后，必须把 Bot 从群里踢出去，再重新拉进来。不重新拉，设置不生效。 这是很多人配了半天没反应的根本原因。

第三步：创建群组，获取 Group ID

每个子 Agent 需要一个专属群组，群组的 ID 就是路由地址。

  • 新建一个 Telegram 群（建议用角色命名）
  • 把主 Bot 拉进群
  • 在群里提及你的 Bot，问：当前群组的 ID 是什么？
  • Bot 会回复一串负数，比如 -1001234567890，复制保存

Group ID 是 Telegram 群组的唯一标识符，负数开头，Bot 通过这个 ID 判断消息来自哪个群。

第四步：用 Prompt 自动创建子 Agent

这是整个流程最关键的一步。回到主 Bot 的私聊窗口，发送创建子 Agent 的 Prompt，把群组 ID、角色名称、角色描述等信息填入即可。

发送后等待 10-30 秒，主 Agent 会自动创建子 Agent 并返回确认信息。每个 Agent 拥有独立的 Workspace——可以理解为它自己的「独立办公室」，里面有独立的记忆、文件和配置，Agent 之间互不干扰。

一个省事的做法：直接把整个配置流程的说明发给 OpenClaw，让它引导你一步一步完成，它会帮你处理创建群聊、绑定路由等细节。

第五步：测试并扩展角色

去刚创建的群组里发一条消息，如果子 Agent 正常回复，第一个角色就配置成功了。

接下来重复第三步和第四步，创建更多角色：

  • QA Agent：写测试用例、找 Bug
  • 工程师 Agent：写代码、做架构
  • 内容 Agent：写推文、做文案

每个角色一个群，互不干扰。更实用的是，你可以在主 Bot 私聊里「调度」它们协作——主 Agent 会自动调用对应的子 Agent，把结果汇总给你。

多 Bot 场景下的管理策略

当你需要更清晰的场景分离时，可以配置多个 Bot，每个绑定不同的 Agent。这时候需要解决一个问题：群里有多个 Bot，如何避免混乱？

方案一：设置默认响应者

  • 不指定时，默认 Bot 回答
  • 提及特定 Bot 名称时，对应 Bot 回答

方案二：全部需要提及

所有 Bot 都设置 requireMention: true，叫谁谁回答。建议只让一个 Bot 设为 false 作为默认响应者，其他都设为 true。

常见问题排查

Bot 在群里不回复：

  • 检查隐私模式是否关闭
  • 确认关闭后是否重新拉入群组
  • 检查 Group ID 是否正确绑定

Bot 之间抢消息：

检查 requireMention 配置，false 表示不需要提及也能响应，true 表示必须提及才响应。

查看详细日志：

实时查看消息路由情况，可以快速定位问题所在。

实际应用场景

  • 个人助理 + 技术顾问：默认 Bot 处理日常对话，技术 Bot 处理代码和架构问题
  • 团队协作：产品经理群做需求分析，工程师群做代码实现，QA 群做测试分析
  • 多语言服务：不同 Bot 分别处理中文、英文、日文客服

这套方案的真正价值不在技术本身，而在于它把「一个人运作一个团队」的成本结构彻底改变了。以前你想同时跑产品、开发、测试三条线，得配三套环境；现在 15 分钟配置完，你的 Telegram 就变成了一个 AI 作战室。对于独立开发者和一人公司来说，这可能是目前性价比最高的多角色 AI 协作方案之一。