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