AI助手需要後端：將其部署在邊緣

構建語音AI助手從未如此簡單。編寫提示詞、連接電話號碼、選擇模型，幾分鐘內你的助手就能接聽電話。最初的對話成功彷彿魔法一般。但隨後有人問：“能查一下我的訂單在哪裏嗎？”或“能安排人明天過來嗎？”這時，助手需要它沒有的信息——它需要與CRM、排班系統或你自有的API交互。LLM不再是應用本身，而是一個更大系統的組件。這正是每個生產級AI助手都需要後端的時刻。本文我們將使用一個Telnyx Edge Compute函數來構建該後端，而非部署另一個Webhook服務，用一個Go函數處理動態變量和Webhook工具調用，驗證傳入請求，並將助手連接到後台運行的業務邏輯。

架構

示例應用名為Jordan，為一家虛構的家居服務公司工作。從呼叫者角度看，交互很簡單：助手接聽電話、問候、收集信息、安排上門評估。幕後卻有兩種完全不同的後端交互。在Jordan開口前，助手請求不應存在於提示詞中的運行時信息。隨後，收集足夠信息後，Jordan需要安排預約。兩個請求均由同一個Edge Compute函數處理。概念上，架構如下：

不同於為不同職責部署獨立的Webhook服務，一個函數擁有所有助手回調。這看似微小，但有很多優勢：僅一個部署、一個端點、一處管理密鑰、一處驗證請求、一處連接業務邏輯。隨應用增長，這種簡潔性變得寶貴。

完整源代碼見edge-ai-assistant-backend-go示例倉庫，部署指南逐步講解配置AI助手和Edge Compute函數。

理解動態變量

首次回調發生在助手開始講話之前，即動態變量。想想當人們致電企業時，問候語通常非靜態。也許你想説：“感謝致電Pinecrest Home Services。”或許高端客户聽到不同問候語，或轉接號碼隨當前開放的辦公室變化，或預估等待時間取決於當日日程。這些都不應放在提示詞內。提示詞描述行為，運行時數據應放在別處。動態變量解決了該問題。Telnyx在每次通話開始時向你的後端請求這些值，函數返回如下JSON：

{ "dynamic_variables": { "company_name": "Pinecrest Home Services", "timeframe": "two business days", "placeholder_transfer_destination": "+15551234567" } }

注意包裝對象：響應必須放在dynamic_variables鍵下，直接返回扁平JSON不會填充助手變量。一旦這些值到達，它們立即可在提示詞中使用，且是在運行時解析而非硬編碼。

當助手需要你的應用

動態變量解決前半部分，後半部分發生在對話中。想象呼叫者説：“我希望這週五有人來。”此時助手需要創建尚不存在的東西——預約。這不應用LLM捏造，而應詢問你的應用。這就是Webhook工具的用武之地。助手識別到有足夠信息執行操作，調用名為schedule_estimate的工具。請求發給處理動態變量的同一Edge Compute函數。函數執行所需業務邏輯，如調用內部排班API、檢查技師可用性或創建CRM記錄。示例簡單返回：

{ "scheduled_date": "2025-04-10", "scheduled_time": "10:00", "confirmation_number": "CONF-1715234567", "estimate_id": "EST-1715234567" }

關鍵在於模式：助手不生成業務數據，你的應用生成。助手知道何時需要信息，後端決定信息內容。這比讓LLM幻覺標識符、預約時段或客户記錄更健康。

一個函數，兩種不同請求

此示例所需基礎設施極少。許多基於Webhook的系統最終會有多個端點：/dynamic-variables、/schedule、/orders等。而此示例中，兩種回調類型指向同一URL。函數檢查傳入請求：若包含data.event_type則處理動態變量；若收到扁平JSON載荷則視為Webhook工具調用。實現雖小但展示了生產級架構，隨助手能力增長，可繼續通過同一函數路由不同回調類型，或隨後拆分。

為何將後端置於邊緣？

語音AI應用的延遲特性不同於大多數Web應用。動態變量在助手打招呼前已解析，工具調用時呼叫者正等待。與後台API請求不同，每個額外網絡躍點直接影響對話體驗。將助手後端運行在Edge Compute，使回調邏輯靠近已處理呼叫的通信基礎設施，消除部分運維工作。無需再部署Web服務、暴露公網、管理部署等，部署一個Edge Compute函數並將助手指向其調用URL即可。助手仍可訪問數據庫、CRM等，但無需額外獨立後端接收回調。架構簡化為：AI助手擁有對話，Edge Compute擁有業務邏輯。

構建生產級後端

雖以排班為例，但架構可擴展。後端成為對話與其餘應用間的橋樑。助手可能需要的操作包括從CRM檢索客户信息、檢查訂單狀態、創建工單、觸發內部工作流或決定轉接人工。從助手視角，這些都相同：識別需要信息、調用工具、等待響應、繼續對話。後端處理所有差異：一個工具調用Salesforce，另一個查詢PostgreSQL，另一個調用內部REST API等。保持對話邏輯與應用邏輯分離是有用的架構邊界。提示詞專注於助手行為，後端隨業務系統獨立演進。

安全不應是生產中的TODO

Telnyx每個Webhook請求使用Ed25519簽名。函數處理請求前，讀取telnyx-signature-ed25519和telnyx-timestamp頭，重建簽名載荷，驗證時間戳在可接受窗口內，最後使用公鑰驗證簽名。檢查通過後才執行業務邏輯，確保請求來自Telnyx。

管理密鑰

簽名驗證需要Telnyx公鑰，示例將其存儲為Edge Compute密鑰。獲取密鑰後使用CLI添加：telnyx-edge secrets add TELNYX_PUBLIC_KEY "$PUBLIC_KEY"。同樣機制適用於API密鑰、數據庫密碼等，避免將秘密硬編碼或存入源碼。

為何所有請求通過一個函數

初看可能不尋常，但單一函數簡化了部署和運維。隨着應用增長，可保持單一函數或拆分，但起始簡單通常是正確選擇。