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金鑰、資料庫密碼等，避免將秘密硬編碼或存入原始碼。

為何所有請求透過一個函式

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