从外部看，AI 接线员似乎很简单：来电者说话，系统作出回应，对话一直进行，直到来电者得到答案或被转接到人工坐席。
在这段对话背后，有一条由电话基础设施、语音识别、语言模型、应用逻辑、API、数据库和呼叫路由组成的处理流水线。
有趣的地方不仅在于 AI 模型本身，而在于这些组件如何协同工作，把音频流转化为有用的业务动作。
想要这些功能的企业有两条路可走。
他们可以购买现成的产品。如今市场上已有专门的 AI 接线员，如 Nextiva 的 XBert，以及来自 Goodcall、Dialzara 等的工具。
或者他们可以自行构建，而本文正是要一步步带你完成这个过程。无论哪种方式，了解架构都很有帮助：它能让你看到商业产品在内部到底在做什么，以及定制开发需要准备哪些组件。
典型的架构大致如下所示：
在本文中，我们将深入探讨 AI 电话客服背后的架构，从来电者拨打企业电话的那一刻，一直到通话结束后发生的事情。
你将看到电话系统如何接通呼叫，语音如何转换为文本，AI 如何识别意图并保持对话上下文，以及功能调用如何将代理与日历、CRM 和其他业务系统连接起来。我们还将探讨代理如何决定何时将通话转接给人工坐席，以及在此过程中可以传递哪些信息。
我们将涵盖的内容：
电话呼叫进入系统
流程始于一次普通的电话呼叫。客户拨打企业电话号码，电信运营商接听该呼叫。
然后，提供方需要把该来电转接给能够处理它的应用程序。
一种常见做法是使用 webhook。来电到达时，电话服务提供商会向应用发送 HTTP 请求。应用可返回说明，说明如何处理该来电。
呼叫本身需要运营商连接。生产系统通常采用 SIP 中继，通过互联网把语音应用或电话系统接入公共电话网络。
Nextiva、Twilio 和 Bandwidth 等提供商提供 SIP 中继，为 AI 语音系统供应号码和通话容量。随后，应用层接管。
例如，Twilio 在来电语音呼叫到达时，会向配置的应用发送 HTTP 请求。应用可以用 TwiML 指令进行响应，以控制呼叫。
一个简化的 Node.js 端点示例如下：
app.post("/incoming-call", (req, res) => {
const response = new VoiceResponse();
response.say("Hello. How can I help you today?");
res.type("text/xml");
res.send(response.toString());
});
此示例目前还未涉及任何 AI，仅展示了第一个架构边界。
电话网络负责处理来电，应用程序接收事件并决定后续操作。
此后，应用程序需要处理来电者的音频。
语音转换为文本
用户通过音频与系统交互，但大多数应用逻辑基于结构化数据和文本。
自动语音识别系统（即 ASR 系统）将来电者的语音转换为文本。
例如，来电者可能会说：
"我需要把周五的预约改到周一下午。"
语音识别层可能会产生：
{
"text": "I need to move my appointment from Friday to Monday afternoon."
}
确切的响应取决于语音识别系统。某些系统还能提供时间戳、置信度、说话人信息或部分转录。
应用程序现在可以将识别出的文本传递给其对话层。
这种分离很有用，因为 AI 推理层不需要理解原始电话音频。它接收文本并返回决策或响应。
系统确定来电者想要什么
下一个挑战是理解意图。
假设有三位来电者这样说：
"我想预约一次咨询。"
"我可以把我的预约改到下周吗？"
"你们的办公室在哪里？"
系统需要识别这些请求需要不同的工作流。
应用程序可以将检测到的意图表示为结构化数据：
{
"intent": "reschedule_appointment",
"entities": {
"current_day": "Friday",
"requested_day": "Monday",
"time_preference": "afternoon"
}
}
语言模型能够生成这种结构，或者应用可以通过另一个分类层得到它。
关键的架构点在于，应用把自然语言转换为下游系统能够处理的信息。
模型可能理解来电者想要重新安排预约，但仅仅因为它生成了这种解释，就不应该直接去修改日历。
应用需要控制接下来发生的事情。
对话以循环方式运行
AI 电话客服通常不会在单个请求中处理整个对话。
相反，它以循环方式运行。
来电者说话。语音识别将音频转换为文本。应用把文本及相关上下文发送给 AI 系统。AI 决定需要说什么或执行什么操作。应用生成音频并将其发送回给来电者。
然后来电者再说一次。
简化版如下所示：
while (callIsActive) {
const audio = await receiveAudio();
const text = await speechToText(audio);
const result = await processConversation({
text,
context: conversationContext
});
conversationContext = result.updatedContext;
const audioResponse = await textToSpeech(result.response);
await sendAudio(audioResponse);
}
这是概念代码，并非完整的电话实现。实际系统需要处理流式音频、中断、超时、错误、身份验证以及特定于提供商的协议。
上下文同样重要。
如果来电者说：
“我想预约。”
系统可能会问：
“您需要什么类型的预约？”
来电者接着说道：
“初步咨询。”
只有当应用程序记住之前的交互时，第二句话才有意义。
对话状态可能包含以下信息：
{
"intent": "book_appointment",
"appointment_type": "initial_consultation",
"customer_name": "Jane Smith",
"preferred_date": null
}
系统可以在对话进行过程中向此状态添加信息。
AI 调用业务系统
这就是 AI 接待员不仅仅是一个语音聊天机器人的地方。
假设来电者询问：
"您明天下午有空吗？"
仅凭对话内容，AI 无法可靠地回答这个问题。它需要来自日历或调度系统的实时信息。
这就是函数调用（也称为工具调用）发挥作用的地方。
应用程序可以向 AI 公开一组有限的函数：
const tools = [
{
name: "check_calendar",
description: "Find available appointment slots",
parameters: {
date: "string",
appointmentType: "string"
}
},
{
name: "book_appointment",
description: "Book an available appointment",
parameters: {
slotId: "string",
customerId: "string"
}
}
];
模型可以确定它需要 check_calendar。
应用程序随后执行该函数：
const slots = await checkCalendar({
date: "2026-08-21",
appointmentType: "consultation"
});
结果会返回到对话上下文中：
{
"available_slots": [
"2026-08-21T14:00:00",
"2026-08-21T15:30:00"
]
}
AI 然后可以告诉呼叫者有哪些可用选项。
重要的架构边界在于 AI 决定可能需要什么操作，而应用代码控制该操作如何执行。
这为开发者提供了一个位置，以执行权限、验证输入、处理故障以及控制对业务系统的访问。
预约安排
现在考虑最后一步。
呼叫者选择其中一个可用的时间。
AI 可以请求预约安排：
{
"tool": "book_appointment",
"arguments": {
"slotId": "slot_123",
"customerId": "customer_456"
}
}
应用程序会先校验这些值，然后再调用日历系统。
例如：
async function bookAppointment(slotId, customerId) {
const slot = await getAvailableSlot(slotId);
if (!slot || slot.booked) {
throw new Error("Appointment slot is no longer available");
}
return calendar.createEvent({
customerId,
start: slot.start,
end: slot.end
});
}
应用程序随后将实际结果返回给 AI。
这一区别很重要。
AI 不应仅仅因为决定调用 book_appointment 而告诉调用方已预约了约会。
日历系统需要确认操作成功。
日历 API 常见地公开用于创建事件的操作。例如，谷歌日历 提供了一个 events.insert 方法来创建事件。
只有在收到成功响应后，对话层才应告诉调用方约会已确认。
捕获潜在客户信息
同样的架构可以在销售对话过程中捕获信息。
调用方可能会提供姓名、电子邮件地址、公司、电话号码、服务需求以及首选的跟进时间。
对话可以逐步填充一个结构化的潜在客户对象：
{
"name": "Jane Smith",
"email": "jane@example.com",
"company": "Example Corp",
"interest": "enterprise consultation",
"appointment_booked": true
}
随后，应用程序可以把这些信息发送到 CRM。
这在对话数据和业务数据之间划出了重要的界限。
转录内容代表了来电者所说的话。
CRM 记录代表了业务需要采取行动的结构化信息。
CRM 可能包含来电者的联系信息、咨询类型、资格数据、预约详情以及跟进状态。
具体字段取决于公司的 CRM 及其销售流程。
了解何时需要人工介入
并非所有对话都应由 AI 系统独自处理。
生产系统需要制定升级规则。
当来电者要求人工服务、请求超出代理支持的工作流程，或者企业决定某类请求必须由人工处理时，可能会触发升级。
应用程序可以明确表示此决定：
if (shouldEscalate(conversation)) {
return transferToHuman({
callerId,
reason,
conversationContext
});
}
关键在于转接过程中发生了什么。
一次有效的交接应当携带上下文信息，而不是让接手的员工从零开始。
人工客服可能会收到：
{
"caller": {
"name": "Jane Smith",
"phone": "+1-555-0100"
},
"reason": "Complex billing question",
"summary": "Caller needs help resolving an invoice discrepancy.",
"actionsCompleted": [
"Customer identity verified"
]
}
具体需要交接哪些数据，取决于所用的系统。
电话平台还能通过语音 API 支持呼叫转接和回拨。例如，Twilio 的语音文档就介绍了呼叫路由功能，其中
通话结束后会发生什么
来电者挂断电话，对话未必就此结束。
视系统及其配置而定，应用程序可以保留对话的文字记录以及其他通话数据。
一条简化的通话记录大致如下：
{
"callId": "call_123",
"duration": 342,
"customerId": "customer_456",
"intent": "book_appointment",
"appointmentId": "appointment_789",
"leadCaptured": true,
"escalated": false
}
转录提供详细对话，结构化字段提供下游应用可查询的信息。
因而，通话可以触发若干业务动作。
销售通话可以创建线索。
预约通话可以更新日历。
支持通话可以创建工单。
复杂对话可能导致人工交接。
电话系统也可以通过状态回调向应用程序通知通话生命周期事件。例如，Twilio 在通话结束时会向号码的状态回调 URL 发送请求，并支持 statusCallbackEvent 属性，用于订阅诸如已启动、振铃、已应答和已完成等拨号腿的生命周期事件。
业务视角
员工视角下，这些基础设施可隐藏在少数业务记录之后。
员工可能看到一个带有联系信息和来电原因的新 CRM 线索。
日历可能包含一条新预约。
对话系统可能包含转录和摘要。
如果通话被转接，员工在与客户交谈前可以获得相关上下文。
这就是 AI 电话代理背后的主要架构思想。
语音界面仅是一层。其下是一套系统，负责将语音转为文本、解释来电请求、维持对话状态、调用外部服务、验证业务操作并把结果返回给来电者。
语言模型提供对话推理。周围的应用提供状态、工具、权限、集成和业务规则，将对话转化为实际工作流。
希望您喜欢这篇文章。您可以 在 LinkedIn 上与我联系。
