前言：多 bot 之後，訊息要送到誰

上一篇把公司責任拆成多個部門 bot，但拆分只完成一半。真正上線後，使用者不會先打開「finance Profile」再輸入問題；他只會在某個 Telegram 群組、私人聊天室或 LINE 對話中發訊息。

因此下一個問題變成：同一個 Gateway 如何同時服務多個 Profile，而且每則訊息都能抵達正確的角色？

這不是把八個 bot 都塞進同一個提示詞，而是建立一張可驗證的路由表：來源聊天室是誰、允許哪些 Profile、最後由哪個 Profile 回應。

一、Profile、Bot 與聊天室不是同一層

在實作時，我先把三個概念分開。

Profile 是一套獨立的執行環境，包含設定、SOUL、USER、skills、cron 與記憶。Bot 是這套環境在某個工作責任上的角色。聊天室則是訊息進入系統的來源。

三者可以用下面的方式理解：

最容易犯的錯，是把模型工具 Profile 當成部門 Bot。flash/deep/best 是模型工具分工，不代表它們應該直接取代 finance 或 engineering 的責任邊界。

二、先畫路由表，再改設定

我的路由設計先從資料表開始，而不是先改設定檔。每一列至少要寫清楚：

• 平台與 chat ID。
• 這個聊天室的用途與 owner。
• 允許接收訊息的 Profile。
• 實際預設回應的 Profile。
• 是否允許群組訊息。
• 失敗時要回報給誰。

例如：

這張表的價值不在於看起來完整，而在於出問題時可以回答：訊息到底在授權層被拒絕、在路由層選錯，還是到了模型後才產生錯誤？

三、Multiplex Gateway 解決的是同時在線

單一 Gateway 的好處是平台連線、訊息接收與基本生命週期可以集中管理。當 multiplex_profiles 啟用後，Gateway 可以在同一個服務中載入多個 Profile，根據來源與路由規則把訊息交給對的執行環境。

但「啟用 multiplex_profiles」只代表系統具備多 Profile 能力，不代表所有聊天室都自動被授權，也不代表會自動猜出正確的 Profile。後面仍然需要 allowlist 與 routes。

我把設定拆成三個責任：

1. multiplex_profiles：允許 Gateway 同時管理多個 Profile。
2. allowed_chats：定義哪些聊天室可以進入系統。
3. profile_routes：定義來源聊天室要交給哪個 Profile。

對群組訊息而言，還要確認群組專用的授權清單。少一層時，症狀可能不是錯誤訊息，而是訊息安靜地消失，讓人誤以為模型或 Gateway 掛掉。

四、allowlist 是安全邊界，不是方便清單

我不把所有 chat ID 都放進允許清單。每加入一個來源，都要能回答三件事：

• 為什麼這個聊天室需要進入系統？
• 它可以接觸哪個 Profile 的資料？
• 如果路由失敗，是否會把訊息送到不該看到的角色？

私人資料、公司資料與不同部門的資料不能因為共用 Gateway 就混在一起。尤其是「公司群組允許使用 architect」不等於 architect 可以讀取每個部門的所有原始資料；平台授權、Profile 權限與工具資料源仍要分層檢查。

五、最小可行路由測試

改完路由後，我不會只看設定檔語法正確，也不會只重啟服務就宣布完成。我會用最小測試矩陣逐一驗證：

每次測試都保留原始訊息、log、回覆內容與 message ID。這些資料比「服務顯示 running」更能證明路由真的有效。

六、一次設定失敗的排查順序

當個人 DM 有回覆、群組卻沒有回覆時，我會依序檢查：

1. chat ID 是否抄錯，尤其是群組 ID 的負號。
2. Bot 是否真的在目標群組內，且具備讀取與回覆權限。
3. 平台層的群組隱私或訊息接收限制是否生效。
4. allowed_chats 是否包含該聊天室。
5. 群組專用授權清單是否也包含該聊天室。
6. profile_routes 是否把來源送到存在且已載入的 Profile。
7. Gateway 重新載入後，log 是否出現路由命中紀錄。
8. 最後才檢查模型、工具與提示詞。

這個順序很重要。若訊息根本沒有通過授權層，繼續調模型只是在錯的地方浪費時間。

七、重載不是驗證

設定檔寫入成功，只能證明檔案被修改。服務重新啟動成功，也只能證明程序能跑起來。完整驗證至少要包含三段：

• 設定層：讀回 multiplex_profiles、allowlist 與 routes 的實際值。
• 服務層：確認 Gateway 載入正確 Profile，並讀取最新 log。
• 外部效果：從目標聊天室送出測試訊息，讀回實際回覆與 message ID。

如果只有前兩段，最多只能說「設定已載入」，不能說「群組路由已修好」。

八、路由規則也需要 owner

路由表不是一次建立後永遠不變。新增聊天室、移交部門、停用 Bot 或改變資料權限時，都可能需要同步更新 allowlist 與 Profile 設定。

所以我會把路由維護責任交給明確 owner，並留下變更原因、影響範圍、驗證結果與回滾方式。沒有 owner 的路由表，最後一定會變成只有最初建立者看得懂的隱性設定。

結語：多 Profile 的重點是可控，不是數量

Multiplex Gateway 讓多個 Profile 可以同時在線，但真正的工程難題是把「誰可以收到什麼」說清楚。

我的做法是先分離 Profile、Bot 與聊天室，再用 allowlist 限制入口，用 profile_routes 決定責任，最後用實際訊息與 log 驗證外部效果。任何一層缺失，都可能讓訊息被送錯或靜默丟棄。

下一篇會記錄一次更具體的踩雷：Bot 在私人訊息中正常回覆，到了群組卻完全沒有反應。那次排查最後發現，問題不在 chat ID、權限或模型，而是在新版授權流程多了一道群組清單。

實際證據清單

• 路由表：每個聊天室、允許 Profile 與預設 Profile 分開定義。
• 分層設定：multiplex_profiles、allowed_chats、群組授權與 profile_routes 各自驗證。
• 測試矩陣：包含允許、拒絕、重啟與錯誤路由情境。
• 完成標準：設定讀回、服務載入、外部訊息回覆與 message ID 全部可追溯。