企业官网建设流程全解析

最近把通义千问接进了FreeSWITCH，跑通了一个真正能打电话的大模型呼叫中心。这里说的“能打电话”不是Demo里那种播放一段预录语音，而是实打实地通过SIP链路接听用户来电，用通义千问理解用户说话内容，实时生成回答，再用TTS把答案播回去，整个全双工对话闭环跑在真实电话线上。这套东西做完之后，我自己都感慨：大模型呼叫中心这个方向，技术栈已经非常成熟了，难点根本不在模型，而在通信链路怎么和模型无缝咬合。

这篇文章主要给两类人看：一类是有FreeSWITCH基础、想接大模型的通信开发者，另一类是做大模型应用、但对传统语音链路比较陌生的AI工程师。我会把整个项目的架构设计、关键代码、踩过的坑和参数调优过程全部摊开来讲，尽量做到你能照着这篇文章直接把系统搭起来。

1. 项目概述：为什么要把大模型接进FreeSWITCH

1.1 这套系统能做什么

简单说，这套系统实现的是：用户拨打一个电话号码，接通之后，FreeSWITCH负责接听电话、采集用户语音、播放提示音，通义千问负责理解用户意图并组织语言回复，TTS负责把回复内容变成声音播给用户听。整个过程用户感知到的就是一个能自然对话的AI客服。

我在实际测试中跑通的典型场景包括：查话费余额、业务咨询、工单登记、简单故障排查，甚至还能通过函数调用让AI替用户直接操作系统里的接口，比如查询订单状态、提交预约。

这套系统的核心价值在于：它把大模型的自然语言理解能力，接到了传统通信网络上。用户不需要装App、不需要打开网页，拿起手机打电话就能和AI对话，这个入口对很多行业来说依然是最低门槛的交互方式。

1.2 整体架构与选型理由

整个系统分成五层：

• 接入层：SIP话机、运营商线路、呼叫中心中继，负责把电话信号送进FreeSWITCH。
• 通信控制层：FreeSWITCH负责呼叫状态机管理、媒体流的收发、音频编解码、录音、放音、排队。
• 语音识别层（ASR）：把用户说话的音频流转成文本。
• 大脑层：通义千问，负责对话理解、意图识别、答案生成、函数调用。
• 语音合成层（TTS）：把模型生成的文本转回自然语音。

这里最关键的决策是：通信控制放在FreeSWITCH，而不是自己写一套SIP协议栈。原因很简单——SIP信令、RTP媒体协商、NAT穿透、编解码转换这些坑，FreeSWITCH已经趟平了，而且它的Event Socket Library（ESL）接口能让我们用Python或Node.js完全接管呼叫流程，和大模型对接非常顺手。

语音识别和合成我选的是阿里云智能语音交互系列服务，和通义千问在同一个云账号体系下，鉴权方式统一、延迟稳定，省去了跨厂商调试的时间。如果你有私有化需求，ASR也可以用FunASR本地部署，TTS可以用开源方案替代，后面我会详细说。

2. 环境准备：FreeSWITCH、通义千问API与基础组件

2.1 FreeSWITCH安装与SIP接入

我开发时用的是Windows环境，生产环境部署在Linux。先说我踩过的Windows坑，再讲Linux的干净部署方式。

Windows安装FreeSWITCH，很多人卡在第一关：下载的安装包装完发现命令行跑不起来。这里有几个关键点：

• 安装路径不要带空格和中文，我习惯直接装在D:\FreeSWITCH。
• Windows版本依赖Microsoft Visual C++ Redistributable，装之前先确认系统里有最新的运行库。
• 启动之后如果netstat -an | findstr 5060看不到UDP监听，大概率是Windows防火墙拦了，需要放行5060的UDP端口和8021的TCP端口。

Linux部署就省心很多，我用的CentOS 7.9：

# 安装依赖 yum install -y epel-release yum install -y git gcc-c++ automake autoconf libtool wget python3-devel yum install -y libuuid-devel libjpeg-devel sqlite-devel # 编译安装FreeSWITCH 1.10.x cd /usr/local/src git clone https://github.com/signalwire/freeswitch.git -b v1.10 freeswitch cd freeswitch ./bootstrap.sh ./configure --prefix=/usr/local/freeswitch make -j$(nproc) make install # 安装默认配置 make cd-sounds-install make cd-moh-install

装完之后，/usr/local/freeswitch/conf下面有一套完整的默认配置，默认的default拨号计划里带了user/1000到user/1019这20个软分机。我用Linphone和MicroSIP做测试话机，注册上去就能互拨。

这里补充一个很重要的认识：FreeSWITCH本质是一个软交换+媒体服务器，它不关心你接的是SIP话机还是运营商中继，信令和媒体处理逻辑完全一样。所以开发阶段用软分机，上线阶段换成运营商中继，代码基本不用动。

2.2 通义千问API调用准备

通义千问的API走阿里云百炼平台（DashScope）。你需要先开通百炼服务，然后创建一个API Key，这个Key就是后续所有模型调用的凭证。

通义千问的模型有多个规格，我的经验是：

• qwen-turbo：响应最快，适合简单的问答和意图识别，成本最低。
• qwen-plus：综合能力平衡，客服场景我主力用这个。
• qwen-max：理解能力最强，适合复杂推理，但延迟略高。

呼叫中心场景对响应延迟非常敏感，我建议根据实际业务复杂度来选择，不要盲目上max。我这边实测，qwen-plus在普通客服问答上的表现已经足够好，首字延迟通常在300到500毫秒之间。

调通义千问API有兩種方式：直接用DashScope SDK，或者用OpenAI兼容模式的接口。我用的是后者，因为代码可以和别的模型平滑切换，降低对单一厂商的绑定。

from openai import OpenAI client = OpenAI( api_key="YOUR_DASHSCOPE_API_KEY", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1" ) def chat_with_qwen(system_prompt, user_content, history=None): messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) if history: messages.extend(history) messages.append({"role": "user", "content": user_content}) response = client.chat.completions.create( model="qwen-plus", messages=messages, temperature=0.7, stream=False ) return response.choices[0].message.content

这里有个细节：通义千问的API支持stream=True的流式输出，但在电话场景里，TTS需要整句话才能合成稳定的语音，流式输出的中间片段断句处理不好反而会导致TTS拼接卡顿，所以我生产环境用的是非流式，换取稳定。

2.3 语音链路的最后一公里：ASR与TTS选型

ASR和TTS是电话场景里最容易翻车的环节。我一开始试过本地Whisper做识别，效果确实不错，但延迟不稳定，嘈杂环境下误识别率高，而且Whisper base模型对8kHz电话音频的鲁棒性不够好。

后来换成了阿里云的实时语音识别和语音合成，效果立竿见影。电话频段是300Hz到3.4kHz，采样率8kHz，阿里云ASR可以直接吃8kHz16bit的PCM流，不需要额外重采样，省了一层转换。

TTS方面，我用的也是阿里云的语音合成，支持多种音色，我选了一个语气相对自然的客服女声。需要注意：TTS合成的音频格式要和FreeSWITCH播放器匹配，我统一用wav格式输出，采样率16kHz（TTS合成结果重新采样到16kHz是为了音质，之后在FreeSWITCH里播放时会自动转换到通话协商的编解码格式）。

ASR和TTS的鉴权方式和通义千问同源，都用API Key，这样整个项目的密钥管理只需要一套体系。

3. 核心对接方案：三种路线与最终选择

把大模型接到FreeSWITCH上，业内常见三种方案。我把三种都试了一遍，认真对比过，这里直接给结论。

3.1 方式一：ESL事件驱动——最推荐的方案

ESL全称Event Socket Library，是FreeSWITCH开放给外部程序的控制通道。外部程序通过TCP连接FreeSWITCH的8021端口（默认密码ClueCon），订阅呼叫相关事件，然后向FreeSWITCH发送API命令来控制呼叫。

这套方案的思路是：FreeSWITCH负责所有电话协议和媒体处理，你的AI应用服务器只负责“听事件、下命令”。比如有电话呼入时，FreeSWITCH会推一个CHANNEL_ANSWER事件给你的程序，你的程序收到后，发一条playback命令播放欢迎语，再发一条record命令开始录音，录音推流给ASR，ASR识别结果喂给大模型，大模型返回文字后调TTS合成音频，再发playback命令把音频播出去。

这种方式的好处是：呼叫控制逻辑完全掌握在你手里，跟大模型的交互时机、重试策略、多轮对话管理都非常灵活，是目前最主流也是社区验证最多的方案。

3.2 方式二：mod_curl拨号计划——轻量但受限

FreeSWITCH的mod_curl允许在拨号计划里直接发起HTTP请求。做法是配置一个extension，当电话进来时，用curl请求把呼叫号码、用户按键等信息发给你的后端服务，后端服务返回一段XML或指令，FreeSWITCH按返回内容继续执行放音或转接。

这种方式写起来很快，适合做简单的“按键导航+大模型回答”的轻量场景，但问题也很明显：

• 对话状态管理困难，多轮对话的上下文难以维护。
• 音频流的处理绕，你很难把实时录音交给ASR再拿回TTS结果，因为拨号计划里没有成熟的“录音流→外部服务→播放响应”的编程模型。
• 调试体验差，出了问题只能看日志，没法像ESL那样实时交互。

我做了一个简单的按键式测试后就放弃了，它适合做IVR导航，不适合做真正的AI对话。

3.3 方案对比与取舍逻辑

我把三种方案的关键差异整理成了表格：

最终我选了ESL方案。理由是：呼叫中心这个场景，控制逻辑必然复杂——需要处理来电者意图、多轮上下文、异常重试、转人工、情绪安抚策略，这些都需要一个完整的编程语言环境来承载。ESL恰好提供了这个环境，而且Python、Node.js都有非常成熟的ESL库。

4. 关键代码实现与参数细节

4.1 ESL连接与呼叫控制

Python连接FreeSWITCH ESL，社区推荐用freeswitch-esl这个库。

pip install freeswitch-esl

下面是核心连接和事件订阅代码：

import ESL import json import time import threading class CallSession: def __init__(self, esl_connection, uuid): self.con = esl_connection self.uuid = uuid self.context = [] self.caller_number = None def answer(self): self.con.api("answer", self.uuid) def play(self, file_path): # playback是阻塞执行，播完才返回 self.con.api("playback", f"{self.uuid} {file_path}") def record(self, file_path, max_sec=10, silence_hits=3): # record语法：record <uuid> <path> [time_limit] [silence_threshold] res = self.con.api("record", f"{self.uuid} {file_path} {max_sec} 0 {silence_hits}") return res

连接并订阅事件：

con = ESL.ESLconnection() con.connect("127.0.0.1", "8021", "ClueCon") con.events("plain", "all") while True: e = con.recvEvent() if e: event_name = e.getHeader("Event-Name") if event_name == "CHANNEL_ANSWER": uuid = e.getHeader("Unique-ID") session = CallSession(con, uuid) handle_incoming_call(session)

这里有个非常重要的细节：con.api()命令是同步阻塞的，比如playback一个10秒的音频，这条命令会阻塞10秒才返回。如果你的场景需要同时处理多路通话，不能用单线程串行，需要为每路通话单独建一个线程或者用协程。我实际用的是线程池方案，每路通话一个独占工作线程，线程内部串行执行“识别-理解-合成-播放”的循环，多路通话之间互不干扰。

4.2 全双工对话引擎：ASR到LLM到TTS的串联

这一节是整个项目的核心。我先把对话引擎的简化版本贴出来，然后逐行解释。

import dashscope from dashscope.audio.asr import Recognition from dashscope.audio.tts import SpeechSynthesizer class VoiceDialogueEngine: def __init__(self, llm_client, system_prompt): self.llm = llm_client self.system_prompt = system_prompt self.history = [] def process_user_utterance(self, audio_file): # Step 1: ASR text = self._asr(audio_file) if not text: return None # Step 2: LLM reply = self._llm_chat(text) # Step 3: TTS tts_file = self._tts(reply) # 更新上下文 self.history.append({"role": "user", "content": text}) self.history.append({"role": "assistant", "content": reply}) return tts_file def _asr(self, audio_file): # 使用阿里云实时识别转离线文件识别 task = Recognition.async_call( model='paraformer-realtime-v2', file_urls=[audio_file], language_hints=['zh-CN'] ) return task.get_sentence() def _llm_chat(self, user_text): messages = [{"role": "system", "content": self.system_prompt}] messages.extend(self.history) messages.append({"role": "user", "content": user_text}) resp = self.llm.chat.completions.create( model="qwen-plus", messages=messages, temperature=0.5 ) return resp.choices[0].message.content def _tts(self, text): # 合成16kHz wav audio = SpeechSynthesizer.call( model='cosyvoice-v1', text=text, voice='longcheng', format='wav', sample_rate=16000 ) # 保存为临时文件，返回路径 path = f"/tmp/tts_{int(time.time())}.wav" with open(path, 'wb') as f: f.write(audio) return path

关于process_user_utterance的完整呼叫循环，我在通话线程里这样组织：

def handle_incoming_call(session): session.answer() session.play("/tmp/welcome.wav") engine = VoiceDialogueEngine(llm_client, system_prompt) for round_idx in range(MAX_ROUNDS): # 防止无限对话 # 录音：静音2.5秒或10秒上限 audio_file = f"/tmp/record_{session.uuid}_{round_idx}.wav" session.record(audio_file, max_sec=10, silence_hits=5) # 处理用户语音 tts_file = engine.process_user_utterance(audio_file) if tts_file: session.play(tts_file) else: # 识别失败，播提示并继续 session.play("/tmp/retry.wav") # 检测用户是否想挂断 # 这个检测逻辑在下面章节说明

这里我踩过一个很关键的坑：record命令的静音检测参数需要和模型行为配合。如果静音阈值设得太低（比如1秒），用户在思考、停顿的空档就会被误判为说完话，导致录音被截断。设得太高（比如4秒），又会拖慢对话节奏。我调下来发现2到3秒的静音判定是比较合适的，既能容忍自然的说话停顿，又不会让用户等太久。

4.3 多轮会话与上下文管理

大模型呼叫中心和单轮问答最大的区别，就是多轮上下文管理。用户打电话过来，可能连续问好几个问题，AI要能记住之前聊过的内容。

我用的方案是维护一个history列表，把每轮对话追加进去，每次请求时把完整的上下文发给通义千问。这个方案实现简单直接，适合轮次少于20轮的客服场景。

MAX_CONTEXT_TURNS = 10 # 最多保留最近5轮对话 def _llm_chat(self, user_text): messages = [{"role": "system", "content": self.system_prompt}] # 只保留最近N轮，防止上下文过长 recent_history = self.history[-MAX_CONTEXT_TURNS:] messages.extend(recent_history) messages.append({"role": "user", "content": user_text}) resp = self.llm.chat.completions.create( model="qwen-plus", messages=messages, temperature=0.5 ) return resp.choices[0].message.content

上下文长度控制是必须做的。通义千问的模型有上下文窗口限制，即使支持长上下文，请求体越大，处理时间越长，电话那头的用户等不起。实测qwen-plus在上下文超过4K token之后，响应延迟会有明显上升。所以我在代码里做了截断，只保留最近5轮对话。

另一个经验是：在system prompt里明确告诉模型“你是一个电话客服，回答要简短自然，不要使用markdown格式，不要输出表情符号”。因为TTS合成时，如果模型输出了**加粗**、1. 列表项这些格式符号，合成出来的语音会把符号也读出来，非常破坏体验。我在prompt里加了约束之后，这个问题基本绝迹。

4.4 呼叫中心增强：排队、转人工与录音

基础的对话跑通之后，真正的呼叫中心还要处理排队、转人工这些场景。

排队用FreeSWITCH的park功能实现。当所有AI坐席都忙时，让新的来电进入park状态，播放保持音乐：

<extension name="ai_queue"> <condition field="destination_number" expression="^3000$"> <action application="answer"/> <action application="playback" data="/tmp/wait_for_agent.wav"/> <action application="park" data="auto_in"/> <action application="playback" data="$${hold_music}"/> </condition> </extension>

park后，来电会进入一个等待队列。业务系统可以随时通过ESL命令把排队者转给空闲的人工坐席：

# 把排队的呼叫桥接到人工坐席分机 con.api("uuid_transfer", f"{uuid} -both user/1001")

这里说一下park和hold的机制：park是让通道进入一种“置位”状态，此时可以播放保持音乐，也可以被任意程序读取和转移。和直接hangup不同，park的通道仍然活着，随时可以恢复。

录音功能我建议全程开启，不仅是合规要求，也是后续做模型评估和优化的数据来源。FreeSWITCH录音有几种方式，我用的最简单的：

# 在会话开始时启动录音 con.api("uuid_record", f"{uuid} start /tmp/call_{uuid}.wav") # 在会话结束时停止并保存 con.api("uuid_record", f"{uuid} stop /tmp/call_{uuid}.wav")

录音文件的路径可以带上业务ID、时间等信息，方便事后和对话日志做关联。

5. 常见问题与排查实录

这个项目踩坑数量远超预期，我把最有价值的经验整理一下。

5.1 Windows安装与运行崩溃

Windows版FreeSWITCH最典型的两个坑：

第一个是启动后立即崩溃退出。我查下来大部分情况是缺少VC++运行库，装上vc_redist.x64.exe就解决了。

第二个是ESL连接失败，表现为Python脚本con.connect()返回0。排查路径：先确认FreeSWITCH已经起来了，fs_cli能正常进去；再看8021端口是否监听：

netstat -an | findstr 8021

如果端口没有监听，去conf/autoload_configs/event_socket.conf.xml检查配置：

<param name="listen-ip" value="127.0.0.1"/> <param name="listen-port" value="8021"/> <param name="password" value="ClueCon"/>

注意listen-ip如果是127.0.0.1，外部机器访问不了。如果AI后端服务和FreeSWITCH不在同一台机器，需要改成实际的内网IP或者0.0.0.0并做好防火墙限制。

5.2 音频通但不说话：编码与媒体协商

我遇到过一种很诡异的情况：电话已经接通，双方都能听见声音，但ASR识别不出任何内容。抓包分析发现，录音文件里的音频格式是G.711编码的8kHz，但我的ASR服务期望的是16kHz的PCM。

这里涉及FreeSWITCH的媒体协商机制。通话双方协商的音频编码不一定是PCM。比如SIP话机如果协商成了G.729，那录音文件就是G.729压缩格式，直接丢给ASR肯定识别不了。

我最终的解决方案是：在拨号计划里强制指定使用PCM编码：

<action application="set" data="absolute_codec_string=PCMU,PCMA,L16"/>

同时在录音命令里明确采样率和位宽：

# 录音时显式指定编码参数 con.api("record", f"{uuid} /tmp/record.wav 10 0 3 8k 16k")

这里8k和16k是录音支持的采样率白名单，FreeSWITCH会按需转换。我建议录音统一存16k16bit的WAV，ASR识别准确率会明显高于8k。

5.3 early media问题：接听前的提示音

早期媒体（Early Media）是另一个高频坑。场景是这样的：用户拨打电话后，在AI接听之前，运营商侧会先送回一个“您拨打的电话正在接通中”的彩铃。这个声音不是FreeSWITCH产生的，是上行中继传下来的。

如果不做处理，会出现一个尴尬的情况：AI的欢迎语还没播完，用户的彩铃已经响起来了，两边声音叠在一起。更严重的是，如果你用record采集用户声音，可能会把彩铃也录进去，导致ASR识别出运营商提示音。

解决方法是处理early media。在FreeSWITCH里，应对方式是在应答前设置ignore_early_media或使用force_early_media。我的做法是：

<action application="set" data="ignore_early_media=true"/> <action application="answer"/>

这行配置的意思是：在真正answer之前，忽略所有上行传来的早期媒体。这样AI的欢迎语就不会和运营商彩铃打架。

5.4 大模型响应慢导致体验撕裂

这是体验优化里最难啃的骨头。用户说完一句话，要经过“录音停止→上传ASR→识别→LLM生成→TTS合成→播放”这条链路，整个延迟叠加起来，慢的时候能到5到8秒。

我在这个环节做了三个优化：

第一个是ASR换成流式识别。不要在用户说完话才开始识别，而是在用户说话的过程中持续识别，用户一停，文本几乎同时出结果。阿里云的实时语音识别WebSocket接口支持这个能力，可以把延迟从1秒压到200毫秒左右。

第二个是TTS结果缓存。客服场景里很多问题是重复的（查余额、查营业时间、问地址），相同问题生成的回答文本基本一致，我把每次TTS生成的音频文件用MD5做key缓存起来，第二次命中的时候直接播放，省掉合成的时间。实测命中率能有20%到30%，对整体延迟改善明显。

第三个是LLM分句播报。通义千问结果还没完全生成完时，先把第一句话丢给TTS合成播报，让用户感觉到“AI开始说话了”，后面的内容再补齐。这个技术上有一定复杂度，因为模型流式输出断点不好控制，我是在Prompt层面要求模型用句号分开每个句子，再配合流式输出解析实现的。

效果对比：

6. 并发评估与后续扩展思路

6.1 并发资源估算

很多朋友关心这套系统能支撑多少路并发。我基于实测给出一个粗略的参考估算。

每路通话的资源消耗主要有三块：

• FreeSWITCH侧：一路G.711通话大约占用64kbps带宽，单核CPU可以轻松处理几十路并发。实际上FreeSWITCH的瓶颈一般不在CPU，而在文件I/O和内存带宽。
• ASR/TTS侧：云端服务按路计费，时延和并发都由云端兜底，危险在于API限流配额。
• LLM侧：通义千问的并发配额决定了最大对话速度。假设每次LLM请求耗时500毫秒，一路通话平均每10秒产生一次请求，那么一路通话实际消耗的LLM QPS是0.1。通义千问的plus模型默认并发配额如果是10，理论上可以支撑100路同时通话。但这个数字很理想，实际上要考虑LLM响应波动、ASR排队等因素，我建议保守按理论值的30%做容量规划。

这里顺便解释一下“并发”和“请求”这两个词在呼叫中心场景的区别：一路“并发通话”指的是一个正在进行的电话会话，而“请求”是通话过程中每次调用大模型的单个HTTP请求。一路通话在会话过程中会产生很多次请求，所以计算LLM侧压力时，要按照通话内请求频率来换算，不能把并发通话数直接当QPS用。

6.2 知识库RAG接入

通义千问虽然通识能力强，但企业客服一定需要私有知识库。我们的方案是把通义千问和向量检索结合，做RAG（检索增强生成）。

思路是在LLM请求之前，先用用户问题的文本去向量数据库做相似度检索，把命中结果作为上下文片段喂给模型。这里我用的是bge-m3这个开源向量模型做文本embedding，它在中英文上效果都不错，比直接用千问自带的embedding更灵活。

from FlagEmbedding import BGEM3FlagModel model = BGEM3FlagModel('BAAI/bge-m3', use_fp16=True) def search_knowledge_base(query, top_k=3): query_vec = model.encode(query)['dense_vecs'] # 用向量数据库或最简单的方式做余弦相似度检索 results = vector_db.search(query_vec, top_k) return results

检索到的知识片段拼到system prompt里，模型就会优先基于这些知识回答，而不是自由发挥。这样企业可以把产品手册、FAQ、工单知识库全部接进来，真正做出定制化的AI客服。

6.3 本地大模型部署与私有化

有些企业数据敏感，不想把对话内容发到公有云。这时候可以考虑在本地部署大模型，把通义千问的API调用替换成本地模型服务。

本地部署的模型选型要看显卡。我实测过16G显存的机器可以跑Qwen2.5-7B-Instruct，配合4bit量化，生成速度大约每秒20到30个token，客服对话基本够用。如果显存只有8G，就只能跑Qwen2.5-3B或者更小的模型，效果会差一些。

部署工具我用的是Ollama，一条命令就能起服务：

ollama run qwen2.5:7b-instruct-q4_K_M

起来之后，它提供一个和OpenAI兼容的API：

client = OpenAI( api_key="ollama", base_url="http://localhost:11434/v1" )

这样我前面的代码完全不用改，只需要把base_url换成Ollama的地址就能切到本地模型。这个切换能力现在看太重要了——先在云上把业务跑通，再根据合规要求决定要不要私有化，整个架构天然支持。

对延迟和并发要求更高的场景，还可以用vLLM部署模型，吞吐比Ollama高不少，只是显存要求也更高，至少要24G才能跑得舒服。我的经验是：并发低于5路用Ollama足够，追求吞吐就上vLLM。

最后再分享一个个人经验：做这种跨领域集成项目，最忌讳一上来就追求完美方案。先把最简单的链路跑通——哪怕先用录音文件离线识别，哪怕先让模型固定回答一句“您好”，只要电话能打通、声音能传过来，整个系统的骨架就立住了。之后每一步优化都有数据支撑，知道瓶颈到底在哪个环节。我是从“拨打1000分机听到一句固定欢迎语”开始，一步步迭代到能进行多轮自然对话的完整呼叫中心的。这个思路，比任何技术选型都重要。