先说个真实的场景我本地原来跑着三个独立的 Telegram Bot一个管写作一个管代码一个做日常问答。三个 bot 就要三套 token、三份部署配置、三条消息回调链路每次想调一下模型参数得分别改三个地方。后来我把它们全部收编进了一个 Bot借助 Telegram 群组的 Topics话题功能做消息路由配合 OpenClaw 这个自托管的 AI 助手网关统一管理一个 Bot 就同时撑起了多个完全独立的 AI 助手每个助手有自己独立的 System Prompt、独立的模型配置、独立的上下文记忆互相不串门。这篇文章就把这套方案的完整部署过程和踩坑记录写出来。适合那些想用 Telegram 做统一 AI 入口、又不想同时维护一大堆 Bot 的人也适合正在折腾 OpenClaw 但卡在部署或路由配置上的朋友。1. 为什么是 OpenClaw Telegram Topics先理清需求和分工在设计任何方案之前我习惯先把我要解决什么问题写清楚。这套组合的核心问题只有一个怎样用最小的维护成本跑尽可能多的独立 AI 助手。1.1 一个 Bot 只能一个角色的困境很多人刚开始玩 AI 助手的时候都是一个 Bot 走天下——把写作、编程、翻译、闲聊全部塞进同一个 System Prompt 里。短期看没问题用久了就会发现几个很烦的现象上下文互相污染。你和它聊了三轮代码调试转头让它帮你写一段朋友圈文案它大概率还带着代码变量的思维回出来的文案冷冰冰。原因很简单同一个会话只有一个上下文窗口前面聊的内容会一直影响后面的输出。System Prompt 难以兼顾。想让一个助手既专业又幽默还精通代码prompt 会写得越来越长模型对每部分指令的遵循度反而下降。我拆成三个独立助手后每个 prompt 都短小精悍效果明显更好。部署和管理成本线性增长。每新增一个 Bot就要注册一个 BotFather token多配一条 webhook 或轮询通道多维护一份环境变量。时间一长光理顺这些 token 之间的关系就够喝一壶。所以我的思路是入口统一大脑分叉。也就是一个 Bot 只做消息收件箱至于这条消息该交给哪个 AI 助手处理由上层网关根据消息特征去路由。1.2 Topics 提供的天然消息隔离舱Telegram 群组的 Topics 功能也叫 Forum Mode本质上是在一个群聊里开多个子线程。每个 Topic 单独拥有自己的消息流、标题和通知设置。最关键的一点是Bot 在接收消息时每条消息都会携带一个message_thread_id字段。这个字段就是天然的房间号。Bot 只要读一下房间号就能判断这条消息应该进哪条处理管线。这意味着不需要多个 Bot。一个 Bot 在群里的所有 Topic 中都能收到消息只需要根据message_thread_id转发给不同的处理逻辑。不需要自己写复杂的状态机。Telegram 服务端已经帮你把不同话题的消息流隔离开了你只需要做映射不用做过滤。用户侧体验极好。大家还在同一个群里通过顶部的话题标签切换助手视觉上清清楚楚不会出现多 Bot 轰炸聊天列表的情况。1.3 OpenClaw 在整套方案里扮演什么角色OpenClaw 是一个自托管的 AI 代理编排框架简单说它就是一个AI 助手网关。它负责三件事连接各种聊天渠道Telegram、Teams、Discord 等、管理多个助手实例每个实例有自己的模型、人格、工具、维护会话记忆。在 Telegram Topics 这套方案里OpenClaw 处在中间层。Telegram 群组负责消息入口和隔离OpenClaw 负责消息路由和模型调度。我甚至不需要自己写 bot 代码只需要在 OpenClaw 的配置文件里声明好各个助手、声明好 Telegram 渠道的接入参数网关就会自动把不同 Topic 的消息分发到对应的助手。这套分工的好处是每一层只干一件事出了问题也容易定位收不到消息查 Telegram 接入路由错了查 OpenClaw 配置回答质量差查模型设置。2. 先把环境跑起来OpenClaw 安装与 Windows 下的 WSL2 折腾记录先说环境结论如果你有一台 Linux 服务器或者 Mac安装过程会顺畅很多如果你跟我一样主力机是 Windows那大概率会在 WSL2 环节卡一下。2.1 部署方式怎么选OpenClaw 官方提供了几种安装方式我理解下来最适合大部分人的是 Docker Compose 方案。其他几种我也列一下方便你按自己的情况选部署方式优点需要注意的坑Docker Compose依赖隔离、升级方便、配置文件清晰需要先装 DockerWindows 下需要 WSL2 后端官方一键脚本命令少、上手快脚本依赖特定系统环境Windows 下经常触发 WSL 检测源码手动部署可定制性最高、方便二次开发要自己装 Node.js/Python 依赖环境变量容易漏配我自己最后选了 Docker Compose。原因很简单多助手配置、模型接入配置都集中在docker-compose.yml和对应的配置文件里出了问题可以整个容器删掉重来不会污染宿主机环境。2.2 无法安全验证 WSL2 环境的排查过程如果你在 Windows 上运行 OpenClaw 的某些安装脚本很可能会遇到类似这样的报错提示无法安全验证 WSL2 环境。请在 PowerShell 中运行 wsl -- status 检查当前状态。我第一次看到这个提示的时候第一反应是OpenClaw 安装脚本在检查什么第二反应是我的 WSL 明明能用啊。后来理清楚了OpenClaw 的安装脚本会检查当前 WSL 是不是 2.0 版本并且要确认默认发行版已经初始化。如果你的 WSL 内核版本过旧、或者默认版本还是 WSL1脚本就会拒绝继续执行。按这个顺序排查先打开 PowerShell运行wsl --status看输出里有没有 默认版本: 2 或者 Default Version: 2。如果显示的是 1就说明系统默认用 WSL1 跑发行版脚本当然认为环境不安全。运行wsl --update更新 WSL 内核。这一步很关键很多人的 WSL 内核停留在 2021 年左右的老版本OpenClaw 脚本检测到内核太旧就会误判。如果更新完还是不行运行wsl --set-default-version 2强制系统把新装的发行版默认切到 WSL2。最后重新打开 PowerShell运行wsl --status确认输出里没有红色错误提示。其实这个报错有点虚张声势说无法安全验证听着很吓人实际上 90% 的情况就是内核版本太老。你先别急着重装 WSL按上面三步走基本都能解决。2.3 启动容器并验证服务状态环境搞定后Docker Compose 启动就比较顺利了docker compose up -d启动完成后我会习惯性检查三件事容器状态、日志输出、端口监听。docker compose ps docker compose logs --tail100正常状态下OpenClaw 容器应该是Up状态日志里能看到成功连接模型 API 的提示。如果你配置了多个助手启动时日志也会列出每个助手加载的模型和人格信息这时候基本可以确认网关已经就绪了。顺带提一句如果容器一直重启先别急着看代码错误优先查网络连通性和模型 API 的 Key 配置。大部分容器起不来的问题都出在这两处。3. 创建 Telegram Bot 并调好 Topics 权限最容易翻车的一环很多人部署 OpenClaw 本身很顺利反而在 Telegram 侧栽了跟头。Telegram Bot 的权限配置非常细差一个开关就可能导致 Bot 收不到任何普通消息。3.1 BotFather 创建 Bot 并保存 Token打开 Telegram搜索 BotFather发送/newbot按提示输入 Bot 显示名称和用户名。创建完成后 BotFather 会返回一个 token形如123456:ABC-DEF...。这个 token 就是 OpenClaw 连接 Telegram 的钥匙。我的建议是立刻把它存到一个本地密码管理器里不要直接贴在群聊或者代码仓库里。Token 泄露意味着别人可以直接控制你的 Bot。3.2 关键开关关闭隐私模式与开启群组模式这一步是整套方案里最容易踩的坑。Bot 默认开启隐私模式Privacy Mode在这种模式下Bot 只能收到命令消息以/开头以及针对它的回复收不到普通用户随便发的日常消息。这显然不能满足我们的需求——用户在每个 Topic 里发的都是普通对话Bot 必须能接收到所有消息。关闭隐私模式的操作给 BotFather 发送/setprivacy选择你的 Bot然后选择Disable。这一步完成后Bot 才能看到群里的所有消息。给 BotFather 发送/setjoingroup选择Enable允许 Bot 被加入群组。做完这两步Bot 的基本权限才算准备好。3.3 创建群组并开启 Topics 模式建群后默认是不开 Topics 的需要在群设置里手动开启进入群设置 -「群组类型」- 开启「话题Topics」。开启后群内会自动创建一个General话题然后你就可以通过群底部的创建话题按钮添加新话题了。在这个方案里我建议按助手的职责命名话题比如写作文案、代码调试、日常问答。话题名字将来会直接参与路由匹配起好名字能省不少事。3.4 把 Bot 拉进群并给足权限在群成员管理里把 Bot 添加进来然后在群设置中检查 Bot 的权限权限项是否必需原因读取消息必需读不到消息就没法做任何处理发送消息必需回答要发回群里管理话题强烈建议部分操作需要创建或归档话题时用得上删除消息可选失败场景下清理错误回复时方便需要提醒的是如果你在 Bot 还在隐私模式下就把它拉进群之后才用 BotFather 关闭隐私模式通常需要把 Bot 从群里移除再重新添加一次权限开关才会真正生效。这个细节我后来是在日志里看到消息一直进不来排查了半小时才发现的。4. 把多个 AI 助手绑到不同 TopicOpenClaw 配置实操环境通了、Bot 也进群了接下来就是重头戏——把 OpenClaw 里的助手和 Telegram Topic 映射起来。4.1 OpenClaw 里一个 assistant 是什么在 OpenClaw 的语境下一个 assistant 就是一个独立运行的 AI 助手实例它包含四样东西System Prompt人格与职责设定、模型选择GPT 还是本地 Qwen、推理参数温度、最大 token 数、上下文长度、工具或插件是否需要联网、是否需要读写文件。我先配置了两个助手做验证。一个是writer专门写文章和文案语气温和、结构化输出一个是coder专门处理编程问题输出代码时带注释。两个助手使用同一个模型后端但 System Prompt 完全不同温度设置也不一样——写作用 0.7代码用 0.2。4.2 编写多助手配置OpenClaw 的配置文件是 YAML 格式大致长这样具体字段名称以你安装的版本为准但结构是通用的assistants: - name: writer description: 负责写作、文案、创意内容 model: qwen2.5:3b temperature: 0.7 system_prompt: | 你是一位资深文案编辑擅长中长文写作。 回答要求结构清晰、语言自然避免空话。 - name: coder description: 负责编程问题、代码调试 model: qwen2.5:3b temperature: 0.2 system_prompt: | 你是一位资深软件工程师擅长代码编写与调试。 回答时先给出思路再给出完整可运行的代码。配置文件的要点是每个 assistant 必须有独立名称不要重名description这段将来在日志和路由匹配里很有用System Prompt 里明确你是谁、怎么回答因为这是隔离助手行为的关键。4.3 拿到 Topic ID 并完成路由映射Telegram 的 Topic 创建后会自动分配一个message_thread_id也就是 OpenClaw 做消息路由的依据。怎么拿到这个 ID 呢最直接的方法是先在群里往某个 Topic 发一条消息然后去看 OpenClaw 的日志日志里会打印收到的 Telegram 消息结构其中就包含message_thread_id字段。拿到 ID 后在配置里做映射telegram: token: 你的Bot Token routes: - topic_id: 12345 assistant: writer - topic_id: 67890 assistant: coder - fallback: writer这里我默认没有匹配到特定 Topic 的消息会落到fallback指定的助手避免出现消息进来了但没人处理的情况。关于 Topic ID 我有两个经验第一不同环境的 ID 不通用测试环境拿到的 ID 和生产环境不一样要重新取第二如果你删除了一个 Topic 再重建即便名字一样ID 也变了需要更新配置并重启。后来我更倾向于用 Topic 的标题做匹配这样对运维友好一些——不过有些版本只支持 ID 匹配那就老老实实用 ID。4.4 把本地模型 Qwen2.5-3B 关联到 OpenClaw热词里有人在问 qwen2.5-3b 关联到 openclaw这个操作其实不复杂关键在于用 Ollama 跑本地模型然后让 OpenClaw 通过 OpenAI 兼容接口调用它。先在宿主机或局域网内另一台机器安装 Ollama拉取模型ollama pull qwen2.5:3b启动 Ollama 服务后在 OpenClaw 的模型配置里设置model_providers: - name: local-qwen type: ollama base_url: http://host.docker.internal:11434 default_model: qwen2.5:3b这句host.docker.internal是 Docker 容器访问宿主机的专用地址。如果你和我一样把 Ollama 和 OpenClaw 装在同一台电脑上就必须用这个地址而不是localhost——容器里的localhost指向容器自己。关联本地模型最大的价值在于像日常问答草稿生成这类轻量任务可以完全走本地模型不消耗 API 配额只有写作、代码这类高质量需求才走到云端模型。省钱和隐私兼得。5. 实测所谓完全独立到底做到了什么程度配置全部完成重启 OpenClaw接下来是最让人兴奋的验证环节。我实际测试了三个维度上下文连续性、跨 Topic 隔离性、路由准确性。5.1 同一个 Topic 内的上下文连续性我先在写作文案这个 Topic 里发了一句帮我写一段欢迎新员工的致辞200字以内语气亲切。助手回了一版我追问了一句把第二段改得更正式一些。这一轮追问如果能在上下文里生效说明同一个 Topic 的消息被正确合并到了同一个会话上下文中。实测结果符合预期——助手知道 第二段 指的是上一轮回复里的第二段说明 OpenClaw 按 Topic 隔离会话 ID 的机制是生效的。5.2 不同 Topic 之间的记忆隔离验证隔离性是这套方案的核心卖点我的测试方法比较粗暴先在日常问答话题里告诉助手我的名字叫老周职业是化工行业的项目经理然后切到代码调试话题问它我刚刚告诉你我叫什么名字你还记得吗如果隔离机制正常代码调试助手应该完全不知道这段对话历史它会回答抱歉我不清楚或者我们没有聊过这个话题。实测结果确实是后者——两个助手各自维护独立的会话记录互不干扰。这背后其实不只是 System Prompt 的隔离更是会话上下文的隔离。OpenClaw 在内部给每个 TopicUser 的组合生成了独立的 session key消息进来后按 key 读取对应的历史记录。所以我们说的完全独立核心是上下文独立而不是模型实例必须独立跑一份。5.3 路由准确性和兜底机制我分别往两个 Topic 发消息观察 OpenClaw 日志中路由的结果确认消息 - Topic - Assistant的链路是准确的。这里还要测试兜底我故意在General话题没有配置映射里发了一条消息日志显示消息被fallback助手处理了。兜底机制很重要它保证了即使你新建了一个话题忘了配置Bot 也不会装死至少有个默认助手在干活。6. 运维记录我踩过的坑和常用排查顺序配置跑通之后剩下的就是日常使用和偶尔排错了。我把自己遇到频率最高的几个问题整理出来按排查顺序写清楚。6.1 Bot 收不到任何消息这是最常见的问题。排查顺序我建议这样来先在群里直接发一条普通文本消息如果 Bot 没有任何反应第一件事打开 OpenClaw 日志看有没有显示收到 Telegram 更新。如果连日志都没有说明 webhook 和 getUpdates 之间可能有冲突——Telegram 的 Bot 只能二选一开着 webhook 就不能用 getUpdates。然后检查 Bot 的隐私模式是否关闭。我在前面强调过隐私模式没关的话普通消息根本不会推给 Bot。去 BotFather 重新执行一遍/setprivacy选 Disable。最后检查 OpenClaw 配置里的 token 是否正确。这里有个小细节token 里包含冒号复制的时候很容易在行首行尾带上多余空格导致认证失败。建议用编辑器开启显示空白字符核对一遍。6.2 消息路由到了错误的助手你会发现某个 Topic 里发消息回答内容明显是另一个助手的风格。这种问题的根因几乎都是message_thread_id配置错了。建议在 OpenClaw 日志里找到消息的原始结构核对实际收到的message_thread_id和配置里写的是否一致。另外注意 Telegram 里回复某条消息和直接在 Topic 里发言携带的 thread ID 可能不同尽量以直接在 Topic 底部输入框发送为准。6.3 本地模型响应慢或者超时Qwen2.5-3B 在纯 CPU 环境下跑单次响应可能要十几秒甚至更长。如果你的机器没有 N 卡建议在 OpenClaw 推理配置里把request_timeout调大一些比如从默认的 30 秒调到 120 秒。如果实在慢得难受我的经验是本地模型负责简单任务翻译、关键词提取、文本改写云端模型负责复杂任务长篇写作、代码生成。在 OpenClaw 里给不同的 assistant 配不同的模型 provider就是为这种混合场景准备的。6.4 常用日志命令调试期间我反复用的三个命令# 查看 OpenClaw 全部日志 docker compose logs -f # 只看最近 200 行过滤 Telegram 相关 docker compose logs --tail200 | grep -i telegram # 查看路由命中情况 docker compose logs | grep -i route日志里会打印每条消息的 source、thread_id、assistant 名称排错时一目了然。最后再分享一个小技巧我给每个 Topic 在 Telegram 里配了一个固定表情图标比如写作话题用笔的图标代码话题用括号图标。这样不管是谁打开群聊一眼就能看出哪个话题是干什么的。整套方案我现在用了快两个月一个 Bot、一个群、六个话题工作、写作、个人助理各司其职维护成本几乎为零。如果你也想把所有 AI 助手收拢到一个入口照着这条路线走应该能少踩不少坑。
OpenClaw + Telegram Topics：一个Bot管理多个独立AI助手的完整指南
先说个真实的场景我本地原来跑着三个独立的 Telegram Bot一个管写作一个管代码一个做日常问答。三个 bot 就要三套 token、三份部署配置、三条消息回调链路每次想调一下模型参数得分别改三个地方。后来我把它们全部收编进了一个 Bot借助 Telegram 群组的 Topics话题功能做消息路由配合 OpenClaw 这个自托管的 AI 助手网关统一管理一个 Bot 就同时撑起了多个完全独立的 AI 助手每个助手有自己独立的 System Prompt、独立的模型配置、独立的上下文记忆互相不串门。这篇文章就把这套方案的完整部署过程和踩坑记录写出来。适合那些想用 Telegram 做统一 AI 入口、又不想同时维护一大堆 Bot 的人也适合正在折腾 OpenClaw 但卡在部署或路由配置上的朋友。1. 为什么是 OpenClaw Telegram Topics先理清需求和分工在设计任何方案之前我习惯先把我要解决什么问题写清楚。这套组合的核心问题只有一个怎样用最小的维护成本跑尽可能多的独立 AI 助手。1.1 一个 Bot 只能一个角色的困境很多人刚开始玩 AI 助手的时候都是一个 Bot 走天下——把写作、编程、翻译、闲聊全部塞进同一个 System Prompt 里。短期看没问题用久了就会发现几个很烦的现象上下文互相污染。你和它聊了三轮代码调试转头让它帮你写一段朋友圈文案它大概率还带着代码变量的思维回出来的文案冷冰冰。原因很简单同一个会话只有一个上下文窗口前面聊的内容会一直影响后面的输出。System Prompt 难以兼顾。想让一个助手既专业又幽默还精通代码prompt 会写得越来越长模型对每部分指令的遵循度反而下降。我拆成三个独立助手后每个 prompt 都短小精悍效果明显更好。部署和管理成本线性增长。每新增一个 Bot就要注册一个 BotFather token多配一条 webhook 或轮询通道多维护一份环境变量。时间一长光理顺这些 token 之间的关系就够喝一壶。所以我的思路是入口统一大脑分叉。也就是一个 Bot 只做消息收件箱至于这条消息该交给哪个 AI 助手处理由上层网关根据消息特征去路由。1.2 Topics 提供的天然消息隔离舱Telegram 群组的 Topics 功能也叫 Forum Mode本质上是在一个群聊里开多个子线程。每个 Topic 单独拥有自己的消息流、标题和通知设置。最关键的一点是Bot 在接收消息时每条消息都会携带一个message_thread_id字段。这个字段就是天然的房间号。Bot 只要读一下房间号就能判断这条消息应该进哪条处理管线。这意味着不需要多个 Bot。一个 Bot 在群里的所有 Topic 中都能收到消息只需要根据message_thread_id转发给不同的处理逻辑。不需要自己写复杂的状态机。Telegram 服务端已经帮你把不同话题的消息流隔离开了你只需要做映射不用做过滤。用户侧体验极好。大家还在同一个群里通过顶部的话题标签切换助手视觉上清清楚楚不会出现多 Bot 轰炸聊天列表的情况。1.3 OpenClaw 在整套方案里扮演什么角色OpenClaw 是一个自托管的 AI 代理编排框架简单说它就是一个AI 助手网关。它负责三件事连接各种聊天渠道Telegram、Teams、Discord 等、管理多个助手实例每个实例有自己的模型、人格、工具、维护会话记忆。在 Telegram Topics 这套方案里OpenClaw 处在中间层。Telegram 群组负责消息入口和隔离OpenClaw 负责消息路由和模型调度。我甚至不需要自己写 bot 代码只需要在 OpenClaw 的配置文件里声明好各个助手、声明好 Telegram 渠道的接入参数网关就会自动把不同 Topic 的消息分发到对应的助手。这套分工的好处是每一层只干一件事出了问题也容易定位收不到消息查 Telegram 接入路由错了查 OpenClaw 配置回答质量差查模型设置。2. 先把环境跑起来OpenClaw 安装与 Windows 下的 WSL2 折腾记录先说环境结论如果你有一台 Linux 服务器或者 Mac安装过程会顺畅很多如果你跟我一样主力机是 Windows那大概率会在 WSL2 环节卡一下。2.1 部署方式怎么选OpenClaw 官方提供了几种安装方式我理解下来最适合大部分人的是 Docker Compose 方案。其他几种我也列一下方便你按自己的情况选部署方式优点需要注意的坑Docker Compose依赖隔离、升级方便、配置文件清晰需要先装 DockerWindows 下需要 WSL2 后端官方一键脚本命令少、上手快脚本依赖特定系统环境Windows 下经常触发 WSL 检测源码手动部署可定制性最高、方便二次开发要自己装 Node.js/Python 依赖环境变量容易漏配我自己最后选了 Docker Compose。原因很简单多助手配置、模型接入配置都集中在docker-compose.yml和对应的配置文件里出了问题可以整个容器删掉重来不会污染宿主机环境。2.2 无法安全验证 WSL2 环境的排查过程如果你在 Windows 上运行 OpenClaw 的某些安装脚本很可能会遇到类似这样的报错提示无法安全验证 WSL2 环境。请在 PowerShell 中运行 wsl -- status 检查当前状态。我第一次看到这个提示的时候第一反应是OpenClaw 安装脚本在检查什么第二反应是我的 WSL 明明能用啊。后来理清楚了OpenClaw 的安装脚本会检查当前 WSL 是不是 2.0 版本并且要确认默认发行版已经初始化。如果你的 WSL 内核版本过旧、或者默认版本还是 WSL1脚本就会拒绝继续执行。按这个顺序排查先打开 PowerShell运行wsl --status看输出里有没有 默认版本: 2 或者 Default Version: 2。如果显示的是 1就说明系统默认用 WSL1 跑发行版脚本当然认为环境不安全。运行wsl --update更新 WSL 内核。这一步很关键很多人的 WSL 内核停留在 2021 年左右的老版本OpenClaw 脚本检测到内核太旧就会误判。如果更新完还是不行运行wsl --set-default-version 2强制系统把新装的发行版默认切到 WSL2。最后重新打开 PowerShell运行wsl --status确认输出里没有红色错误提示。其实这个报错有点虚张声势说无法安全验证听着很吓人实际上 90% 的情况就是内核版本太老。你先别急着重装 WSL按上面三步走基本都能解决。2.3 启动容器并验证服务状态环境搞定后Docker Compose 启动就比较顺利了docker compose up -d启动完成后我会习惯性检查三件事容器状态、日志输出、端口监听。docker compose ps docker compose logs --tail100正常状态下OpenClaw 容器应该是Up状态日志里能看到成功连接模型 API 的提示。如果你配置了多个助手启动时日志也会列出每个助手加载的模型和人格信息这时候基本可以确认网关已经就绪了。顺带提一句如果容器一直重启先别急着看代码错误优先查网络连通性和模型 API 的 Key 配置。大部分容器起不来的问题都出在这两处。3. 创建 Telegram Bot 并调好 Topics 权限最容易翻车的一环很多人部署 OpenClaw 本身很顺利反而在 Telegram 侧栽了跟头。Telegram Bot 的权限配置非常细差一个开关就可能导致 Bot 收不到任何普通消息。3.1 BotFather 创建 Bot 并保存 Token打开 Telegram搜索 BotFather发送/newbot按提示输入 Bot 显示名称和用户名。创建完成后 BotFather 会返回一个 token形如123456:ABC-DEF...。这个 token 就是 OpenClaw 连接 Telegram 的钥匙。我的建议是立刻把它存到一个本地密码管理器里不要直接贴在群聊或者代码仓库里。Token 泄露意味着别人可以直接控制你的 Bot。3.2 关键开关关闭隐私模式与开启群组模式这一步是整套方案里最容易踩的坑。Bot 默认开启隐私模式Privacy Mode在这种模式下Bot 只能收到命令消息以/开头以及针对它的回复收不到普通用户随便发的日常消息。这显然不能满足我们的需求——用户在每个 Topic 里发的都是普通对话Bot 必须能接收到所有消息。关闭隐私模式的操作给 BotFather 发送/setprivacy选择你的 Bot然后选择Disable。这一步完成后Bot 才能看到群里的所有消息。给 BotFather 发送/setjoingroup选择Enable允许 Bot 被加入群组。做完这两步Bot 的基本权限才算准备好。3.3 创建群组并开启 Topics 模式建群后默认是不开 Topics 的需要在群设置里手动开启进入群设置 -「群组类型」- 开启「话题Topics」。开启后群内会自动创建一个General话题然后你就可以通过群底部的创建话题按钮添加新话题了。在这个方案里我建议按助手的职责命名话题比如写作文案、代码调试、日常问答。话题名字将来会直接参与路由匹配起好名字能省不少事。3.4 把 Bot 拉进群并给足权限在群成员管理里把 Bot 添加进来然后在群设置中检查 Bot 的权限权限项是否必需原因读取消息必需读不到消息就没法做任何处理发送消息必需回答要发回群里管理话题强烈建议部分操作需要创建或归档话题时用得上删除消息可选失败场景下清理错误回复时方便需要提醒的是如果你在 Bot 还在隐私模式下就把它拉进群之后才用 BotFather 关闭隐私模式通常需要把 Bot 从群里移除再重新添加一次权限开关才会真正生效。这个细节我后来是在日志里看到消息一直进不来排查了半小时才发现的。4. 把多个 AI 助手绑到不同 TopicOpenClaw 配置实操环境通了、Bot 也进群了接下来就是重头戏——把 OpenClaw 里的助手和 Telegram Topic 映射起来。4.1 OpenClaw 里一个 assistant 是什么在 OpenClaw 的语境下一个 assistant 就是一个独立运行的 AI 助手实例它包含四样东西System Prompt人格与职责设定、模型选择GPT 还是本地 Qwen、推理参数温度、最大 token 数、上下文长度、工具或插件是否需要联网、是否需要读写文件。我先配置了两个助手做验证。一个是writer专门写文章和文案语气温和、结构化输出一个是coder专门处理编程问题输出代码时带注释。两个助手使用同一个模型后端但 System Prompt 完全不同温度设置也不一样——写作用 0.7代码用 0.2。4.2 编写多助手配置OpenClaw 的配置文件是 YAML 格式大致长这样具体字段名称以你安装的版本为准但结构是通用的assistants: - name: writer description: 负责写作、文案、创意内容 model: qwen2.5:3b temperature: 0.7 system_prompt: | 你是一位资深文案编辑擅长中长文写作。 回答要求结构清晰、语言自然避免空话。 - name: coder description: 负责编程问题、代码调试 model: qwen2.5:3b temperature: 0.2 system_prompt: | 你是一位资深软件工程师擅长代码编写与调试。 回答时先给出思路再给出完整可运行的代码。配置文件的要点是每个 assistant 必须有独立名称不要重名description这段将来在日志和路由匹配里很有用System Prompt 里明确你是谁、怎么回答因为这是隔离助手行为的关键。4.3 拿到 Topic ID 并完成路由映射Telegram 的 Topic 创建后会自动分配一个message_thread_id也就是 OpenClaw 做消息路由的依据。怎么拿到这个 ID 呢最直接的方法是先在群里往某个 Topic 发一条消息然后去看 OpenClaw 的日志日志里会打印收到的 Telegram 消息结构其中就包含message_thread_id字段。拿到 ID 后在配置里做映射telegram: token: 你的Bot Token routes: - topic_id: 12345 assistant: writer - topic_id: 67890 assistant: coder - fallback: writer这里我默认没有匹配到特定 Topic 的消息会落到fallback指定的助手避免出现消息进来了但没人处理的情况。关于 Topic ID 我有两个经验第一不同环境的 ID 不通用测试环境拿到的 ID 和生产环境不一样要重新取第二如果你删除了一个 Topic 再重建即便名字一样ID 也变了需要更新配置并重启。后来我更倾向于用 Topic 的标题做匹配这样对运维友好一些——不过有些版本只支持 ID 匹配那就老老实实用 ID。4.4 把本地模型 Qwen2.5-3B 关联到 OpenClaw热词里有人在问 qwen2.5-3b 关联到 openclaw这个操作其实不复杂关键在于用 Ollama 跑本地模型然后让 OpenClaw 通过 OpenAI 兼容接口调用它。先在宿主机或局域网内另一台机器安装 Ollama拉取模型ollama pull qwen2.5:3b启动 Ollama 服务后在 OpenClaw 的模型配置里设置model_providers: - name: local-qwen type: ollama base_url: http://host.docker.internal:11434 default_model: qwen2.5:3b这句host.docker.internal是 Docker 容器访问宿主机的专用地址。如果你和我一样把 Ollama 和 OpenClaw 装在同一台电脑上就必须用这个地址而不是localhost——容器里的localhost指向容器自己。关联本地模型最大的价值在于像日常问答草稿生成这类轻量任务可以完全走本地模型不消耗 API 配额只有写作、代码这类高质量需求才走到云端模型。省钱和隐私兼得。5. 实测所谓完全独立到底做到了什么程度配置全部完成重启 OpenClaw接下来是最让人兴奋的验证环节。我实际测试了三个维度上下文连续性、跨 Topic 隔离性、路由准确性。5.1 同一个 Topic 内的上下文连续性我先在写作文案这个 Topic 里发了一句帮我写一段欢迎新员工的致辞200字以内语气亲切。助手回了一版我追问了一句把第二段改得更正式一些。这一轮追问如果能在上下文里生效说明同一个 Topic 的消息被正确合并到了同一个会话上下文中。实测结果符合预期——助手知道 第二段 指的是上一轮回复里的第二段说明 OpenClaw 按 Topic 隔离会话 ID 的机制是生效的。5.2 不同 Topic 之间的记忆隔离验证隔离性是这套方案的核心卖点我的测试方法比较粗暴先在日常问答话题里告诉助手我的名字叫老周职业是化工行业的项目经理然后切到代码调试话题问它我刚刚告诉你我叫什么名字你还记得吗如果隔离机制正常代码调试助手应该完全不知道这段对话历史它会回答抱歉我不清楚或者我们没有聊过这个话题。实测结果确实是后者——两个助手各自维护独立的会话记录互不干扰。这背后其实不只是 System Prompt 的隔离更是会话上下文的隔离。OpenClaw 在内部给每个 TopicUser 的组合生成了独立的 session key消息进来后按 key 读取对应的历史记录。所以我们说的完全独立核心是上下文独立而不是模型实例必须独立跑一份。5.3 路由准确性和兜底机制我分别往两个 Topic 发消息观察 OpenClaw 日志中路由的结果确认消息 - Topic - Assistant的链路是准确的。这里还要测试兜底我故意在General话题没有配置映射里发了一条消息日志显示消息被fallback助手处理了。兜底机制很重要它保证了即使你新建了一个话题忘了配置Bot 也不会装死至少有个默认助手在干活。6. 运维记录我踩过的坑和常用排查顺序配置跑通之后剩下的就是日常使用和偶尔排错了。我把自己遇到频率最高的几个问题整理出来按排查顺序写清楚。6.1 Bot 收不到任何消息这是最常见的问题。排查顺序我建议这样来先在群里直接发一条普通文本消息如果 Bot 没有任何反应第一件事打开 OpenClaw 日志看有没有显示收到 Telegram 更新。如果连日志都没有说明 webhook 和 getUpdates 之间可能有冲突——Telegram 的 Bot 只能二选一开着 webhook 就不能用 getUpdates。然后检查 Bot 的隐私模式是否关闭。我在前面强调过隐私模式没关的话普通消息根本不会推给 Bot。去 BotFather 重新执行一遍/setprivacy选 Disable。最后检查 OpenClaw 配置里的 token 是否正确。这里有个小细节token 里包含冒号复制的时候很容易在行首行尾带上多余空格导致认证失败。建议用编辑器开启显示空白字符核对一遍。6.2 消息路由到了错误的助手你会发现某个 Topic 里发消息回答内容明显是另一个助手的风格。这种问题的根因几乎都是message_thread_id配置错了。建议在 OpenClaw 日志里找到消息的原始结构核对实际收到的message_thread_id和配置里写的是否一致。另外注意 Telegram 里回复某条消息和直接在 Topic 里发言携带的 thread ID 可能不同尽量以直接在 Topic 底部输入框发送为准。6.3 本地模型响应慢或者超时Qwen2.5-3B 在纯 CPU 环境下跑单次响应可能要十几秒甚至更长。如果你的机器没有 N 卡建议在 OpenClaw 推理配置里把request_timeout调大一些比如从默认的 30 秒调到 120 秒。如果实在慢得难受我的经验是本地模型负责简单任务翻译、关键词提取、文本改写云端模型负责复杂任务长篇写作、代码生成。在 OpenClaw 里给不同的 assistant 配不同的模型 provider就是为这种混合场景准备的。6.4 常用日志命令调试期间我反复用的三个命令# 查看 OpenClaw 全部日志 docker compose logs -f # 只看最近 200 行过滤 Telegram 相关 docker compose logs --tail200 | grep -i telegram # 查看路由命中情况 docker compose logs | grep -i route日志里会打印每条消息的 source、thread_id、assistant 名称排错时一目了然。最后再分享一个小技巧我给每个 Topic 在 Telegram 里配了一个固定表情图标比如写作话题用笔的图标代码话题用括号图标。这样不管是谁打开群聊一眼就能看出哪个话题是干什么的。整套方案我现在用了快两个月一个 Bot、一个群、六个话题工作、写作、个人助理各司其职维护成本几乎为零。如果你也想把所有 AI 助手收拢到一个入口照着这条路线走应该能少踩不少坑。
