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密钥、数据库密码等，避免将秘密硬编码或存入源码。

为何所有请求通过一个函数

初看可能不寻常，但单一函数简化了部署和运维。随着应用增长，可保持单一函数或拆分，但起始简单通常是正确选择。