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 設計。對於需要更大範圍覆蓋的系統，同樣的原則在多渠道層面同樣適用。