教程 May 22, 2026

Telegram Bot-to-Bot API：对 AI Agent 架构意味着什么 — UnifyPort

2026 年 5 月 7 日，Telegram 推出了一项大多数消息平台从未触碰的功能：自主 Bot 之间的直接原生通信。无需共享后端，无需中继服务器。一个 Bot 通过 @username 寻址另一个 Bot，消息就此送达。对于正在构建 AI Agent 系统的开发者来说，这值得认真关注。

究竟发生了什么变化

在此次更新之前，如果你想让两个 Bot 在 Telegram 上协调工作，必须通过外部服务路由所有消息。Bot A 将结果发送给你的后端，后端决定下一步操作，再指示 Bot B 执行。Bot 本身是孤立的——它们只能接收来自用户的消息，或由你自己的基础设施调用。

新系统的工作方式不同。一个 Bot 现在可以通过 @username 直接向另一个 Bot 发送私信。有两个前提条件：发送方和接收方都必须显式开启此模式。任何 Bot 都不会被强制拉入它未同意参与的 Agent 协作图。

这个双向 opt-in 的约束是有意为之的。它防止 Bot 被垃圾消息轰炸或被强制加入它并非为此设计的 Agent 图，同时也让开发者能清晰区分哪些 Bot 属于协调层，哪些直接面向终端用户。

为何对多智能体系统意义重大

多智能体 AI 系统——由专业模型分别处理不同任务并相互传递工作——在过去一年中变得越来越普遍。协调层通常是最棘手的部分：你需要一个可靠、低延迟的通道，供 Agent 传递上下文、委托子任务、汇报结果。

大多数团队目前用消息队列、共享数据库或自定义 HTTP 服务来解决这个问题。这些方案可行，但会增加基础设施、引入故障点，而且完全游离于用户实际交互所在的消息平台之外。

Telegram 的 Bot-to-Bot 支持将平台本身变成协调基础设施的一部分。你可以直接围绕 Telegram 的投递保障、重试机制和现有认证模型来构建 Agent 系统，而无需搭建独立的中继层。

由此产生的两种架构模式

编排者-工作者模式。 一个 Bot 作为中央协调者。它接收用户请求，将其拆解为子任务，并通过直接消息将各子任务分发给专门的工作者 Bot。工作者 Bot 处理完各自的部分后向编排者汇报，编排者将结果整合后回复用户。

用户 → 编排者 Bot
           ↓            ↓
      工作者 Bot A   工作者 Bot B
           ↓            ↓
      编排者 Bot（聚合结果）
           ↓
         用户

此模式适合可并行的任务：调研 + 摘要、翻译 + 排版、数据获取 + 分析。

流水线模式。 Bot 以串行链条排列。Bot A 处理第一步，将输出直接传递给 Bot B，Bot B 处理下一步，依此类推。用户只与链条中的第一个 Bot 交互，中间结果完全在 Bot 层内流转。

此模式适合每一步都对上一步输出进行转换的任务：采集 → 校验 → 增强 → 投递。

构建前需要考虑的问题

双向 opt-in 是强制的。 你无法在不修改现有 Bot 的情况下将其加入 Agent 协作图——对方 Bot 必须开启接收 Bot 消息的模式。如果你要将第三方 Bot 与自建 Bot 混用，请确认对方是否支持此模式。

消息格式有限制。 Bot-to-Bot 消息走的是与用户消息相同的 API，因此受相同的 payload 大小限制和媒体类型限制。你无法将任意结构化数据作为原生消息发送——如果 Agent 之间需要传递大型 JSON payload，建议用独立通道传输数据，Bot 消息仅用于任务信号。

此功能仅限 Telegram 范围内。 如果一个 Agent 需要响应 Telegram 事件，另一个 Agent 需要基于结果发送 WhatsApp 通知，跨平台协调仍需在平台之外完成。

当你的 Agent 跨越多个渠道

对于同时运营多个消息平台的 Agent 系统——Telegram 服务一批用户、WhatsApp 服务另一批、LINE 或 Zalo 服务其他用户——协调问题已超出任何单一平台的 Bot API 所能解决的范围。

统一的 Webhook 层意味着你的 Agent 无论消息来自哪个渠道，都能收到规范化的事件，并能通过正确的渠道路由响应，而无需每个 Agent 都去理解多套 Provider API。这正是 UnifyPort 所解决的问题：统一的 API 接口，标准化的事件结构，覆盖你的 Agent 需要触达的每一个渠道。

Telegram 的 Bot-to-Bot 功能是将消息基础设施视为一等协调原语的重要一步。它所开启的架构模式——Agent 通过服务用户的同一媒介相互通信——比独立中继层更为简洁。在以 Telegram 为主要渠道的系统中，这一功能值得纳入 Agent 设计。对于需要更大范围覆盖的系统，同样的原则在多渠道层面同样适用。