简介这是一套面向电话营销与智能客服场景的AI语音通话销售机器人源码适合具备一定后端与语音开发基础的技术人员、创业团队及企业二次开发使用可解决自动外呼、客户意图识别与对话应答等需求。资源包共2002个文件约103.6MB以795个js脚本、216个css与203个html页面构成前端与业务逻辑51个php与6个sql负责服务端与数据存储另有66个so动态库、49个h头文件及freeswitch相关组件支撑语音通信底层并含少量wav音频、ttf字体与json配置。已有1239人学习下载。内容覆盖NLP语义解析、ASR语音识别、TTS语音合成与机器学习对话策略等模块附带系统搭建教程涉及环境配置、源码编译、数据库连接与API接口设置读者可据此部署运行、调整对话策略并集成CRM等企业系统同时需关注电话营销合规、数据安全与高并发性能优化。1. 语音通话机器人源码拆包从拨号到对话的完整链路很多做电销系统的团队都遇到过同一个尴尬买来的成品机器人对话僵硬、打断后接不上话、并发一上来就炸。与其被黑盒卡脖子不如直接拿一套能跑通的源码自己改。这份 AI 智能电话语音通话销售机器人源码核心就是一条完整的语音通话链路——从 SIP 注册、拨号、ASR 识别、NLU 意图解析、TTS 合成到对话状态管理全部以源码形式交付附带系统搭建教程。它适合两类人一是想快速搭一套外呼 Demo 验证业务的中小团队二是需要深度定制对话逻辑、不想被 SaaS 平台按分钟计费绑死的开发者。下面我按实际拆包和部署的顺序把这条链路讲透。2. 语音通话链路拆解SIP 信令、音频流与对话状态机2.1 为什么是 FreeSWITCH 外挂 AI 服务而不是全自研拿到源码第一件事是看架构。这套系统没有把语音通话和 AI 推理揉在一个进程里而是用 FreeSWITCH 做信令和媒体处理AI 部分通过 WebSocket 或 HTTP 接口外挂。这个选型很务实FreeSWITCH 处理 SIP 注册、呼叫建立、RTP 音频流是成熟方案你不需要重新造轮子而 ASR、NLU、TTS 这些模块迭代快独立部署方便单独替换。常见做法是 FreeSWITCH 通过 mod_event_socket 或 ESLEvent Socket Library把通话事件推给业务层业务层拿到音频流后送 ASR识别出文本再走 NLU生成回复后调 TTS 合成音频最后把音频推回 FreeSWITCH 播放给客户。整条链路的关键在于音频流的实时性和对话状态的连续性——客户说了一半被打断状态机得知道当前在哪个节点下一句该接什么。源码里通常有一个call_handler模块负责这个调度。我一般会先确认它用的是同步还是异步模型。同步模型在低并发下没问题但一旦同时有几十路通话ASR 返回慢一点就会阻塞整条链路。异步模型用事件驱动每路通话有独立的状态上下文扩展性更好。2.2 对话状态机的实现与意图槽位设计语音通话机器人和文本客服最大的区别是客户不会按你预设的流程走。他可能上来就问价格也可能先聊两句再问功能还可能中途挂断。所以对话状态机不能是简单的线性流程得有意图识别加槽位填充的机制。源码里一般会定义一个DialogState结构包含当前节点、已收集的槽位、对话历史。NLU 模块输出意图和实体后状态机根据当前节点和意图决定跳转到哪个节点。比如客户问“你们这个多少钱”意图是ask_price状态机就跳到报价节点同时把价格信息填入槽位。# 对话状态机核心逻辑示意 class DialogState: def __init__(self): self.current_node greeting # 当前对话节点 self.slots {} # 已收集的槽位信息 self.history [] # 对话历史用于上下文理解 def transition(self, intent, entities): 根据意图和实体决定下一个节点 # 打断处理如果客户在机器人说话时插话优先响应新意图 if intent interrupt: self.history.append((interrupt, entities)) return self.current_node # 保持当前节点等待客户说完 # 意图路由表实际项目中会从配置文件加载 route_map { ask_price: quote, ask_feature: feature_intro, want_human: transfer_agent, reject: end_call } next_node route_map.get(intent, fallback) self.current_node next_node self.slots.update(entities) self.history.append((intent, entities)) return next_node这段代码的关键在interrupt分支。语音通话里打断是高频事件如果状态机不处理打断客户说“等一下”的时候机器人还在自顾自念话术体验直接崩。参数route_map建议做成外部配置方便运营人员调整意图到节点的映射不用改代码重新部署。槽位设计上销售场景常见的槽位包括产品名称、预算范围、联系方式、意向等级。NLU 识别出这些实体后填入slots后续节点可以直接引用。比如报价节点需要知道客户问的是哪个产品就从slots里取。2.3 音频流的编解码与实时性调优语音通话的音频流默认走 RTP 协议编码格式常见的有 PCMU、PCMA、G.722。FreeSWITCH 默认用 PCMU采样率 8kHz。但 ASR 引擎通常要求 16kHz 采样率的 PCM 数据所以中间需要一个重采样步骤。源码里一般会在audio_bridge模块做这件事从 FreeSWITCH 拿到 8kHz 的音频帧重采样到 16kHz再送给 ASR。如果这一步处理不好ASR 识别率会明显下降。我踩过的坑是重采样算法用了简单的线性插值高频部分失真严重后来换成带限插值才正常。实时性方面音频帧的大小很关键。FreeSWITCH 默认每 20ms 一帧这个粒度对 ASR 来说太细一般会攒 3 到 5 帧再送。但攒太多会增加延迟客户说完到机器人响应之间超过 800ms 就能感觉到卡顿。建议攒 3 帧也就是 60ms 的音频数据配合 ASR 的流式识别接口能在 300ms 内出中间结果。注意如果部署环境网络抖动大RTP 丢包会导致 ASR 识别断断续续。源码里通常有丢包补偿逻辑但效果有限建议在服务器端做网络质量监控丢包率超过 2% 就告警。3. 从源码到可运行系统环境搭建与参数配置3.1 基础环境依赖与安装顺序这套源码的搭建教程一般会列一堆依赖但顺序很重要。我习惯按这个顺序来先装 FreeSWITCH再装 Python 运行环境然后装 ASR/TTS 引擎最后配业务层。FreeSWITCH 在 Linux 上的安装源码编译比包管理安装更可控。编译参数里--enable-core-odbc-support和--enable-openssl建议打开后面接数据库和加密信令会用到。编译完先跑freeswitch -nonat确认能启动再改配置文件。# FreeSWITCH 源码编译核心步骤 git clone https://github.com/signalwire/freeswitch.git cd freeswitch ./bootstrap.sh ./configure --enable-core-odbc-support --enable-openssl make make install # 安装声音文件和默认配置 make sounds-install make moh-install # 启动测试 freeswitch -nonat -nc # 进入控制台 fs_cli-nonat参数表示不处理 NAT 穿透如果服务器有公网 IP 直接这么跑。-nc表示不加载控制台后台运行。fs_cli是命令行控制台用来查看注册状态和呼叫事件。Python 环境建议用 3.8 以上源码里的异步框架通常依赖asyncio。ASR 和 TTS 如果用的是开源方案比如 Vosk 做识别、EdgeTTS 做合成安装相对简单如果用商业 API需要申请密钥并配置到环境变量里。3.2 SIP 账号配置与拨号规则FreeSWITCH 的 SIP 账号配置在conf/directory/default/目录下每个账号一个 XML 文件。源码教程里一般会给一个模板改一下用户名和密码就行。!-- conf/directory/default/1001.xml -- include user id1001 params param namepassword valueyour_password/ /params variables variable nameuser_context valuedefault/ variable nameeffective_caller_id_number value1001/ /variables /user /include拨号规则在conf/dialplan/default.xml里配。外呼场景一般会配一个前缀比如拨9开头走外线。关键参数是originate命令的超时时间默认 60 秒太长建议改成 30 秒避免无效号码占用通道。!-- 外呼拨号规则 -- extension nameoutbound_call condition fielddestination_number expression^9(\d)$ action applicationset datacall_timeout30/ action applicationbridge datasofia/gateway/your_gateway/$1/ /condition /extensioncall_timeout控制呼叫超时bridge里的your_gateway需要替换成实际网关名称。如果对接的是运营商 SIP 线路网关配置在conf/sip_profiles/external/下。3.3 AI 服务对接参数与并发调优业务层和 AI 服务的对接核心参数有三个ASR 的静音检测阈值、TTS 的语速和音色、对话超时时间。静音检测阈值决定机器人什么时候认为客户说完了。设太高客户停顿一下机器人就抢话设太低客户说完了机器人还在等。我一般从 800ms 开始调根据实际通话录音微调。TTS 语速建议 1.0 到 1.2 倍太快客户听不清太慢显得不专业。并发调优方面FreeSWITCH 单机跑 200 路并发通话问题不大瓶颈通常在 ASR 服务。如果 ASR 是单实例部署并发上来后识别延迟会飙升。建议 ASR 做水平扩展业务层用负载均衡分发音频流。# 业务层并发控制示意 import asyncio from concurrent.futures import ThreadPoolExecutor class CallSession: def __init__(self, call_id, asr_client, tts_client): self.call_id call_id self.asr asr_client self.tts tts_client self.state DialogState() self.silence_threshold 0.8 # 静音检测阈值单位秒 async def handle_audio(self, audio_frame): 处理单路通话的音频流 text await self.asr.recognize(audio_frame) if not text: return # 静音或无效音频继续等待 intent, entities await self.nlu(text) next_node self.state.transition(intent, entities) reply self.generate_reply(next_node, self.state.slots) audio_out await self.tts.synthesize(reply) return audio_out这段代码里silence_threshold是核心参数实际项目中会做成可配置项。asyncio保证每路通话独立协程互不阻塞。如果 ASR 调用是同步的需要用ThreadPoolExecutor包一层避免阻塞事件循环。4. 避坑与排查语音通话机器人部署中的五个高频翻车点4.1 现象机器人听不到客户说话ASR 一直返回空原因通常是音频流方向搞反了。FreeSWITCH 的 RTP 流有发送和接收两个方向业务层如果只接了发送方向自然拿不到客户的音频。排查时先在fs_cli里执行show channels看通道状态再用uuid_record录一段通话音频确认客户声音有没有进到系统。解决方法是检查audio_bridge模块的订阅逻辑确保同时订阅了read和write事件。另外确认 SIP 协商的编码格式和 ASR 要求的格式一致不一致时重采样逻辑要正确。4.2 现象客户打断后机器人还在念旧话术这是对话状态机没有处理打断事件。很多源码的默认实现是等 TTS 播放完才处理下一轮输入客户插话时音频还在播状态机也没更新。解决方式是在 TTS 播放通道上加一个中断标记检测到客户说话就立即停止播放并把当前意图设为interrupt让状态机优先响应新输入。具体实现上可以在CallSession里加一个is_speaking标志ASR 检测到有效语音时置为FalseTTS 播放循环里检查这个标志一旦为False就跳出播放。4.3 现象并发超过 50 路后通话质量断崖式下降原因一般是 ASR 服务过载。单实例 ASR 的吞吐量有限并发上来后请求排队识别延迟从 200ms 涨到 2 秒以上。排查时看 ASR 服务的 CPU 和内存占用如果 CPU 打满就是算力不够。解决方法是 ASR 水平扩展业务层加一个简单的轮询负载均衡。另外可以按通话优先级分配资源高意向客户的通话走独立 ASR 实例普通外呼共用另一个实例。4.4 现象TTS 合成的声音机械感重客户听两句就挂这是音色和韵律问题。开源 TTS 默认音色通常比较生硬解决方式有两个一是换用质量更好的 TTS 引擎二是对合成文本做预处理在标点处加适当停顿数字和英文单词做特殊处理。我一般会在 TTS 前面加一个文本规范化模块把“1000”转成“一千”把“ABC”转成“A B C”避免 TTS 读错。停顿方面逗号后加 200ms 静音句号后加 400ms听起来自然很多。4.5 现象外呼号码被标记为骚扰电话这是线路和拨号策略问题。高频外呼同一个号段容易被运营商拦截。解决方式是控制外呼频率同一号码 24 小时内不超过 3 次不同号码之间加随机间隔。另外线路要选正规运营商不要用来路不明的网关。源码里一般有拨号频率控制模块检查call_interval参数默认可能是 1 秒建议改成 3 到 5 秒并加随机抖动。5. 进阶技巧用录音回放做对话逻辑的离线验证部署完跑通之后别急着上生产。我习惯先用录音回放做一轮离线验证把常见客户应答录成音频文件批量喂给对话引擎看状态机跳转和回复生成是否符合预期。这个方法比实时拨测效率高得多而且能复现边界场景。具体做法是写一个replay_test脚本读取录音文件列表逐个模拟音频流输入记录每轮的意图识别结果和状态机跳转路径。重点看三类场景客户直接问价格、客户说“不需要”、客户中途沉默超过 10 秒。# 录音回放测试脚本核心逻辑 import json from pathlib import Path def replay_test(audio_dir, expected_file): 批量回放录音对比预期对话路径 expected json.loads(Path(expected_file).read_text()) results [] for audio_file in sorted(Path(audio_dir).glob(*.wav)): session CallSession(call_idaudio_file.stem, ...) path [] for frame in read_audio_frames(audio_file): text asr.recognize(frame) if text: intent, entities nlu(text) node session.state.transition(intent, entities) path.append({text: text, intent: intent, node: node}) results.append({file: audio_file.name, path: path}) # 对比预期路径 if path ! expected.get(audio_file.stem): print(f[FAIL] {audio_file.name} 路径不符) return results这个脚本的关键是expected_file里面按录音文件名存了预期的对话路径。每次改完对话逻辑跑一遍回放测试几分钟就能覆盖几十个场景。比人工拨测靠谱得多而且能纳入 CI 流程。参数方面read_audio_frames的帧大小要和线上一致否则静音检测行为会不同。我一般用 60ms 一帧和线上攒帧策略保持一致。另外录音文件建议用 16kHz 单声道 WAV避免重采样引入的差异。从那以后我每次改完对话逻辑都强制走一遍录音回放加边界场景检查确认状态机没有死循环、打断处理正常、超时挂断生效才敢推到测试环境。希望帮到你。本文还有配套的精品资源点击获取