一天内创建10个Telegram Bot
如果有人问我"你今天干了什么"，我的回答是："创建了10个Telegram bot。"听起来像在吹牛，但确实就是一天的事。这篇记录从5个bot扩展到10个的全过程，以及多agent路由中那些让人抓狂的配置细节。
从5到10
最初的OpenClaw部署只有5个agent，够用但不够细分。随着项目增多，一个agent承担太多角色会导致上下文混乱——你跟"学习助手"聊房产投资，它会一脸懵。所以决定按职责拆分，一个bot对应一个明确的领域。
最终的10个bot列表：
| Bot名称 | 职责 | 模型 |
|---------|------|------|
| Joe (Main) | 主管理员，总协调 | Claude Opus |
| NobData | NobData项目开发 | Claude Opus |
| Flect | Flect项目管理 | Claude Opus |
| Life | 生活助手 | Claude Opus |
| Learning | 学习笔记 | DeepSeek |
| Real-estate | 房产投资分析 | GPT-4o |
| Investment | 投资理财 | GPT-4o |
| Health | 健康管理 | DeepSeek |
| Royal | Royal项目 | Claude Opus |
| Customer-service | 客服对接 | Claude Opus |
模型分配策略
不是每个bot都需要最强的模型。我的分配原则：
项目类bot用Opus：NobData、Flect、Royal这些涉及代码开发的agent，需要强推理能力和长上下文理解。Opus虽然贵，但在代码生成和架构设计上的质量差距是明显的。
工具类bot用DeepSeek/GPT-4o：Learning和Health这类主要做信息整理和问答的agent，用性价比更高的模型完全够用。DeepSeek在中文理解上表现不错，GPT-4o则在结构化分析上有优势。
这样分配的好处是成本可控。如果10个bot都用Opus，API费用会飙升。按实际需求分配模型，既保证了关键agent的能力，又控制了整体开销。
创建过程
在Telegram上创建bot本身很快——找@BotFather，/newbot，取名，拿token，一个bot一分钟搞定。10个bot，10分钟。
真正耗时的是OpenClaw端的配置。每个bot需要：
1. 在gateway配置中添加account（Telegram token）
2. 创建对应的agent配置（模型、system prompt、工具权限）
3. 配置binding（把account绑定到agent）
4. 设置dmPolicy（控制谁可以和bot对话）
10个bot就是40项配置，任何一项出错都会导致bot无响应或路由错误。
多Agent路由的坑
这是当天最痛苦的部分。配完所有bot后，发现有些bot能正常响应，有些完全沉默。排查了一下午，最终定位到两个关键问题：
坑1：binding条目缺失
OpenClaw的路由逻辑是：收到消息 → 根据account找binding → 根据binding找agent。如果一个account没有对应的binding条目，消息就会被丢弃，不会有任何错误日志。
我的错误是：添加了account和agent，但忘了某几个bot的binding配置。结果这些bot在Telegram上看起来"在线"，但发消息过去如石沉大海。
教训：每添加一个bot，必须同时检查三个配置——account、agent、binding，缺一不可。
坑2：dmPolicy allowlist
OpenClaw默认的dmPolicy是拒绝所有DM。这是安全设计——你不希望随便一个人都能和你的bot对话。但这意味着每个新bot都需要显式配置allowlist，把允许对话的用户ID加进去。
我有几个bot配置了agent和binding，但忘了设置dmPolicy。结果我自己发消息过去也被拒绝了——因为默认策略是deny all。
更隐蔽的是，dmPolicy的allowlist是按Telegram user ID配置的，不是username。一开始我用username，怎么都不生效，后来才发现要用数字ID。
一天的成果
从早上开始规划，到晚上10个bot全部上线响应，整整一天。其中：
- 30%时间在规划和设计（哪些bot、用什么模型、职责边界）
- 20%时间在创建和基础配置
- 50%时间在调试路由问题
这个时间分配很有意思——创建本身很快，大部分时间花在了"让它们正确工作"上。这大概是所有系统集成工作的共同特点：连接容易，正确连接难。
感悟
10个bot听起来很多，但每个bot的职责都很明确。这和微服务的思路一样：与其有一个什么都做的巨型bot，不如有10个各司其职的小bot。用户知道找谁聊什么，bot知道自己该关注什么，上下文更干净，回答更准确。
当然，10个bot也带来了管理复杂度。配置同步、版本管理、模型升级，每件事都要乘以10。这是"分"的代价，但相比"合"的混乱，这个代价值得承受。
下次如果要扩展到20个bot，我会先写一个自动化脚本来处理那40项配置。重复的手工操作做第二遍就该自动化了——这是我当天最大的教训。