来接电话从零搭建一套 AI 自动接电话助理的本地部署方案“来接电话”这句话如果从 AI 嘴里说出来场景就完全变了。这篇文章不围绕某个现成的一键包而是给出一套比较完整的“AI 接电话助手”技术选型与搭建路线覆盖电话接入、语音识别ASR、对话生成LLM、语音合成TTS四个核心环节并重点回答几个读者最关心的问题本地跑需要什么硬件、显存大概什么量级、能不能接 API、支不支持批量任务、以及这套东西用起来有哪些边界要守住。先说结论靠当前开源的 ASR、LLM、TTS 组件组合出一套自动接听、自动应答、自动挂断的电话助理是可行的而且不需要电信运营商给你开放什么特殊能力。如果你有自己的 SIP 线路或者只是在局域网里做概念验证都可以在普通 PC 或小显存显卡上跑通。这篇文章会把每个环节的开源方案、启动思路、测试方法和排查清单都写清楚适合想自己做语音助手、客服机器人或电话通知系统的开发者参考。整套方案的难点不在某一个模型而在“电话事件”和“AI 对话”之间的衔接。电话来了要自动摘机摘机后要把对方的话转成文字文字交给大模型生成回复再把回复文本合成语音放给对方听最后还要判断什么时候该挂断。任何一个环节卡住整个链路就断。下面按这个链路逐层拆。1. 核心能力速览能力项说明项目类型组合式开源方案非单一模型电话接入方式SIP 软电话 / VoIP 网关 / 模拟语音卡语音识别ASRWhisper、FunASR、SenseVoice 等开源模型对话生成LLM本地部署或云端 API 调用语音合成TTSGPT-SoVITS、Edge-TTS、CosyVoice 等启动方式各模块独立启动通过 HTTP/WebSocket 串联显存需求需按实际选型测试小参数量模型可 CPU 推理支持 API每模块基本都提供 HTTP 接口支持批量任务支持批量外呼通知但需自建呼叫队列适合场景个人语音助手、客服预筛选、电话通知、会议助理表格里这些能力并不是某一个项目开箱即用而是通过已有开源组件组合出来的。好处是每一层都能替换比如你觉得 Whisper 识别中文不够快可以换 FunASR不想本地跑大模型可以用云端 API想要更自然的音色可以换成 GPT-SoVITS 的克隆音色。坏处是每一层都要自己接一遍调试成本比一键包高。对开发者来说这个代价通常可以接受。2. 适用场景与使用边界先明确这套方案适合谁、不适合谁再动手不然很容易做到一半发现方向不对。2.1 适合的场景第一类是个人电话助理。来电时先由 AI 接听做简单问答记录留言再通过微信、邮件或钉钉把内容推送给你。第二类是客服预筛选企业用小号跑一个 AI 前台先问清楚用户意图再转接人工能省掉大量重复的“您好请问有什么可以帮您”。第三类是批量电话通知比如停电通知、活动确认、回访调研用批量外呼加 AI 对话比人工打电话快得多。这三类场景的共同点是对话内容相对固定、容错率比较高、不需要像真人客服那样处理非常复杂的情绪。如果你要做的是医疗问诊、法律咨询、金融交易确认这类高风险场景AI 接电话目前只能做初步信息收集最终判断必须交给人工。2.2 不适合的场景不适合把它当成一个完整的“替身”来用。AI 接电话目前很难处理口音非常重、背景噪音很大、说话含糊不清的情况多人同时说话时ASR 也很容易出错。另外如果你没有任何可以接进来的电话线路只想在电脑上点一点就接手机来电那需要依赖具体的硬件方案和运营商能力不能指望纯软件解决。2.3 合规与安全边界这句话要写在最前面这套方案只能用于你自己拥有或已获得合法授权的电话线路和通话内容。无论是接听还是外呼都涉及通话双方的隐私。建议做到以下几点通话开始前用语音提示“本次通话由 AI 助理接听可能会被录音”外呼场景更需要明确告知对方身份。录音文件、转写文本、对话日志必须加密存储不要明文落盘。不要用真实人物的声音做克隆音色除非你拥有该声音的授权更不要用 AI 冒充真人进行诈骗或骚扰。涉及人脸、声音、身份证号、银行卡号等敏感信息建议在系统设计上自动过滤或脱敏。技术本身是中性的但电话这个入口涉及真实人际关系和法律责任合规意识必须前置。后面所有代码示例都默认你是在自己的测试环境、自己的号码上做验证。3. 总体架构设计先画一个逻辑链路方便后面理解每一层要做什么来电接入SIP 网关/软电话 ↓ 自动摘机检测来电事件并接通 ↓ 语音识别 ASR对方说话 → 文本 ↓ 对话管理 LLM文本 → 回复文本 ↓ 语音合成 TTS回复文本 → 音频 ↓ 播放与结束播放音频 → 挂断/转人工每一层之间的数据传递可以走 HTTP 回调也可以走 WebSocket 实时流。对实时性要求高的场景建议 ASR 和 TTS 都选支持流式推理的方案对概念验证来说先做完一轮“录音 → 识别 → 生成 → 合成 → 播放”的离线流程就够了。在动手装环境之前先把各模块的选型列表搞清楚。下面的表格给出的是当前常见的主流开源方案具体版本和接口以你实际安装的为准。模块可选方案说明电话接入Asterisk / FreeSWITCH开源软交换支持 SIP 注册与自动应答ASR 语音识别Whisper, FunASR, SenseVoice中文场景优先考虑 FunASR/SenseVoiceLLM 对话Qwen、DeepSeek、Llama 等本地部署或 API 调用均可TTS 语音合成GPT-SoVITS、CosyVoice、Edge-TTS追求自然度用 GPT-SoVITS追求轻量用 Edge-TTS如果你完全不想碰电话硬件还有一个更简单的验证方式在电脑上直接录制一段对方的音频文件用 Python 脚本把“音频 → 文本 → 回复 → 音频”走一遍。这套链路跑通了再接 SIP 电话。我建议所有第一次做的人先走这条纯离线验证路线。4. 环境准备与硬件门槛4.1 操作系统Windows、Linux、macOS 都能跑但长期稳定运行建议用 Linux。Ubuntu 22.04 是当前兼容性比较好的选择社区文档多遇到问题容易搜到答案。4.2 GPU 与显存显存需求完全取决于你选哪一档模型只跑轻量 ASR 小参数量 LLM 轻量 TTS纯 CPU 也能跑只是速度慢一些。跑 7B 左右的 LLM 量化版比如 Qwen2.5-7B-Instruct 的 4bit 量化常见 8G 显存的显卡可以尝试实际占用以推理参数为准。跑 14B 以上模型建议 16G 以上显存。GPT-SoVITS 推理阶段显存占用不高但训练音色模型时建议至少 8G 显存。以上都是经验区间不是固定值。实际显存占用受上下文长度、批量大小、量化格式影响很大。第一次跑的时候用nvidia-smi盯着看以本机实测为准。4.3 其他前置条件Python 3.10 或 3.11避免太高版本遇到依赖兼容问题。CUDA 和 cuDNN版本需要和你安装的 PyTorch 匹配。FFmpeg几乎所有音频处理都依赖它。磁盘空间至少预留 30G 以上模型文件比想象中大。端口规划服务多了之后要避免冲突建议固定分配SIP 5060ASR 9001LLM 8000TTS 9880API 网关 8080。下面给出一份适用于 Debian/Ubuntu 的环境初始化命令# 更新系统基础软件 sudo apt update sudo apt install -y ffmpeg git curl wget # 安装 Python 虚拟环境工具 sudo apt install -y python3.10-venv python3-pip # 检查显卡驱动有 NVIDIA 显卡时执行 nvidia-smi注意nvidia-smi如果提示找不到命令说明驱动没装好后续 PyTorch 的 CUDA 推理肯定起不来。5. 电话接入自动摘机是第一步“接电话”三个字落到技术上第一步是自动摘机。这里有两种常见路线。5.1 用 SIP 软交换做自动应答Asterisk 或 FreeSWITCH 可以注册 SIP 分机当来电到达时通过拨号计划Dialplan自动执行 Answer 指令。以 Asterisk 为例核心思路是配置一个 extension收到来电后自动接听并播放或转接。[auto-answer] exten s,1,Answer() exten s,n,Wait(1) exten s,n,Playback(hello) exten s,n,Hangup()这段配置的意思是来电后自动摘机等 1 秒播放一段提示音然后挂断。它可以用来验证线路是否通路。实际项目中你通常不会直接播放固定音频而是通过 AGIAsterisk Gateway Interface或 AMIAsterisk Manager Interface把通话中的音频流交给外部程序处理。想快速验证电话线路可以先在局域网里跑一个 SIP 软电话比如 MicroSIP注册到 Asterisk然后从另一个终端拨号进来。能听到自动播放的音频说明 SIP 链路已经打通。5.2 纯软件模拟如果暂时没有 SIP 线路可以用音频文件模拟来电。做法是用手机或电脑录一段“你好我想咨询一下你们的产品”保存为input.wav后面的 ASR 步骤直接处理这个文件。这样可以把“电话接入”和“AI 对话”两个问题解耦先跑通后者。6. 语音识别ASR把对方的话变成文字自动摘机之后系统需要把通话中对方的语音实时转成文本。目前可选的方案很多按使用体验排序中文场景比较稳妥的是 FunASR 和 SenseVoiceWhisper 的优点是支持语言多缺点是中文识别速度和准确率不一定比专门的中文模型好。6.1 离线识别测试先用离线文件验证 ASR 流程。下面以 OpenAI Whisper 的 Python 接口为例import whisper model whisper.load_model(small) # 可选 tiny/base/small/medium/large result model.transcribe(input.wav, languagezh) print(result[text])tiny和base模型可以在 CPU 上跑速度快但识别效果一般。small和medium在中文场景下更可用显存占用从材料看属于轻量级实际以本机为准。如果音频里有明显噪音可以先做降噪预处理。6.2 流式识别与电话实时转写电话场景里对方是一边说、系统一边识别所以最好选支持流式 ASR 的框架。FunASR 提供了流式语音识别服务可以通过 WebSocket 推送音频帧返回实时识别文本。这里给一个通用调用思路import websockets import asyncio import json async def send_audio(ws, audio_path): async with ws: with open(audio_path, rb) as f: while chunk : f.read(3200): await ws.send(chunk) await ws.send(json.dumps({type: finish})) asyncio.run(send_audio(input.wav, ws://127.0.0.1:9001))实际接口路径和协议格式以你安装的 FunASR 版本为准。这一步的核心不是代码本身而是理解“音频流进来文本流出去”这个过程。6.3 识别效果判断标准清晰普通话短句正确率应该在 90% 以上达不到就考虑换更大的模型或加降噪。电话号码、金额、时间这类数字信息必须重点验证一个数字错了后面的 LLM 和 TTS 都会跟着错。停顿较长时流式识别可能会把一句话切成多段需要在对话管理层做拼接。7. 对话生成LLM让 AI 知道怎么回答ASR 输出的是文本下一步要把这段文本交给大模型让模型生成自然的回复。7.1 本地部署 vs 云端 API如果你注重数据隐私或者想在无外网环境运行就选本地部署。本地部署常见方案是 Ollama、vLLM、llama.cpp 等加载 Qwen、DeepSeek、Llama 等开源模型。以 Ollama 为例# 拉取模型并启动服务 ollama pull qwen2.5:7b ollama serve启动后 Ollama 会默认监听11434端口并提供 OpenAI 兼容的/v1/chat/completions接口。这样你可以不改代码直接从原来的 API 调用逻辑切过来。如果你只是想尽快验证效果可以先用云端大模型 API。下面以 OpenAI 兼容接口为例import requests url http://127.0.0.1:11434/v1/chat/completions prompt f 你是电话助理。用户说{user_text} 请用一句简短、友好的中文回复不要超过 50 字。 payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个电话助理正在接听用户来电。}, {role: user, content: prompt} ], temperature: 0.3 } resp requests.post(url, jsonpayload, timeout120) print(resp.json()[choices][0][message][content])注意timeout要设置得足够大因为本地 7B 模型在没有 GPU 加速时生成速度会很慢。接口地址和参数名以实际部署方式为准但整体思路一致。7.2 对话管理电话场景和聊天机器人有一个重要区别电话是要挂断的模型需要知道什么时候结束。建议在 prompt 里约好输出协议比如必须输出一个 JSON{ reply: 好的我会转告他给您回电话。, should_hangup: true }然后由业务层根据should_hangup决定是否执行挂断动作。这样比让模型直接输出文本再“猜”语义要稳定得多。7.3 判断标准与常见问题回复是否自然、是否答非所问。电话场景里模型胡说八道的成本比聊天高得多必须加高质量 system prompt 约束。生成速度是否可接受。超过 5 秒才回复用户体验会明显变差。优先用量化模型或者缩短上下文。上下文管理。电话助理不需要像 ChatGPT 那样记住几十轮历史保留最近 3-5 轮就够了既能控制显存又能减少模型跑偏。8. 语音合成TTS把回复文本变成可播放的语音这是整条链路里最直接影响听感的一环。你要的不是“能说话”而是“像正常人在打电话”。8.1 方案选型Edge-TTS完全不需要 GPU调用微软 Edge 的在线语音服务音色自然缺点是依赖外网不能离线使用。这个方案仅用于快速效果验证长期稳定使用需确认服务条款。CosyVoice阿里开源的语音合成模型支持情感控制和音色克隆需要一定显存。GPT-SoVITS可以只用 1 分钟左右的参考音频微调音色适合做指定音色的回复播报但训练和推理流程稍复杂。如果是中文电话场景先试 GPT-SoVITS 或 CosyVoice。GPT-SoVITS 的推理接口通常是一个 HTTP 服务可以传入参考音频路径和待合成文本返回生成的 wav 文件。8.2 调用示例下面是一个常见的 TTS 接口调用模板实际路径和参数需要根据你的部署方式调整import requests tts_url http://127.0.0.1:9880/tts payload { text: 您好您咨询的问题我已经记录了稍后会有专人和您联系。, reference_audio: ref.wav, prompt_text: 这里是参考音频的文字内容 } resp requests.post(tts_url, jsonpayload, timeout120) if resp.status_code 200: with open(reply.wav, wb) as f: f.write(resp.content)8.3 试听标准合成语音是否比真人慢半拍。TTS 生成通常需要 1-3 秒这个延迟要提前设计成“等待音”或“请稍等”缓冲。长句子是否需要切分。TTS 一次性输入过长文本容易出错建议按标点切句逐句合成再拼接。音色是否统一。如果每一句换一个音色电话体验会非常奇怪。9. 整体流程编排把四个模块串起来上面四个模块单独都能跑但真正让“来接电话”成立的是最后一步编排。推荐的做法是写一个 Python 控制器负责调度各个环节。import requests # 1. 读取通话音频 audio_path call_chunk.wav # 2. ASR 转写 asr_resp requests.post(http://127.0.0.1:9001/asr, files{file: open(audio_path, rb)}) user_text asr_resp.json()[text] print(用户说:, user_text) # 3. LLM 生成回复 llm_resp requests.post(http://127.0.0.1:11434/v1/chat/completions, json{ model: qwen2.5:7b, messages: [{role: user, content: user_text}] }) reply_text llm_resp.json()[choices][0][message][content] print(AI 回复:, reply_text) # 4. TTS 合成 tts_resp requests.post(http://127.0.0.1:9880/tts, json{text: reply_text}) if tts_resp.status_code 200: with open(reply.wav, wb) as f: f.write(tts_resp.content) # 5. 播放回铃通道 # 这一步在 SIP 环境里通过网络桥接完成本地验证时直接播放 reply.wav这里每一个 URL 都是占位符你需要替换成自己实际部署的服务地址。这个顺序也符合电话通话的自然逻辑对方说完一句话系统识别、思考、合成、播报然后继续听对方下一句话循环往复直到 LLM 返回挂断指令。9.1 循环对话与挂断判断电话场景不是一次性问答而是多轮对话。所以编排层需要维护一个会话循环while not should_hangup: # 获取下一段用户音频 audio_path get_next_audio_chunk() # ASR - LLM - TTS # 播放 TTS 结果 # 检查 LLM 返回的 should_hangup 字段重点是要设置超时机制。如果对方长时间不说话超过 N 秒就自动询问“您还在吗”再超 N 秒就挂断。否则通话会一直占线浪费资源。10. 接口 API 与批量外呼任务当单路通话验证完毕之后就可以扩展为接口服务和批量任务。10.1 封装 API 服务建议使用 FastAPI 把完整的“接电话”流程封装成一个 HTTP 服务供上层系统调用from fastapi import FastAPI from pydantic import BaseModel class CallRequest(BaseModel): caller_number: str audio_url: str business_type: str general app FastAPI() app.post(/api/call/answer) def answer_call(req: CallRequest): # 这里执行 ASR - LLM - TTS 流程 return { status: success, reply_audio: reply.wav }API 化之后你在上层可以对接 CRM、外呼系统、用户 App业务方只需要把来电者的音频传过来就能拿回 AI 生成的回复音频。10.2 批量外呼任务如果你要做批量电话通知系统设计上需要一个任务队列。典型做法是任务表存每一通电话的号码、业务类型、待通知内容比如“您的快递已到门口”。调度器逐个取任务通过 SIP 线路发起外呼。每次外呼走完一遍 ASR/LLM/TTS 流程把通话结果写回任务表。通话失败空号、关机、无人接听要有重试策略。{ task_id: 20250101_001, phone: 13800138000, script: 您好这里是 XX 公司您预约的维修服务将在明天上午十点进行请保持电话畅通。, max_retries: 3, status: pending }批量任务的重点不在模型而在并发控制和资源限制。本地部署的 ASR、LLM、TTS 服务同时处理太多路通话会直接把显存打爆建议一开始先限制最大并发数比如 1-2 路跑稳定了再往上加。10.3 失败重试建议区分“任务失败”和“通话失败”。任务失败通常是服务不可用通话失败可能是用户不接、号码无效、对方挂断。重试要做间隔退避不要 1 分钟内反复拨打同一号码容易被运营商限制。每通电话生成独立的录音文件和转写日志方便审计。11. 显存占用与性能观察方法整条链路跑起来之后最需要关注的就是资源占用。这里给一套通用的观察方法。11.1 怎么看显存# 每 1 秒刷新一次显存状态 watch -n 1 nvidia-smi启动 ASR 服务后看一眼显存基线再启动 LLM 后看一眼TTS 再加载后再看一次。这样能分清每个模块吃了多少。11.2 影响性能的关键因素LLM 的上下文长度上下文越长占显存越多电话场景建议限制在 2048 token 以内。并发路数每增加一路通话ASR、LLM、TTS 都会叠加占用建议先单路测试。TTS 的采样率和音频长度合成音频越长GPU 占用时间越长。ASR 的音频采样率16kHz 的采样率对电话语音来说基本够用不需要 44.1kHz。11.3 降低显存和延迟的手段ASR 换流式轻量模型CPU 推理也能接受。LLM 用 4bit 量化版或使用更小参数模型。TTS 用切句合成而不是一次性合成几百字的文本。所有服务启动后把不需要的 WebUI 关掉WebUI 本身也会占一部分显存。CPU 推理不是不能跑但延迟会明显上升。如果只有 CPU建议 ASR 用 SenseVoice 小模型LLM 换成 1.5B 或 3B 级别的小模型TTS 用轻量方案。这样整链路也是通的只是体验打折。12. 常见问题与排查方法下面这张表覆盖了从环境准备到批量外呼的主要坑点。问题现象可能原因排查方式解决方案启动 ASR 时提示 CUDA 不可用驱动版本和 PyTorch 不匹配运行python -c import torch; print(torch.cuda.is_available())重装匹配版本的 PyTorch 或更新驱动模型加载速度慢首次加载需要解码权重观察日志第二次加载会快很多把模型保存到本地目录加载时指定路径启动后页面或服务打不开端口被占用查看端口监听状态换端口或杀死占用进程电池录音转写为空录音格式不被 ASR 支持用 ffprobe 检查音频格式统一转成 16kHz/16bit/mono wavLLM 回复过慢显存不足导致 CPU fallback看日志中是否走 CPU 推理减小模型规模或清理显存TTS 合成声音断断续续长文本单次合成导致检查 TTS 日志是否报错长文本超限按标点切句逐句合成批量任务执行一半卡住某个语音服务失去响应查任务日志和进程状态加超时自动重试必要时重启服务自动摘机后没有声音SIP 线路没配好或音频设备异常先用固定语音测试线路检查 Dialplan 和音频设备配置这里特别说一下“端口被占用”是新手最容易遇到的问题。因为整个系统有多个服务每个都占一个端口建议启动前先用一条命令检查netstat -tlnp | grep -E 5060|11434|9001|9880|8000如果有进程已经占用要么换端口要么杀掉旧进程。很多“启动后页面打不开”的报错根源都是端口冲突。13. 最佳实践与使用建议整套方案跑通之后真正决定能不能稳定用的是工程细节而不是模型本身。13.1 先说一遍推荐步骤第一步用本地音频文件离线验证 ASR LLM TTS 三条链路。第二步用 SIP 软电话完成自动摘机和音频播放验证。第三步把 ASR、LLM、TTS 串起来做端到端通话测试。第四步封装 API加入批量任务和日志系统。第五步接入真实电话线路先在可控流量下运行一段时间。不要跳过第一步直接接电话线否则排查起来非常痛苦分不清是线路问题还是模型问题。13.2 工程化细节所有服务建议做成 systemd 服务或 Docker 容器开机自启并用 Supervisor 维护进程状态。通话记录和识别文本必须分目录按日期存储文件名带上任务 ID否则批量任务跑到几百通之后根本没法审计。批量外呼一定要加日志和失败重试。每一通电话至少记录开始时间、结束时间、通话状态、ASR 文本、LLM 回复、TTS 是否成功。这些日志是你排查问题的唯一依据。接口服务要限制访问范围。如果只是内网使用绑定127.0.0.1就够了如果需要跨机器调用加一个简单的 Token 鉴权不要裸奔在公网。13.3 合规检查清单在上真实场景之前逐条确认通话双方是否知情并获得授权声音克隆素材是否有明确授权敏感信息存储是否加密是否在通话中标识 AI 身份是否设置了人工转接兜底通道任何一条不满足都建议先补救再上线。技术在电话领域的效果放大效应很强一旦被恶意使用影响范围和速度都会远超普通文本应用。14. 总结与下一步“来接电话”用技术实现本质上就是“SIP 摘机 → ASR 转写 → LLM 生成 → TTS 播报 → 自动挂断”这个闭环。它不是一个现成的一键包而是一套可以按需组合的开源方案。最值得先验证的不是电话线路而是离线状态下的“音频 → 文本 → 回复 → 合成语音”流程最容易踩的坑是各服务之间的接口对接和端口管理以及显存不够导致的性能雪崩。下一步可以做的事情很多把 ASR 换成流式方案降低延迟把 LLM 换成专门的客服微调模型把声音换成更稳定的克隆音色或者把整个编排层做成带 Web 控制台的管理系统。从现在的开源组件成熟度来看个人开发者花几天时间跑通一套内部可用的 AI 接电话助理是完全可行的。建议把本文收藏起来在你动手部署的时候把这几个章节当作检查清单先确认环境再逐模块验证最后串链路。这样做完踩坑数量会少很多。接下来就是动手时间了。