Telegram Topic Agent Bridge：把使用者所在的聊天室變成零 orchestrator 的 agent 協調層
runs.dash 的 Threads 貼文提出一個反直覺的 multi-agent 架構：不用中央 orchestrator、不靠共享資料庫，而是把 Telegram supergroup topic 當成 coordination layer。每個 agent session 掛在 topic 上，由 bridge 攔截 agent-B <msg> 這類訊息並注入對方下一個 turn；同 chat 直接注入、跨 chat fanout。真正的風險不是 routing，而是 agent 互相觸發形成 loop，因此需要 per-agent rate limit、state persistence 與 e2e 驗證。
最簡單的 coordination primitive，可能不是新 infra，而是使用者已經待在裡面的 channel。Telegram topic threading 天然帶有 pub/sub 與上下文分區語意。
多數 multi-agent 系統會設一個中央 orchestrator route 訊息；這個設計把 route 行為下放到 bridge + topic threading，讓聊天室本身承擔一部分協調層。
某個 agent 打 agent-B <msg>，bridge 攔截後注入 agent B 的下一個 turn。同 chat 可直接注入；跨 chat 則 fanout 到對方 channel。
貼文提到 12 個 bridge commits、e2e 驗證、state persist in state.db，bridge restart 後狀態仍存活。這是把社群通道從 UI 變成 runtime component 的關鍵。
這跟一般 multi-agent orchestrator 差在哪？
傳統 multi-agent 架構常把協調邏輯集中在一個 orchestrator：它決定誰接任務、誰回報、誰等待、誰重試。Telegram topic bridge 的思路相反：把 coordination 拆成「訊息通道 + bridge policy + agent session injection」。通道是 Telegram；policy 是 bridge 裡的命名、路由、rate limit、fanout、state；實際思考仍由各 agent session 自己完成。
中央節點理解任務圖，決定 agent 間呼叫。優點是可控、可觀測；缺點是要多維護一層 infra 與狀態機。
把 Telegram topic 當作事件流與人機共用介面。優點是低摩擦、可被人直接觀察與介入；缺點是需要嚴格防 loop、權限與噪音。
Bridge 不是大型 planner，而是薄薄的 transport adapter：解析目標 agent、決定同 chat 注入或跨 chat fanout、寫入 state、做 dampening。