首页DoorDash 每天需要处理大量来自配送员的客服电话。订单问题、配送异常、平台规则和账户操作，都可能触发一次客服咨询。对于配送员来说，电话通常比文字聊天更方便，尤其是在配送途中。
为进一步提高自助处理能力，DoorDash 与 AWS 合作，引入 Amazon Bedrock、企业知识库，在约两个月内开发出基于生成式 AI 的电话客服方案。这类 AI 电话客服的技术重点已经超出了传统语音识别。用户询问订单状态时，系统需要访问实时订单数据；要求修改信息时，需要调用业务接口；无法处理的问题，还要及时转给人工客服，并保留此前的对话内容。
本文结合 DoorDash 案例，拆解 AI 智能客服的技术架构，以及实时通信、Function Calling 和对话式 AI 在其中的作用。
一. AI 电话客服与传统 IVR 有什么区别？
1. 传统 IVR 擅长分流，但复杂问题仍然依赖人工
传统 IVR（Interactive Voice Response，交互式语音应答）通常通过按键菜单或预设语音指令完成服务分流。
例如，用户拨打客服电话后，系统提示“查询订单请按 1，退款问题请按 2，人工服务请按 0”。这种方式适合处理分类明确、流程固定的业务。
当用户的问题同时涉及多个业务环节时，菜单式交互就比较受限。
例如，用户需要查询订单配送进度，并询问能否修改收货时间。系统首先需要判断是哪笔订单，再查询当前履约状态，最后根据平台规则决定是否允许修改。
传统 IVR 可以通过预设流程完成部分操作，但一旦用户表达不符合菜单设计，或者业务规则出现多种分支，就需要配置更多语音菜单与条件逻辑。
生成式 AI 电话客服的优势在于，可以通过自然语言理解用户意图，再根据业务状态决定下一步操作。不过，这种灵活性也带来了工具调用准确性、权限控制和任务执行可靠性等新问题。
2. DoorDash 如何扩展原有的语音客服系统？
DoorDash 的生成式 AI 方案沿用了既有呼叫中心基础设施，并结合 Amazon Lex、Amazon Bedrock 和 Bedrock Knowledge Bases 处理自然语言问题。
其重点是让配送员通过电话获得常见问题的答案，减少不必要的人工转接。
例如，平台政策或配送规则类问题可以通过企业知识库检索回答，减少人工客服重复解释相同问题的工作量。
但企业知识库并不能覆盖所有客户服务任务。查询当前订单、修改预约、创建退款申请等操作，还需要访问实时业务数据或执行系统接口。
这里也是 AI 智能客服从知识问答发展为任务型 Agent 的关键区别。
二. AI 智能客服如何完成一通电话？
以电商订单客服为例，用户拨打客服电话后，可能提出“帮我查一下订单，如果还没发货，能不能把配送时间改到明天”。
以下是一个典型的任务型 AI 客服处理流程。它用于说明技术架构，不代表 DoorDash 已公开实现了其中每一种业务操作。
1. 电话接入：SIP 如何把用户连接到 AI Agent？
传统电话网络与互联网实时音视频系统使用的通信机制不同。企业通常通过运营商、云通信平台或 SIP Trunk 将电话接入呼叫中心。
SIP（Session Initiation Protocol，会话初始协议）主要负责建立、管理和结束通信会话。通话音频一般由 RTP 等媒体协议承载。
当用户拨打客服号码时，运营商或电话平台将呼叫路由到企业配置的通信服务，再由应用选择 AI Agent 或人工坐席进行处理。
如果客服需要接入网页、App 和电话等多个入口，系统还应考虑不同通道之间的会话关联、音频格式适配和客户身份管理。
例如，电话网络可能使用 8kHz 窄带音频，而语音识别服务可能需要其他采样率。音频格式转换、回声处理和传输缓冲都会影响最终识别效果及响应延迟。
2. 语音识别：把用户说的话转成可处理的输入
电话接通后，ASR（Automatic Speech Recognition，自动语音识别）负责识别用户语音。
客服场景常见的挑战包括方言、口音、电话背景噪声，以及订单号、商品名称和地址等专有信息。
例如，“订单 1286”和“订单 1268”只相差两个数字，但识别错误可能导致系统查询错误记录。
开发者可以结合业务热词、结构化参数校验和必要的语音复述，降低关键字段识别错误的风险。
对于需要用户连续表达的问题，可以采用流式 ASR，在用户尚未结束说话时持续获取中间识别结果。但涉及订单号、金额等关键字段时，仍应等待相对稳定的结果并进行校验。
3. 意图理解：确定用户真正要完成什么任务
用户说“我想改一下配送时间”，只是提出了一个意图，还不足以直接执行操作。
系统需要进一步确认订单、识别目标时间，查询当前订单是否支持修改，并根据平台规则决定是否执行。
在任务型 Voice Agent 中，LLM 通常承担自然语言理解、上下文管理和工具选择等工作。
应用层则负责将业务操作定义为受控任务。例如：
get_order_status：查询订单状态。get_delivery_slots：查询可选择的配送时段。update_delivery_time：修改配送时间。create_support_ticket：创建客服工单。
这些只是业务接口的示例名称，并非某个模型或通信 SDK 自动提供的内置接口。
大模型可以负责判断何时使用这些工具，但工具的真实执行逻辑、权限检查和数据更新，必须由企业自己的业务服务完成。
4. Function Calling：从理解需求进入系统操作
Function Calling（函数调用）允许大模型根据用户意图选择工具，并生成符合预设参数结构的调用请求。
例如，用户要求查询订单时，模型可能生成如下逻辑请求：
{
"tool": "get_order_status",
"arguments": {
"order_id": "1286"
}
}上述 JSON 仅用于展示工具调用意图，不是可直接提交到声网 API 的完整配置。
业务服务器接到请求后，需要验证用户是否有权访问该订单，再调用订单系统接口获取真实状态。
如果订单显示“已经发货”，模型应基于真实结果向用户解释，而不能根据对话内容猜测订单状态。
如果用户继续要求修改配送时间，系统还需要查询可用时段并确认修改条件。
通常建议将查询类操作与修改类操作分开授权。查询订单属于读取数据，修改配送时间、发起退款或取消订单则可能产生实际业务影响。
后者应该在必要时要求用户确认，并由服务端执行最终权限校验。
5. 结果确认：接口返回成功，不等于整个任务已经完成
AI 客服完成工具调用后，需要根据业务系统的真实响应决定如何回复。
例如，修改配送时间的接口可能返回以下结果：
- 修改成功，并返回新的配送时间。
- 订单已进入配送阶段，不允许修改。
- 目标时间没有可用配送资源。
- 接口超时，暂时无法判断是否执行成功。
最后一种情况尤其需要注意。
如果工具调用超时，系统不能直接告诉用户“修改失败”，因为请求可能已经到达业务服务器，只是响应没有及时返回。
也不能未经核实就再次提交相同请求，否则可能引发重复操作。
对于有副作用的业务接口，开发者需要设计幂等键、操作状态查询和必要的补偿流程。
例如，创建退款申请时，可以使用由业务服务器生成的唯一操作标识，避免同一申请因网络重试而重复提交。
AI 客服只有在业务系统明确确认结果后，才能向用户承诺相应操作已完成。
三. 工具调用期间，如何避免 AI 客服突然沉默？
任务型 AI 客服通常需要访问订单、CRM、库存或工单系统。工具调用使 Agent 能够处理真实业务，但也会带来额外等待。
例如，用户询问订单问题时，系统可能先查询订单，再访问配送服务，最后检查修改规则。如果这些请求按顺序执行，等待时间可能明显增加。
1. 一通电话的延迟来自多个环节
从用户说完问题到听见 AI 回复，中间可能经过：
语音轮次判断 → ASR 最终识别 → LLM 工具选择 → 业务接口调用 → LLM 回复生成 → TTS 音频生成 → 电话链路播放。
实际系统还存在音频采集和传输、缓冲、编码及解码等耗时。
需要注意，流式 ASR、提前推理以及流式 TTS 可以使部分处理阶段重叠，因此不能简单地把所有模块耗时机械相加。
工程上建议分别记录：
- 首音频响应时间：用户结束发言到听到 AI 第一段回复的时间。
- 工具调用耗时：从发起工具调用到获得可用结果的时间。
- 任务完成耗时：从用户提出请求到业务系统确认完成的时间。
- 打断响应时间：用户插话后，系统停止旧回复并开始处理新输入的时间。
其中，首音频响应很快，不代表整个任务已经处理完成。
2. 区分同步查询和长时间任务
查询订单状态可能只需要一个接口请求，而取消订单、审批退款或复杂故障排查，可能涉及多个系统。
对于较短的只读查询，可以直接等待结果，再向用户播报。
对于耗时较长的任务，可以由业务系统建立任务状态，让 Agent 先告知用户正在处理，再在获得结果后继续说明。
但系统不能在尚未确认任务状态的情况下反复承诺“马上完成”。
如果电话可能在执行期间挂断，还需要考虑业务任务是否继续执行，以及是否通过短信、App 通知或回呼向用户反馈结果。
3. 用户插话以后，已经提交的业务请求怎么办？
假设用户说“取消订单”，系统开始调用接口。随后用户突然说“等一下，先别取消”。
语音系统可以停止当前播报并理解新要求，但这并不意味着已经发出的业务请求会自动撤销。
开发者需要在业务层区分三个状态：尚未提交、正在执行和已经完成。
如果操作尚未提交，可以中止；如果请求已经进入执行阶段，必须查询真实状态，并在业务允许时执行撤销或补偿操作。
对于退款、支付、订单取消等敏感操作，最好在发起不可逆的请求之前获得明确确认。
这类设计比单纯缩短语音打断延迟更重要，因为它直接影响业务数据的一致性。
四. AI 客服什么时候应该转接人工？
一套成熟的 AI 客服系统，不需要追求所有电话都由 AI 独立完成。
对于权限不足、业务异常、投诉升级和高风险操作，人工客服仍然是服务流程的一部分。
1. 转人工不应该只依赖用户重复要求
常见的转接条件包括：
- 用户明确要求人工客服。
- 多轮交互后仍无法确定用户意图。
- 业务系统连续出错，无法完成请求。
- 需要人工审核、特殊授权或例外处理。
- 涉及投诉、纠纷或其他高风险服务场景。
开发者可以结合任务失败次数、业务规则以及客户表达的诉求设置转接条件，而不是仅依靠模型对用户情绪的主观判断。
2. 转接时，人工坐席应该拿到什么？
如果用户已经向 AI 解释了订单问题，转人工后还需要从头复述，AI 客服实际上没有减少多少服务成本。
合理的转接流程应该让人工坐席获得必要的上下文，例如已验证的客户身份、问题摘要、当前订单、已查询的数据、已执行操作及失败原因。
与此同时，企业需要控制敏感信息的展示范围，并根据权限和合规要求处理通话记录与转写文本。
电话媒体的转接和会话上下文的移交也是两个不同问题。即使 SIP 或呼叫中心支持电话转接，CRM 页面同步、工单创建和上下文交接仍需要业务系统配合。
3. 怎样判断 AI 客服真的解决了问题？
通话数量、接通率和平均通话时长都可以作为运营指标，但不能独立证明 AI 已经完成客户服务。
建议区分以下指标：
- 接通率：呼叫是否成功进入客服服务。
- 自助完成率：符合条件的电话中，AI 独立完成业务任务的比例。
- 首次联系解决率（FCR）：客户问题是否在首次联系中解决。
- 人工转接率：需要转接人工的电话占比。
- 工具执行成功率：业务操作是否得到后端系统确认。
- 重复来电率：用户是否因为问题未解决而再次联系。
- 单次已解决问题成本：总服务成本与实际解决问题数量之间的关系。
对于自动外呼，还需要另行记录有效接听率、用户授权状态和任务完成情况。
尤其不能将“AI 接听了多少通电话”直接等同于“AI 解决了多少客户问题”。
五. 声网对话式 AI 如何支持电话智能客服？
AI 电话客服通常需要将实时通信、语音模型、Agent 编排和企业业务接口连接起来。
声网对话式 AI 引擎提供实时语音交互和模型接入能力，开发者可以结合实际业务配置 LLM、ASR、TTS 及工具调用功能。
1. 实时语音交互：处理电话中的连续对话与打断
声网对话式 AI 引擎面向需要实时语音交互的场景，支持对接主流语音识别、语言模型及语音合成服务。
客服用户可能在 AI 播报业务说明时插话，例如要求重复某个金额、补充订单信息或直接提出新的问题。
因此，开发者需要关注轮次检测、打断控制和播放状态管理，减少用户等待，同时避免对话历史与实际播报内容不一致。
在使用电话接入时，还需要考虑电话链路本身的编解码、网络抖动及运营商侧延迟，不能直接把模型侧的性能指标等同于实际电话体验。
2. 自定义工具调用：接入订单、库存与工单系统
声网自定义工具调用开发文档已经提供了通过 HTTPS 请求访问企业业务系统的方式。
开发者可以为支持 Function Calling 的标准文本 LLM 配置工具定义和服务端接口，在符合条件时由智能体发起 GET 或 POST 请求。
例如，查询订单状态时，模型根据对话生成工具参数，引擎执行请求，再将结果交给模型组织最终回复。
当前文档说明，自定义工具调用支持同步 HTTP 请求，暂不支持通过该机制直接执行异步任务、自动重试或请求回滚；具体模型支持范围和配置限制应以对应版本文档为准。
对于取消订单、创建退款申请等有副作用的操作，业务服务仍需要自行实现身份认证、幂等控制和操作结果确认。
此外，用户打断当前播报并不能保证已经发出的 HTTP 请求被取消。因此，高风险业务变更必须由应用层处理状态和撤销逻辑。
3. 人工客服与业务系统仍然需要独立建设
声网提供的实时通信和对话式 AI 能力，可以作为智能客服中的语音交互与 Agent 运行基础设施。
但人工坐席工作台、CRM、订单管理、客服工单、权限系统和电话服务合规功能，并不会因为接入对话式 AI 引擎就自动具备。
企业需要根据现有系统设计完整的客服流程，包括呼叫路由、坐席转接、业务系统认证、信息保护及操作审计。
这样才能把实时语音交互能力真正接入到业务处理流程中。
六. 结语
DoorDash 的实践说明，生成式 AI 可以在既有电话客服系统中承担部分高频咨询工作，并通过企业知识库改善自助问答体验。
但对于订单修改、售后申请、预约和客户资料更新等业务，AI 还需要访问真实系统，遵守权限与业务规则，并确认执行结果。
一套能够投入生产的 AI 电话客服系统，需要同时处理三类问题：电话和实时语音交互是否稳定，Agent 是否正确理解和选择业务操作，以及企业系统是否安全、可靠地完成任务。
在这个架构中，RTC、SIP 等通信能力负责连接用户与服务，ASR、LLM、TTS 负责语音理解与回复，Function Calling 将对话连接到业务接口，企业后台负责权限、安全和最终执行。
对于开发团队，最值得优先优化的也不是让 AI 听起来多像真人，而是提高真实业务的完成率：查询结果准确，操作状态明确，异常能够恢复，必要时顺利转人工。
做到这些之后，AI 电话客服才真正具备从接听电话走向独立处理业务的能力。
