企业官网建设流程全解析

最近上手了一套把 ASR / LLM / TTS 直接内建进软电话的工具系统——后端跑 FreeSWITCH，AI 侧走本地 Ollama + qwen3:14b，全程不出内网。体验下来，真正值得写的不是界面长什么样，而是这套组合在技术上的几个关键取舍：信令怎么走、质量怎么量化、AI 的延迟预算怎么压、私有化部署的并发瓶颈在哪、以及最容易翻车的那道坎。

一、信令与媒体分离：VoIP 一切复杂性的源头

VoIP 的基本盘是两条互不干扰的通道：SIP 负责"建立通话"，RTP 负责"搬运声音"。这个分离设计带来了灵活性，也带来了绝大多数线上故障。

信令侧默认5060/UDP，一个 UDP 包刚好装下一条 SIP 消息，开销最小、握手最快，这是它被标为"推荐"的原因。但它有一个容易被忽略的暗坑：以太 MTU 1500，去掉 IP/UDP 头，SIP 消息体超过约 1300 字节就会分片。一旦分片，任一片丢失整条信令作废，重传反而比 TCP 慢。

而触发超限的场景恰恰是生产环境常态：多 codec 候选、多端注册、TLS 证书链、大量自定义头。所以真上生产，信令应当切到TCP 或 TLS（5061），媒体走SRTP。代价是多一个 RTT 的连接开销，但换来的是确定性和加密。

软交换选型上，FreeSWITCH 这类B2BUA​ 架构的价值在于：它终结两侧会话，可以任意改写 SDP、转码、录音、混音。对要做 AI 的系统来说，这是刚需——你需要从中间把媒体流"抽"出来。

具体抽法有三条路：

• ESL（Event Socket Library）：外置程序通过 socket 订阅事件、下发命令。适合做呼叫控制与话术推送，不碰媒体。
• media bug / audio fork：在媒体通道上挂一个钩子，把双向 RTP 复制一份给 ASR。这是实时字幕和 AI 分析的标准做法。
• MRCP / unimrcp：把 ASR、TTS 包装成标准资源，走协议对接，适合已有第三方引擎的场景。

选哪条，决定了后面 AI 的介入深度能做到几层。

二、通话质量不是"感觉"，是一组可观测指标

传统电话挂断即结束，通话质量永远停留在"刚才好像有点卡"这种模糊描述里。可观测化的做法，是每次通话结束都产出一组确定数字：MOS、RTT、抖动、丢包率、编码格式。

这里面有个必须澄清的误区：MOS 4.4 不是"特别好"，它是 G.711 的天花板。

E-Model 里，MOS 由 R 因子换算（R 取值 0–100），无损 G.711 链路的 R 约 93–94，对应 MOS 恰好在 4.4 附近。也就是说，只要你用的是 PCMU/PCMA，再好的网络也刷不到 4.6。看到 4.3–4.4，正确解读是"这条链路没有损伤"，而不是"系统优化得特别出色"。

各指标的实际参考线：

编码选择上，G.711（PCMU/PCMA，64 kbps）赢在兼容性——所有网关、所有运营商都认，但它对丢包零容忍。如果链路可控、Opus​ 是更优解：6–40 kbps 自适应，自带 FEC 与 DTX，在 5% 丢包下的表现能碾压 G.711。代价是需要端点双方都支持，跨运营商落地困难。

运维上最该做的一件事：建立自己的质量基线。内网 12 ms RTT、0 抖动、0 丢包是"局域网实验室数据"，一旦跨公网、跨运营商、走移动网络，这组数字会立刻打回原形。用演示环境的指标对外承诺，是这类项目最常见的翻车起点。

配套的网络侧动作：QoS/DSCP 标记语音流量优先级（EF 46）、抖动缓冲按实测自适应（20–200 ms）、以及针对 NAT 的 ICE/STUN/TURN 部署。

三、AI 接入的生死线：端到端延迟预算

把 LLM 塞进实时通话，最难的不是"能不能答对"，而是"能不能在人类还能容忍的时间内答完"。

一次 AI 应答的端到端延迟要拆成五段：

VAD 判定说话结束 → ASR 转写 → LLM 首 token（TTFT） → TTS 首包音频 → 播放 200~400ms 300~800ms 200~600ms 150~500ms

人类对话的舒适区间是1 秒内应答，超过 1.5 秒就会被感知为"迟钝"，超过 2 秒会产生"它是不是没听见"的焦虑。

几个压延迟的关键手段：

流式，全程流式。​ 界面里"流式输出"开关不是在炫技，它是唯一能让系统可用的选项。流式 ASR 边说边出字，流式 LLM 边生成边送 TTS，流式 TTS 边合成边播放——三段流水线重叠后，感知延迟能压掉一半以上。真正该盯的指标是 TTFT（首 token 时间）和 TTFB（首音频包时间），不是总耗时。

参数即延迟。​ 温度 0.3、Top P 0.8、最大 tokens 512——这三个值本质上是延迟控制手段，不只是质量旋钮。低温压幻觉、Top P 收缩采样空间，而max_tokens=512 直接给最坏延迟设了上限。在实时通话里，一个啰嗦但正确的回答，代价远大于一个略短但准时的回答。

超时是保命机制。​ 120 秒超时看似宽松，重点在于超时之后的行为：必须静默降级，让坐席接管，绝不能让通话卡在等待上。AI 是副驾，副驾睡着时车得继续开。

打断（barge-in）是被低估的一环。​ 用户插话时，系统要能立刻停掉 TTS、清空 ASR 缓冲、重启一轮理解。没有 barge-in 的语音 AI，体验上永远是"机器人"。

四、私有化部署：数据不出内网的代价

AI 侧配置是127.0.0.1:11434+qwen3:14b，即本地 Ollama。这条选择的价值非常明确：客服对话里满是手机号、地址、订单号、投诉内容，全流程不出内网意味着合规评审这道关能过。对金融、医疗、政企，这是入场券而非加分项。

但代价要算清楚，主要在两块：

显存。​ 14B 参数，FP16 约 28 GB，Q4 量化约 8–10 GB。一张 24 GB 的消费级卡跑 Q4 量化版是可行的，但 KV cache 还要额外吃显存——并发一上来，最先爆的是它。

并发，这是真正的瓶颈。​ 实时通话是串行阻塞的：一个坐席在说话，模型就得为这一路服务，不能像离线批处理那样排队攒批。粗略估算，单张高端卡跑 14B 量化模型，流式并发大概在10–20 路量级（取决于 prompt 长度与输出长度）。坐席数一旦超过这个量级，只有三条路：加卡横向扩展、换更小模型（7B 甚至 3B 做意图分类 + 话术检索）、或者上 vLLM 这类带 PagedAttention 和连续批处理的推理服务来提升吞吐。

架构上更务实的做法是分流：不要让 LLM 承担所有事。高频、确定性的问题走检索或规则引擎，只有真正需要理解和生成的才交给大模型。这既是成本优化，也是延迟优化。

五、AI 介入的四个深度，本质是一条灰度路径

从轻到重，AI 进语音链路有四种形态：

1. 记录者——实时字幕。最轻，零风险，把通话从"发生过"变成"留得下"。
2. 副驾——话术建议。人说、AI 提示，决策权在人。适合复杂投诉与商务谈判。
3. 嘴——AI 播报 TTS。把合规提示、标准话术用统一口径念出去，消除坐席差异。
4. 代驾——AI 自动对话。最深，适合查余额、预约、通知这类高重复、低风险场景。

这套分层的意义在于：AI 介入深度应该是可分级配置的，而不是一键接管。企业可以按业务风险逐场景放开——通知类先全自动，咨询类先建议，投诉类只做记录。在"全人工"和"全智能"之间二选一，是这类项目最常见的战略错误。

六、最容易翻车的地方：人设与语料的冲突

有一个真实案例值得单独讲。系统提示词写的是某 AI 助手人设，但用户问"你能干什么"时，AI 自动回复给出的是家政、保洁、维修服务介绍，还主动致歉未提供月嫂服务。

这不是模型笨，是配置错位：RAG 知识库里灌进去的语料，和提示词定义的人设是两套东西。模型忠实于它检索到的语料，于是把另一业务的答案搬了过来。

这里藏着 RAG 落地的核心矛盾：当检索内容与系统提示词冲突时，多数模型会优先服从检索到的具体文本，而不是抽象的指令。你写一百遍"你是 X 助手"，不如知识库里一条错误语料的杀伤力大。

对应的三条工程纪律：

• 顺序不能反：先定人设与边界，再清洗语料，最后才开自动回复。反了必然人格分裂。
• 必须有回归测试集：30–50 条问题，覆盖问候、业务范围、价格、投诉、转人工五类。每次改提示词、换模型、更新语料都重跑。这是唯一能防止"改好 A、改坏 B"的办法。
• 给 AI 明确的不作为边界：最危险的不是答错，而是自信满满地答错。宁可"这个问题我帮您转人工"，也不要编造业务。

顺带一句：那次对话里用户回了"你好搞笑"——这就是 AI 出戏的直接信号。AI 客服的单次错误成本比人工低，但传播成本高得多。

七、从电话到统一通信：数据的资产化

语音、会议、即时消息、企业通讯录共用同一套 SIP 身份（同一个分机号）和同一套 AI 后端——这是典型的 UC 收敛路径。

会议侧"会议号 + PIN"的双因子设计是务实的：会议号可外发，PIN 单独通知，避免扫号入会；录制开关按会决定而非默认全录，在合规上更稳妥。

而真正的价值在最后一层：入口一旦统一，通话转写、消息记录、会议纪要就沉淀为可被 LLM 消化的统一资产。​ 过去质检靠人工抽检 1%，现在每一通电话都能结构化——这才是 VoIP 上 AI 最大的杠杆，比"AI 自动接电话"这件事本身价值高得多。

八、落地清单：分四个阶段走

阶段一：先把电话打通打稳（无 AI）

• FreeSWITCH 软交换上线，分机规划、拨号路由、录音策略定稿；
• SIP over TLS、媒体 SRTP；
• 建立跨网络环境的 MOS/RTT/抖动/丢包基线，这是后续所有优化的参照系。

阶段二：只读接入

• 挂 media bug 把音频 fork 给 ASR，先做实时字幕与通话转写；
• 跑通通话小结自动生成，验证摘要质量；
• 此阶段 AI 不参与对话，风险为零。

阶段三：灰度介入

• 选一个低风险、高频场景（如业务通知、信息查询）开 AI 自动对话；
• 其余场景开话术建议，保持人在回路；
• 建立 TTFT / TTFB / 超时率 / 转人工率四个监控指标。

阶段四：闭环

• 用全量通话文本做质检与挖掘，反哺知识库；
• 按发现的问题迭代提示词与语料，每次迭代跑回归集；
• 并发触顶时按分流策略扩容，而非盲目加卡。

合规前置项（必须在阶段一就定死）：录音与 AI 通话的事前告知、通话文本与摘要的存储位置与保留期限、访问权限分级。

结语

VoIP 的技术底座二十年没怎么变：信令建链、媒体承载、编解码协商。真正的变化发生在最上层——一次通话不再是用完即弃的消耗品，而是可以转写、理解、提炼、检索的数据资产。

打通只是起点。能不能在 1 秒内给出可信的回答，能不能让数据不出内网，能不能在模型答不上来时体面地转人工——这些才是决定项目成败的地方。

VoIP 的下半场，比的不是能不能打通，而是打通之后，你能留下什么。