Telegram 开放 Bot-to-Bot Communication：AI Agent 协作的新基础设施

Telegram 官方正式支持机器人间通信（Bot-to-Bot Communication），这是其 Bot 平台近年最具实用价值的功能更新之一。

此前，Telegram 的机器人之间默认互相看不到消息——即使在同一个群组里，两个 bot 也无法直接对话。这个限制从架构上有其合理性（防滥用、控制复杂度），但也直接锁死了多 Agent 协作的可能性。

现在这个限制被有条件地放开了。

2026-08-24 更新：本文已扩充为完整指南，补充 BotFather 开启步骤、私聊互通、可运行的 Python 示例、防死循环的代码级实现，并纳入 2026 年 5 月 Guest Bots 等后续平台更新。

如何开启：BotFather 设置

所有参与互通的 bot 都要在 @BotFather 处开启 Bot-to-Bot Communication Mode：

在 @BotFather 发送 /mybots，选择目标 bot
进入 Bot Settings，打开 Bot-to-Bot Communication Mode 开关

一个常见误区是以为开了模式就能收到所有 bot 消息。实际交付取决于场景：群组里默认只收到「命令提及」和「直接回复」两类消息；想让 bot 收到群里全部 bot 消息，要么把它设为群管理员，要么在 @BotFather 用 /setprivacy 关闭 Group Privacy Mode。私聊场景则要求通信双方都开启模式，任何一方没开，调用会直接返回 USER_BOT_TO_BOT_DISABLED 错误。

三种通信场景

群组内通信

在同一个 Telegram 群组中，一个 bot 可以通过以下方式与另一个 bot 交互：

使用命令提及：/command@OtherBot
直接回复另一条来自 bot 的消息

只要对话双方中至少有一方开启了 Bot-to-Bot Communication Mode，接收方就能收到并处理这条消息。

一个典型的场景：一个负责生成代码的 contributor bot 在群里提交代码，一个 reviewer bot 直接在群里给出 review 意见，整个过程可以有人类开发者监督介入。

私聊通信

官方文档确认 bot 可以直接给另一个 bot 发私信，双方都开启 Bot-to-Bot Communication Mode 即可，未开启的一侧会收到 USER_BOT_TO_BOT_DISABLED 错误。这对「bot 把另一个 bot 当工具调用」的场景更友好，不需要再建一个群组当信道。

商业账户通信

如果一个 bot 通过 Chat Access Mode 连接到了 Telegram Business 账户，它可以向该商业账户使用的其他 bot 发送消息。发送方需要开启 Bot-to-Bot Communication Mode。

这相当于在商业工作流中把另一个 bot 当作工具来调用——预约、客户咨询、复杂任务处理都可以拆分给不同的专用 bot。

最小可用示例

两个 bot 互聊不需要任何框架，原生 Bot API 就够。下面的代码让一个 bot 只响应来自其他 bot 的消息（忽略所有人类消息），并内置去重与限速：

python

import time, requests

TOKEN = "你的bot token"
API = f"https://api.telegram.org/bot{TOKEN}"
seen = set()        # 消息去重
last_reply = 0.0    # 限速状态

def handle(msg):
    global last_reply
    frm = msg.get("from", {})
    if not frm.get("is_bot"):          # 只处理其他 bot 的消息
        return
    if msg["message_id"] in seen:
        return
    seen.add(msg["message_id"])
    if time.time() - last_reply < 2:   # 每 2 秒最多回一次
        return
    last_reply = time.time()
    requests.post(API + "/sendMessage", json={
        "chat_id": msg["chat"]["id"],
        "text": f"收到 @{frm.get('username')} 的消息：{msg.get('text', '')[:100]}",
        "reply_to_message_id": msg["message_id"],
    })

offset = 0
while True:                            # getUpdates 长轮询
    r = requests.get(API + "/getUpdates",
                     params={"offset": offset + 1, "timeout": 30}).json()
    for u in r.get("result", []):
        offset = u["update_id"]
        if "message" in u:
            handle(u["message"])

把这段代码分别部署到两个 bot 上，在群里 @ 其中一个，就会看到它们开始互相回复。回复链会持续到限速阈值把节奏压下来——这正好演示了为什么防循环措施必须落在代码层。

防死循环：从官方要求到代码实现

Telegram 在文档中明确提醒：bot-to-bot 通信很容易导致无限交互循环。开发者必须实现以下防护措施：

消息去重：识别并忽略重复消息
限速：例如每个 bot 每几秒最多回复一次
最大交互深度 / 超时：全局和按发送方、接收方分别设置
恶意对端容错：即使另一个 bot 恶意地持续快速响应，你的 bot 也必须保持稳定，否则可能导致性能下降甚至平台限制

落到代码层，对应四件事：

官方要求	实现方式
消息去重	用 `message_id`（或 `update_id`）维护已处理集合
限速	按对话、按对端 bot 分别做令牌桶，示例用了最简的全局 2 秒间隔
最大交互深度	统计 `reply_to_message_id` 回复链长度，超过 N 层直接沉默
超时	单次处理设超时，整条对话设全局截止时间

交互深度是四项里最容易被忽略的。去重和限速只能降低频率，挡不住两个「尽职尽责」的 bot 无限礼貌地互相回复。用回复链深度做硬截止，才能保证对话可终止。

2026 年 4 月之后的平台进展

这个功能上线后，Telegram 围绕 bot 生态又连发了三次相关更新：

4 月 3 日，Bot API 9.6：Managed Bots 进入 API，一个 bot 可以创建和管理其他 bot，manager bot 拿到新 bot 的控制权
5 月 7 日，AI Bot 革命更新：Guest Bots 让任何 bot 可以被 @用户名临时唤入任意私聊或群聊，且只能访问被 @ 的那条消息及其回复；bot-to-bot 通信作为正式功能全面推送；bot 回复支持流式输出；用户还能在 Settings > Chat Automation 里把 bot 连接到自己的账号代回复消息
6 月 11 日，Rich Messages：sendRichMessage 与 sendRichMessageDraft 让 bot 能以流式方式发送带格式的富文本，AI 回复的观感进一步逼近打字机效果

把这三次更新连起来看，Telegram 的意图相当清晰：bot 可以被创建（Managed Bots）、被唤起（Guest Bots）、互相协作（Bot-to-Bot）、替人回复（Chat Automation），一条完整的多 Agent 基础设施链路。

对 AI Agent 生态意味着什么

这个更新最实际的影响是：Telegram 现在可以当作多 Agent 协作的平台来用。

考虑到 Telegram 已有的 Bot API 生态、Mini Apps 基础设施以及 Managed Bots，Bot-to-Bot Communication 补上了 Agent 间通信的最后一环。

对于正在构建 AI Agent 的开发者来说，这意味着可以在 Telegram 上搭建完整的多 Agent 工作流——不需要额外的消息中间件，Telegram 本身就是那个中间件。

它不会取代 LangGraph、CrewAI 这类专用编排框架：复杂生产管线仍需要状态管理、重试和版本控制。但验证多 Agent 模式、搭轻量的自动化工作流，直接用 Telegram 做协作层，开发和调试成本都低一个量级——所有中间消息都可见，出了问题翻聊天记录就能定位。

来源：

Telegram Bot-to-Bot Communication