前一天我已經把多個 Profile 接進同一個 Gateway，個人私訊可以正常收到回覆。看起來系統已經上線，下一步只是把更多群組加入路由表。

結果是，個人 DM 正常，群組卻完全沒有反應。

這種問題最危險的地方，不是錯誤很難修，而是它沒有明顯錯誤。使用者只看到「Bot 不理人」，log 也沒有一行清楚寫著「你少設定了一個欄位」。如果直接重啟、換模型或重建 Bot，只是在浪費時間。

先把症狀固定下來

我先把問題切成幾個可驗證的假設：

關鍵對照是：同一個 Bot、同一個 Profile、同一個模型，個人 DM 能回，群組不能回。這代表不能先把問題歸因於模型。

真正的根因

舊版設定只處理一般允許清單，例如 allowed_chats。我原本以為，只要把群組 Chat ID 放進去，Gateway 就會把訊息交給 Profile。

但新版的授權流程把私訊與群組拆成兩層：

1. 一般聊天是否在 allowed_chats。
2. 群組聊天是否另外在 group_allowed_chats。

缺少第二層時，群組事件會在授權層被靜默丟棄。它甚至不一定會進入後面的 Profile 路由與模型呼叫，所以你在模型 log 裡找不到任何失敗請求。

這也是為什麼「換模型」完全沒用：訊息根本還沒走到模型。

不要用猜的，直接找判斷點

我用原始碼搜尋群組授權相關欄位，總共找到 221 個命中結果，再縮小到 Gateway 的 allowlist 判斷。最後確認群組事件會先經過額外的 group_allowed_chats 檢查。

這裡有一個很實用的除錯原則：先定位事件生命週期，再決定要看哪一層 log。

訊息處理大致可以拆成：

平台事件 → Chat 授權 → Profile 路由 → Provider／模型 → 回覆平台

症狀「沒有回覆」可能發生在任何一層。如果沒有先做 DM 與群組的對照，很容易直接跳到 Provider 層查錯。

修正方式

我保留原本的 allowed_chats，並補上群組專用設定；同時確認 multiplex_profiles 已啟用，且目標 Profile 同時存在於 allowlist 與 route map。

設定完成後，不是看到服務重載成功就算完成，而是做兩次端到端測試：

1. 在個人 DM 發送測試訊息，確認原本的路徑沒有被破壞。
2. 在目標群組發送測試訊息，確認收到回覆並讀回實際 message_id。

測試結果是個人 DM 與群組都成功回覆。這證明修正的是授權層，而不是碰巧換到另一個可用模型。

這次踩雷留下的檢查清單

新增群組路由時，我現在會依序確認：

• Chat ID 是從實際平台事件讀回，不手打猜測。
• allowed_chats 有目標 Chat。
• group_allowed_chats 有目標群組 Chat。
• profile_routes 指向正確 Profile。
• multiplex_profiles 已開啟。
• Bot 的群組權限與平台 Privacy Mode 符合需求。
• 重載後分別測試 DM 與群組。
• 測試保留可追溯證據，例如回覆內容、message_id 與時間。

結語

這次問題表面上像是「Bot 沒回群組」，實際上是事件在授權層被丟掉。沒有錯誤訊息不代表沒有根因，只代表你可能還沒找到事件消失的位置。

當 Agent 從單一聊天走向多 Profile、多群組、多平台時，allowlist 不再只是幾個設定欄位，而是整個系統的安全邊界。任何一個聊天入口都應該有明確的 owner、授權條件、路由目標與端到端驗證。

今天的實際證據：補上 group_allowed_chats 後，目標群組收到 Bot 回覆，並取得實際 message_id；原本正常的個人 DM 也維持可用。