一個智慧代理，通吃所有管道

客戶先在你的網站上問了一件事，兩週後改用 WhatsApp 追問。這到底算一段關係、還是兩個陌生人，取決於身分怎麼解析，而不是取決於聊天介面。

整體架構

管道是入口，不是各自為政的孤島。每一個管道往下都會收斂到同樣的三樣東西：

智慧代理不會為每個管道各複製一份。檢索、記憶與跟進全都掛在空間上，所以換一個 app 進來，變的只是傳輸方式，其他什麼都沒變。

身分解析

每個管道會提供一個外部識別碼：小工具權杖裡的終端使用者 id、Telegram 的使用者 id、WhatsApp 號碼。解析依據是 (tenant, external_user_id)：查一次，第一次看到就建一個。

有兩個細節值得知道：

• 首次接觸會有競態，而且已經處理好。 兩則訊息同時抵達，都會查不到使用者，於是都想建立一個。由唯一性約束決定勝負，失敗的那一邊改成重新讀取而不是報錯——所以一連串同時湧入的首則訊息，產生的是一個使用者，不是一個錯誤。
• 空間會被解析出來，或被建立。 每個使用者都有預設空間；如果請求明確指定了空間，該空間必須屬於這位使用者，否則請求會被拒絕。就是這道檢查擋住了刻意構造的請求去讀別人的對話。

要不要把同一個人跨管道串起來，是租戶的決定，不是系統的猜測。 平台不會因為網站訪客和某個 WhatsApp 號碼看起來很像就把兩者合併——那種推測正是系統把一位客戶的往來紀錄漏給另一位的原因。凡是你能確認是同一個人的場合（已登入的使用者、帶有終端使用者 id 的連結），只要傳同一個識別碼，往來紀錄就會跟著走；確認不了的場合，就讓它們保持分開。

轉接層共用什麼，又不共用什麼

Telegram 和 WhatsApp 看起來不一樣，做的事卻一樣。轉接層負責收攏所有不該產生分歧的部分：

由轉接層共用	交給各管道自理
身分解析與空間查找	訊息呈現與發送呼叫
目前工作階段的讀寫	Telegram 的行內鍵盤與表單提示
指令——新建、列出、切換、歷程、更名、刪除、定位、說明	WhatsApp 的清單與互動式回覆
歷程重播與格式化	各平台自有的附件處理
回應較慢時的提示
執行一輪對話

原則是：對話語意只能有一個地方定義。如果工作階段切換在 WhatsApp 上跟在 Telegram 上稍有不同，這個差異在客戶撞上之前是看不見的。

一個實際的推論：這些是私訊整合。在 Telegram 私訊裡，聊天 id 和寄件者 id 是同一個值，所以發送目標和身分索引鍵收斂成同一個東西——這也是為什麼轉接層能把「這是誰」和「我要回到哪裡」當成同一個概念處理。

需要較久才能給的答案

有些回覆沒辦法在一輪之內產出。智慧代理可以把工作排進行程，讓答案稍後送達，並推送回請求進來的那個管道：網頁小工具裡的一則對話泡泡、Telegram 或 WhatsApp 裡的一則訊息。見排程跟進。

實務上的意義

• 一位客戶、一份往來紀錄，不管他從哪裡發訊息。
• 新增一個管道，不會讓對話邏輯分岔。
• 檢索與記憶在每個管道的行為完全一致，因為它們掛在空間上，而不是掛在管道上。