最近在整理多人使用的 AI 助理時，我又碰到一個很容易讓人誤判的畫面：替不同使用者開好各自的聊天頻道，看起來乾乾淨淨，大家互相看不到對方的對話，於是直覺上會覺得「隔離完成了」。
但站在後端看，事情可能完全不是這樣。三個頻道如果最後都進到同一份 Session、同一個使用者 Profile、同一套長期記憶，那其實不是三個 AI 助理，只是一個助理開了三扇門。
UI 分開，不代表狀態分開
傳統聊天系統裡，頻道主要負責整理對話與控制可見性。對人來說，只要成員權限設好，A 看不到 B 的頻道，邊界大致就成立了。
AI Agent 多了一個麻煩：它會在訊息之外累積狀態。它可能保存對話摘要、使用者偏好、任務進度、常用文件、工具授權與人工修正。這些狀態不一定存在聊天平台裡，而是落在 Agent runtime 的資料庫、檔案、向量索引或快取中。
因此，聊天平台的 ACL 只能回答「誰看得到哪個畫面」，不能回答「模型這次拿到了誰的上下文」。如果後端仍以同一個預設身份處理所有頻道，畫面上的隔間只是佈景，資料還是住在同一個房間。
這也是我現在檢查多人 Agent 時，第一個不看的反而是畫面。我會直接往 request 進入後的路由看：系統如何從伺服器、工作區、頻道、討論串與使用者身份，推導出真正的 runtime scope？
真正要隔離的是一整串狀態
一個可以長期使用的個人 AI 助理，至少有六類東西需要明確歸屬。
第一是 身份。後端必須知道目前服務的是哪一個人或哪一個工作群組，不能只知道訊息來自哪個頻道。頻道 ID 可以是路由線索，但不應直接等於業務身份；兩者之間要有可檢查、可撤銷的對應關係。
第二是 Session。不同使用者的短期上下文必須分開，包含對話歷史、摘要與尚未完成的任務。否則即使長期記憶沒有共用，模型仍可能在壓縮上下文或恢復任務時，把上一個人的脈絡帶進來。
第三是 記憶。偏好、常用資料與人工更正都要有 scope。多人共用同一個向量索引並非一定錯，但檢索前必須先以身份與權限縮小範圍，不能撈出內容後再叫模型「不要引用別人的資料」。資料一旦進入 prompt，邊界其實已經失守。
第四是 工具與憑證。每個人能呼叫哪些工具、看到哪些資料、能否執行寫入，不該因為大家都在使用同一個 Bot 就自動相同。共用入口不代表共用權限，更不代表可以共用個人憑證。
第五是 產物與稽核紀錄。Agent 產生的檔案、任務結果、工具呼叫與錯誤紀錄，也要帶著相同 scope。否則前面隔離得很努力，最後卻在共用輸出目錄或管理後台裡全部混回去。
第六是 生命週期。新增使用者時建立哪些資源？停用時撤銷哪些路由與權限？記憶要保留、匯出還是刪除？如果沒有明確的 provisioning 與 deprovisioning，隔離很容易只在建立當下正確，之後逐漸漂移。
討論串是最容易漏掉的縫
多人聊天入口還有一個很實際的坑：子對話不一定會自動繼承父層的 Agent 路由。
對使用者來說，頻道底下開一個討論串，只是把某件事獨立出來談；他自然會期待同一個 AI 助理、同一份個人記憶與同一組權限繼續存在。但後端若只用目前的 channel ID 查路由，討論串會得到一個新的 ID，最後不是掉回預設 Profile，就是根本找不到身份。
更危險的是掉回預設值。完全失敗至少看得見；悄悄使用共用 Profile，表面上仍會正常回答，卻可能讀到錯誤的記憶或使用錯誤的工具範圍。
所以路由規則不能只寫「這個頻道對應這個 Profile」，還要定義繼承語意：若訊息來自討論串，是否先查自身明確設定，再回溯父頻道？父層停用後，既有討論串是否同步失效？路由決策有沒有留下紀錄？這些才是系統真正的隔離邏輯。
我偏好的路由順序
實作上，我會把這件事當成多租戶系統，而不是聊天功能。每次請求進來，都先解析一個明確的 execution context，再讓 Agent 開始工作。概念上的順序大致是：
- 驗證平台上的使用者與工作區身份。
- 解析目前入口，包含父頻道與討論串關係。
- 找出被允許的 Profile，而不是套用方便的全域預設值。
- 以 Profile 決定 Session、Memory、工具 Policy、憑證與輸出空間。
- 記錄這次路由為何成立，以及最後實際使用了哪個 scope。
- 找不到明確路由時拒絕或降級，不要默默進入高權限的共用環境。
這裡最重要的設計原則是 fail closed。多人 Agent 最糟的錯誤通常不是「沒有回答」，而是「回答得很順，但用了不屬於這個人的上下文」。
隔離要用測試證明，不靠畫面感覺
這類功能也不能只測「A 頻道收到 A 的回覆」。我會特別做交叉測試：先讓 A 留下一個只有 A 知道的偏好，再從 B 詢問；從父頻道建立子討論串，確認仍落到相同 scope；移除路由後，確認舊討論串不會退回預設 Profile；最後檢查日誌、產物與工具權限是否也沒有跨界。
換句話說，測試的不是聊天有沒有通，而是資訊有沒有可能穿牆。
站在 CTO 的角度，我越來越不把「每人一個頻道」視為多人 AI 助理的完成條件。那只是入口配置。真正的產品邊界存在後端：身份怎麼解析、狀態怎麼分區、子對話怎麼繼承、權限怎麼縮限，以及錯誤時系統選擇拒絕還是猜測。
AI Agent 很會讓介面看起來有人格、有歸屬感，這也是它迷人的地方。但系統不能只靠感覺提供隱私。當一個助理開始替不同的人記住事情、使用工具與執行工作時，我們需要的不是三扇不同顏色的門，而是門後真的有三個不會互通的房間。