Telegram 无代码做 AI Bot？Managed Bots、BotFather 和真实门槛一次讲清

Article type: tutorial
Voice: operator

如果你在 X 上看到“Telegram 现在支持无代码做 AI Bot”的说法，先别急着把它理解成“一键生成完整 AI Agent”。Telegram 这次真正开放的是 Managed Bots：它让一个管理 bot 可以替用户创建、接管并后续管理新的 bot。

这篇只讲 Managed Bots 这条官方创建与接管链路怎么跑通，不把“模型、知识库、状态管理、计费和运维”混进来。换句话说：这不是“AI bot 全栈教程”，而是“先把 Telegram bot 的开通与托管流程产品化”的最小教程。

如果你现在就在搭 AI 工作流，可以顺手对照 TG Hubs 的 工作流与 Agent 主题页；如果你更关心 bot 创建之后，后端 Agent 运行时该自己拼还是接现成框架，也可以再看前面的 OpenAI Agents SDK 边界拆解。

先说准：这篇教程到底教什么

截至 2026-04-26，Telegram 官方文档已经明确补上了这几样能力：

• Telegram Bot Features 页面新增 Managed Bots 章节；
• Bot API 9.6 新增 getManagedBotToken、replaceManagedBotToken、ManagedBotUpdated；
• 官方支持 https://t.me/newbot/{manager_bot_username}/{suggested_bot_username}?name={suggested_bot_name} 这种建 bot 深链。

所以这篇教程的目标只有一个：让你的管理 bot 能把用户创建的新 bot 接回来，并拿到它的 token。

它不解决这些事：

• 你的 AI 模型接哪家；
• 知识库怎么做；
• 多租户账单怎么算；
• RAG、工具调用、上下文记忆怎么接。

这些属于 bot 创建之后的系统题。如果你后面要把它做成真正可规模化的产品，迟早还要回到执行环境、上下文边界和工具治理，这一层可以再对照 Cloudflare 内部 AI 工程栈那篇拆解。

跑这条链路前，你要准备什么

你至少需要：

• 一个已经由 @BotFather 创建好的 bot，作为 管理 bot；
• 一个能接收 Bot API updates 的后端；
• 基本的 token 存储能力；
• 愿意把“每用户一个 bot”当成产品交付模式来做，而不是只是试个聊天 demo。

如果你只是想体验一个现成 AI bot，这篇就不是最短路径；它更适合：

• 想做 Telegram bot SaaS；
• 想给每个客户、门店、群组、创作者分发独立 bot；
• 想把 bot 开通流程从“手工发 token”改成“像 SaaS onboarding 一样顺”。

Step 1：先准备一个管理 bot

先在 @BotFather 里创建一个普通 bot，或者选你现有的 bot 作为管理 bot。

这个 bot 的职责不是长期给最终用户聊天，而是：

• 发起创建流程；
• 接收 managed_bot 更新；
• 调用 getManagedBotToken 取回新 bot token；
• 把新 bot 绑定到你的租户系统或业务后台。

如果你把“管理 bot”和“最终用户使用的 bot”混成一个，后面权限、租户隔离和排障都会更乱。

Step 2：在 BotFather Mini App 里打开 Bot Management Mode

Telegram 官方 Bot Features 页面给出的动作很短：

• 选择一个现有 bot，或先创建一个新 bot；
• 打开 BotFather 的 Mini App；
• 给这个 bot 启用 Bot Management Mode。

这一项必须先开。因为如果没开，后面的典型症状就是：

• 用户可以点你的创建链接；
• 看起来也像是在创建；
• 但你的管理 bot 根本收不到能接住这次创建的更新。

Step 3：生成给用户的 t.me/newbot/... 深链

Telegram 官方支持的深链格式是：

https://t.me/newbot/{manager_bot_username}/{suggested_bot_username}?name={suggested_bot_name}

一个最小例子：

https://t.me/newbot/ManagerBot/CoolAIAgentBot?name=Cool+AI+Agent

用户打开这个链接后，会看到一个创建窗口：

• bot 的 @username 已预填；
• bot 的显示名已预填；
• 但两者仍可编辑。

这里先记住第一个失败点

如果你预填的 suggested_bot_username 已经被占用，用户必须改名后才能继续。所以不要把深链当成“百分百自动成功”；更好的做法是：

• 预先生成更不容易冲突的建议用户名；
• 或者在你的产品里提前告诉用户“用户名可能需要手改”。

Step 4：用户确认创建后，接收 managed_bot 更新

用户确认之后，管理 bot 会收到一个包含 ManagedBotUpdated 的更新。Telegram 官方文档对这个对象的定义很关键：

• user：创建这个 bot 的用户；
• bot：这个新 bot 本身的信息；
• token 不直接放在这里，要再调用一次 getManagedBotToken 去取。

一个最小示意结构，可以理解成这样：

{
  "update_id": 123456789,
  "managed_bot": {
    "user": {
      "id": 111111111,
      "is_bot": false,
      "first_name": "Alice"
    },
    "bot": {
      "id": 222222222,
      "is_bot": true,
      "first_name": "Cool AI Agent",
      "username": "CoolAIAgentBot"
    }
  }
}

这里最容易拿错的是 ID。

后面调 getManagedBotToken 时，你要用的是 新 bot 的 bot.id，不是创建者的 user.id。Telegram Bot API 9.6 对 getManagedBotToken 的参数说明写得很明确：它需要的是“被管理 bot 的 user identifier”，也就是这个 bot 自身的标识。

Step 5：用 getManagedBotToken 取回新 bot token

Bot API 9.6 文档给出的接口定义是：

• 方法名：getManagedBotToken
• 必填参数：user_id
• 成功返回：String 类型 token

最小请求形态可以写成这样：

curl -s "https://api.telegram.org/bot<MANAGER_BOT_TOKEN>/getManagedBotToken" \
  -d "user_id=<MANAGED_BOT_BOT_ID>"

这里的：

• <MANAGER_BOT_TOKEN> 是你的管理 bot token；
• <MANAGED_BOT_BOT_ID> 是上一步 managed_bot.bot.id。

如果你这里传成了创建者 user.id，最常见的结果不是“偶尔不稳”，而是整个接管流程直接失败。

Step 6：第一时间用 getMe 验证新 token

拿到新 token 后，不要立刻去接模型、接知识库、接 webhook。先做最小验收：

curl -s "https://api.telegram.org/bot<NEW_MANAGED_BOT_TOKEN>/getMe"

你至少要确认这 3 个字段

• id
• username
• is_bot

如果返回的数据能对上你刚创建的新 bot，比如：

• is_bot 为 true；
• username 是你预期的 CoolAIAgentBot；
• id 和前面 managed_bot.bot.id 一致；

那就说明三件事已经成立：

• 新 bot 已创建成功；
• token 已被你的管理 bot 正确取回；
• 这个新 bot 已经可以被你的后台正式接管。

这一步就是这篇教程最小可验证的完成态。 如果 getMe 都没过，后面的 AI 对话、RAG、工具调用都先别接。

Step 7：需要轮换 token 时，用 replaceManagedBotToken

Telegram 这次不只给了 getManagedBotToken，还给了 replaceManagedBotToken。

它的接口定义同样很直接：

• 方法名：replaceManagedBotToken
• 必填参数：user_id
• 成功返回：新的 token 字符串

最小请求形态：

curl -s "https://api.telegram.org/bot<MANAGER_BOT_TOKEN>/replaceManagedBotToken" \
  -d "user_id=<MANAGED_BOT_BOT_ID>"

更稳的做法通常不是“直接轮换完就上线”，而是：

1. 先记录旧 token 当前绑定的流量与 webhook 状态；
2. 轮换后立刻拿新 token 跑一次 getMe；
3. 确认新 token 生效后，再让业务流量切过去；
4. 不要假设旧 token 还能继续兜底。

这条链路最常见的 4 个坑

1）没开 Bot Management Mode

症状：用户能点深链，但你的管理 bot 接不住创建结果。
优先检查：BotFather Mini App 里对应 bot 的模式是否真的开启。

2）把 user.id 和 bot.id 搞反了

症状：getManagedBotToken 调不通，或返回结果不符合预期。
优先检查：你传入的 user_id 是否来自 managed_bot.bot.id，而不是创建者 managed_bot.user.id。

3）用户名冲突

症状：用户在创建页卡住，无法沿用你给的建议用户名。
优先检查：你给的 suggested_bot_username 是否过于常见，是否缺少品牌或租户前缀。

4）拿到 token 后没先跑 getMe

症状：你直接接模型或业务逻辑，最后排障时不知道是 Telegram 创建链路坏了，还是你自己的 AI 后端坏了。
优先检查：先把 Telegram 层的验收做成固定动作，别一开始就把多层错误叠在一起。

跑通后的 5 项检查

发布到生产前，至少确认这 5 件事：

• [ ] 管理 bot 能稳定收到 managed_bot 更新
• [ ] 你能从更新里准确取到 managed_bot.bot.id
• [ ] getManagedBotToken 能取回新 bot token
• [ ] 新 token 跑 getMe 时，id、username、is_bot 都能对上
• [ ] token 已按租户维度做加密存储，并且你测试过 replaceManagedBotToken 的轮换链路

如果这 5 项里有 2 项还没稳，不建议你马上把“AI bot 平台”这顶帽子扣上去。因为 Telegram 这次解决的是 bot 创建与接管，不是整个 AI 产品后端。

Sources

• Telegram Bot Features: Managed Bots / Creating Your Own Management Bot
• Telegram Bot API 9.6 changelog
• Telegram Bot FAQ
• 触发线索：X 上关于 Telegram bot 新能力传播的视频与帖子（2026-04-26）