企业官网建设流程全解析

Riffn 的名字后面跟着一句话：An instant voice link with your AI agents and local models。从这句话能看出，它并不是一个新的语音识别库，也不是又一个 TTS 引擎，而是一条把 AI agent 和本地模型之间的语音交互串起来的即时通道。真正有价值的问题是：为什么要单独做一个“语音链接”层，而不是把录音、识别、模型推理、语音合成直接拼在一起？原因在于，语音交互链路比普通的接口调用复杂得多：音频采集有设备差异，识别模型有资源开销，agent 推理有延迟，语音合成又有自己的播放节奏。任何一个环节没有对齐，用户听到的结果就是“机器人反应很慢”“识别得乱七八糟”“声音断断续续”。这篇文章会从这类工具的通用架构出发，解释四段链路的关系，再用一个最小 Python 示例把整条本地语音链路跑通，最后给出参数、验证、排错和上线前检查清单。读完以后，你不仅能理解 Riffn 这类项目解决的是什么问题，也能在自己的 agent 场景里独立搭出一条可观测、可优化、可上线的语音通道。

1. 先理解 instant voice link 到底要打通哪几个环节

语音链路看起来只是“说话 -> 回答”，但拆开以后，每一步都有自己的延迟、失败模式和参数选择。先理解链路本身，再讨论工具，才不会在后续集成时被某个环节卡住。

1.1 为什么 AI agent 需要一条即时语音链路

AI agent 通常以聊天框形式出现，用户输入文本，agent 返回文本。文本交互的优点是稳定、可复制、容易调试，但缺点是打断了操作流。

举例来说，用户在做饭时想调整厨房计时器，或者工程师在检修设备时需要一边看仪器一边询问参数，这时候掏出手机打字并不现实。语音交互可以边说话边操作，agent 边听边执行。Riffn 的标题特意强调 instant，说明这个领域的关键指标不是识别准确率，而是“从用户开始说话到 agent 开始回应”的总时长。总时长短，用户才愿意把语音当作高频入口；总时长超过一两秒，用户就会觉得它慢。

本地模型在这条链路里承担两个角色：

• 识别本地语音并把声音变成文本。
• 根据文本生成回复，再交给语音合成。

选择本地模型而不是云端接口，通常是为了三件事：数据不出设备、离线可用、模型行为可替换。数据不出设备意味着隐私敏感场景更可控；离线可用意味着没有网络时语音入口仍然工作；可替换意味着可以按场景使用不同大小的模型。Riffn 这类项目强调 local models，本质上是希望这条链路不依赖特定云厂商，而成为 agent 与本地推理引擎之间的一层通用连接。

1.2 一条语音链路通常拆成四段：采集、识别、推理、合成

为了把“即时语音链接”讲清楚，必须把整条链路拆成四个独立节点：

这四个节点是串行关系。最终延迟等于采集等待时间加识别时间加推理时间加合成播放时间。单独优化任何一段都不一定能带来体验提升，因为瓶颈往往在耗时最长的节点上。一条设计良好的语音链路，应该让四个节点都能被独立测量、独立替换、独立降级。

1.3 Riffn 的技术定位：把链路做短，而不是只做一个模型

从标题里的 instant voice link 这个词组可以看出，Riffn 更关注的是“链接”而不是“模型”。它解决的是 agent 和本地模型之间的语音通道问题，包括如何把麦克风音频送进识别模型、如何把识别文本送进 agent、如何把 agent 回复变成语音流播出来。

这类项目常见的设计方式是：定义一条标准音频管道，让上层应用只需关心文本和动作，不关心声卡、采样率、编解码器。你可以把这条管道理解成数据库连接池：没有连接池时也能连数据库，但每个调用都要处理连接、超时和异常；有了连接层，业务就只需要执行 SQL。语音链接层也一样，把采集、识别、合成这些重复工作收敛起来，让开发者把精力放在 agent 本身的逻辑上。

把链路做短还有一个含义：减少中间转录次数。中间转录是指把音频转成文本、文本转成音频的多次往返。理想情况下，用户一句话应该只被识别一次，agent 回复应该只被合成一次，中间尽量少做格式转换和缓冲拷贝。理解的难点在于，这里的“短”不是代码行数短，而是数据路径短、事件经过的中间层少。

2. 搭建前的环境准备与选型：先确认你要跑哪一种语音链路

很多人拿到这类项目后第一件事是直接跑代码，结果在录音设备、模型下载、端口占用上浪费大量时间。提前确认链路的形态和依赖，可以省下更多时间。

2.1 先选模型，再选链路

本地语音链路可以分成三种形态。

全本地链路最接近 Riffn 标题描述的场景，但资源占用也最高。如果机器只有 8GB 内存且没有独立显卡，建议先用 small 级别的识别模型和 7B 以下的本地 LLM，或者先用规则函数代替 LLM 推理，把链路逻辑验证通，再逐步替换成更大模型。

不要一上来就追求最大模型。语音链路的瓶颈往往先出现在设备和依赖配置上，先跑通再调优是更稳的顺序。

2.2 音频设备与 Python 环境检查

推荐使用 Python 3.9 到 3.11 作为参考环境。部分音频采集库和深度学习依赖对最新 Python 的支持会有滞后，落地前先确认依赖是否兼容。

首先确认麦克风设备可用。在 Linux 系统上，PortAudio 通常需要单独安装：

# Debian / Ubuntu sudo apt-get update sudo apt-get install -y libportaudio2 portaudio19-dev # macOS 可使用 Homebrew # brew install portaudio

然后创建虚拟环境并安装依赖：

python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install sounddevice numpy wave pyaudio pyttsx3 faster-whisper requests

注意：wave是标准库，不需要单独安装。这里列出它只是为了提醒自己最后要用 WAV 文件作为中间格式。faster-whisper 首次运行时会下载模型文件，如果部署环境无法访问外网，需要提前准备离线模型包，并配置 Hugging Face 的本地缓存目录。这是正常的离线部署准备工作，不属于任何特殊网络操作。

安装完成后，用下面的命令确认声卡可以被 Python 访问：

python -c "import sounddevice; print(sounddevice.query_devices())"

如果输出为空或者报错，说明 PortAudio 没有正确找到音频设备，需要回到上一步检查系统依赖。

2.3 目录结构和最小工程划分

建议按功能分文件，即使是最小示例，也不要全部堆在一个文件里：

voice-link-demo/ ├── requirements.txt ├── audio_utils.py # 录音、保存 WAV、音频能量判断 ├── stt.py # 语音识别封装 ├── agent.py # agent 回复逻辑 ├── tts.py # 语音合成封装 └── main.py # 主循环串起整条链路

分文件的目的不是形式主义。语音链路的每段延迟都不同，分开后可以单独打印耗时、单独替换实现、单独测试。后面的排查和验证都是建立在这个结构上的。

3. 用最小示例跑通一条可复用的语音交互链路

下面这一段不是 Riffn 官方的接入方式，而是为了理解“agent 与本地模型之间的语音链路”而写的最小参考实现。它演示的是整条链路所必需的环节：采集、识别、推理、合成。实际使用时，应根据自己的模型版本、本地服务接口和操作系统调整代码。

3.1 第一步：采集麦克风音频并保存成 WAV 文件

录音模块要做三件事：从默认麦克风录制一段声音、判断这段声音是否包含有效语音、把音频保存为模型可以读取的 WAV 文件。

# audio_utils.py import sounddevice as sd import numpy as np import wave SAMPLE_RATE = 16000 CHANNELS = 1 SAMPLE_WIDTH = 2 # int16 def record_audio(seconds=5.0): frames = sd.rec( int(seconds * SAMPLE_RATE), samplerate=SAMPLE_RATE, channels=CHANNELS, dtype="int16", ) sd.wait() return frames.ravel() def save_wav(audio, path="input.wav"): with wave.open(path, "wb") as wf: wf.setnchannels(CHANNELS) wf.setsampwidth(SAMPLE_WIDTH) wf.setframerate(SAMPLE_RATE) wf.writeframes(audio.tobytes()) def audio_energy(audio): return float(np.sqrt(np.mean(audio.astype(np.float32) ** 2)))

这里的采样率 16000 Hz 是语音识别模型的常见输入要求。16 kHz 对语音来说足够表达人声频率范围，又能减少数据传输量。如果录制 44.1 kHz 音频，需要额外做重采样，模型不一定支持，所以在采集端直接统一成 16 kHz 更省事。

3.2 第二步：把音频交给本地 STT 模型转成文本

语音识别封装只需要一个函数：输入 WAV 路径，输出文本。

# stt.py from faster_whisper import WhisperModel _model = None def get_stt_model(model_size="small"): global _model if _model is None: _model = WhisperModel(model_size, device="cpu", compute_type="int8") return _model def transcribe(wav_path, language="zh"): model = get_stt_model() segments, _ = model.transcribe(wav_path, language=language) return "".join(segment.text for segment in segments).strip()

模型大小可以从 tiny、base、small、medium 中选。tiny 速度快但识别效果一般，small 在速度和准确率之间比较均衡，medium 资源占用明显增加。内存较小或没有 GPU 的机器建议先用 int8 量化版本，能显著降低资源占用，识别效果下降在可接受范围内。

如果原始环境没有网络下载模型，可以把模型目录提前拷贝到本地，再通过环境变量指定缓存路径。不同版本的 faster-whisper 对环境变量的处理方式略有差异，落地前以对应版本文档为准。

3.3 第三步：把文本交给 agent，获得回复文本

这里的 agent 可以是本地跑的 LLM，也可以是一个规则函数。最小示例先使用规则函数，保证链路可以在低资源环境跑通。

# agent.py import datetime def agent_reply(user_text): if "时间" in user_text: return f"现在是 {datetime.datetime.now():%H:%M}" if "谢谢" in user_text: return "不用客气，还有什么需要帮忙的吗？" return f"你说的是：{user_text}"

如果要替换成本地 LLM，常见做法是调用本机部署的 HTTP 接口：

# agent.py 的可选扩展 import requests def agent_reply_llm(user_text): resp = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": user_text}], "stream": False, }, timeout=60, ) resp.raise_for_status() return resp.json()["message"]["content"]

这里的端点路径和请求参数会随本地推理服务版本变化，示例只说明思路。生产环境还需要处理超时、重试、模型列表配置和上下文长度控制。

3.4 第四步：用本地 TTS 把回复读出来

语音合成最简单的实现是使用系统自带语音引擎。pyttsx3 可以在 Windows、macOS 和 Linux 上调用本地语音，不需要额外下载模型。

# tts.py import pyttsx3 _engine = None def speak(text): global _engine if _engine is None: _engine = pyttsx3.init() _engine.say(text) _engine.runAndWait()

pyttsx3 的好处是零模型依赖，缺点是音色偏机械，适合验证链路，不适合直接做产品体验。想要更自然的本地语音，可以换成 Piper。Piper 是本地神经网络 TTS，支持多种语言和音色，但需要下载对应语音模型文件。选择 TTS 时要记住：语音合成本身也有延迟，如果你发现 agent 回复很快但用户等待时间长，问题往往出在 TTS 生成和播放环节。

3.5 串联主循环

把四段逻辑串起来，就是一个完整的语音交互闭环：

# main.py import audio_utils import stt import agent import tts VAD_THRESHOLD = 300.0 RECORD_SECONDS = 5.0 def main(): print("请说话（5 秒录音窗口）...") audio = audio_utils.record_audio(RECORD_SECONDS) if audio_utils.audio_energy(audio) < VAD_THRESHOLD: print("检测到静音，跳过本次输入") return audio_utils.save_wav(audio, "input.wav") user_text = stt.transcribe("input.wav") print("识别结果:", user_text) if not user_text: print("识别为空，跳过") return reply = agent.agent_reply(user_text) print("Agent 回复:", reply) tts.speak(reply) if __name__ == "__main__": while True: main()

这个循环每轮录音 5 秒，然后依次经过 VAD 判断、识别、推理、合成。它是最小闭环，但已经具备了一条语音链路的所有核心节点。把它跑通后，再替换任何一段都不会影响其他段的理解。

4. 流式语音链路的参数与细节，真正决定体验的是这些配置

最小示例能跑通，但距离“instant voice link”还有明显差距。差距主要来自参数设计。语音链路的体验不只是模型能力决定的，还取决于音频参数、静音判断、超时机制和资源管理。

4.1 音频参数设置：采样率、位深、声道和块大小

识别链路统一使用 16 kHz 单声道 int16，这是大多数语音模型的标准输入格式。TTS 输出采样率可能与识别不同，播放时由音频库自动转换。如果使用流式传输，最好在协议层明确标注采样率，避免对端解码出错。

块大小直接影响流式链路的实时性。每 20ms 到 100ms 处理一个音频块，可以边录音边送识别模型，而不是等整句话说完才处理。Riffn 这类即时链接工具强调 instant，通常会在采集端尽量早地把音频帧发出去，而不是等大块缓冲。

4.2 VAD：不要把整段静音都交给模型

VAD（语音活动检测）的作用是判断音频里有没有人声。没有 VAD 时，系统会把静音、键盘敲击声、环境噪声全部送入识别模型，既浪费计算资源，又容易产生误识别。

最简单的 VAD 实现是能量阈值法：

if audio_utils.audio_energy(audio) < VAD_THRESHOLD: # 静音，不进入识别 return

能量阈值法的缺点是会把掌声、关门声等非语音事件当作有效输入。更可靠的方案是使用 WebRTC VAD 或 Silero VAD。Silero VAD 是本地模型，能按帧输出人声概率，适合实时流式场景。

VAD 参数需要结合环境调试。办公室里空调噪声大，阈值要调高；安静书房里阈值可以调低。生产环境建议记录 VAD 被触发的次数和识别结果的置信度，方便后续调参。

4.3 超时、断句与打断机制

用户说话不可能是标准 5 秒窗口。真实对话里有停顿、重复、插话，语音链路需要一套时间策略。

打断机制是语音交互里比较关键的一环。agent 正在播报时，用户直接说话，系统应该立刻降低或停止 TTS 播放，并把麦克风重新切换到识别状态。这需要 TTS 播放线程和录音线程并行，并且能互相通知。最小示例里 TTS 使用阻塞式 runAndWait，所以做不了打断；生产实现要把 TTS 放到独立线程，并提供 stop 回调。

4.4 本地模型资源占用与并发

本地模型是资源大户。识别、推理、合成三个阶段如果同时运行，内存和 CPU 会快速消耗。单机场景建议按队列串行处理：同一时刻只允许一个语音请求进入完整链路。

资源估算时可以关注几个关键值：

• faster-whisper small 模型在 CPU int8 下内存占用约 1GB 左右，但不同版本会有差异。
• 本地 LLM 的显存占用主要由模型参数量和上下文长度决定，7B 模型量化后通常需要至少 6GB 可用显存或内存。
• Piper TTS 的模型较小，但也在独立线程中运行，不能完全忽略。

如果用户同时接入多个语音请求，就需要引入任务队列和超时机制。最简单的方案是使用单消费者队列，第一份请求处理完再处理下一份；更复杂的方案是双队列：STT 一个队列，LLM 一个队列，中间用事件解耦。

5. 运行验证：从音频、日志和 Token 三端确认链路正常

“能跑起来”不等于“链路正确”。语音链路最容易出现的情况是每一段单独调用都没问题，串起来后整体表现很奇怪。原因通常是数据格式、时序、状态在不同段之间没有对齐。因此验证要从分段开始。

5.1 验证原则：先分段，再整链

不要一开始就对着麦克风说话。建议按照采集 -> 识别 -> agent -> 合成 -> 整链的顺序逐段验证。

验证顺序：

1. 录音：运行录音函数，把 audio.wav 用播放器打开，确认有清晰人声。
2. 识别：把一段已知内容的音频文件喂给 transcribe，确认输出文本和原内容一致。
3. Agent：直接调用 agent_reply，传入测试文本，确认回复符合预期。
4. 合成：直接调用 speak，确认扬声器能出声。
5. 整链：最后再运行主循环。

这样做的原因是：如果整链失败，你至少能确定问题出在哪个分段，而不是从一堆相互干扰的日志里猜测。

5.2 使用录制音频回放代替真实麦克风

在开发环境里反复对着麦克风说话效率很低，而且每次说的内容都不一样，无法复现问题。更稳的做法是准备几个测试 WAV 文件，直接注入到识别阶段。

# 把测试音频保存为 test_greeting.wav # 然后临时修改 main.py：不用麦克风，直接 transcribe("test_greeting.wav")

使用固定音频样本可以验证识别模型在相同输入下的稳定性。特别是在调整采样率或音频增益后，固定样本能快速看出结果是变好还是变差。

5.3 使用文本回放代替 TTS

调试 agent 逻辑时，可以关闭 TTS 播放，只打印回复文本。这样不会因为扬声器声音干扰麦克风，也不会每次调试都听到语音播报。常见的做法是通过环境变量控制：

if os.getenv("VOICE_DISABLED"): print("[TTS 已跳过]") else: tts.speak(reply)

文本回放能让调试速度和可读性明显提升。语音链路里“无声”和“无声但报错”是两种问题，前者可能是声卡配置，后者可能需要看异常堆栈。控制了变量，才更容易定位。

5.4 从日志中观察延迟分布和 Token 数

在四个阶段分别打印耗时，能得到一张延迟分布表：

[rec] 录音+保存耗时: 5.02s [stt] 识别耗时: 1.23s [agent] 推理耗时: 0.85s [tts] 合成耗时: 0.76s 整链耗时: 7.86s

观察这张表，可以判断瓶颈在哪一段。识别耗时高，就考虑换更小的模型或使用 GPU；推理耗时高，就检查 LLM 上下文长度和量化等级；合成耗时高，就考虑更轻量的 TTS 或流式合成。

LLM 服务通常会返回 token 使用情况。把 prompt tokens、completion tokens 和耗时一起记入日志，可以判断回复慢是因为输入太长、输出太长，还是模型本身吞吐不足。

6. 常见问题排查：为什么语音链路总是一端通、另一端断

语音链路涉及声卡、模型、网络进程和播放设备，问题现象五花八门。下面列出最常遇到的四类问题，以及从现象倒推原因的排查路径。

6.1 麦克风采集不到声音

现象：程序运行，但 audio_energy 一直很低，或者保存的 WAV 文件播放时没有声音。

可能原因：

• 系统默认输入设备不是目标麦克风。
• 采集进程没有麦克风权限。
• Linux 下 PortAudio 设备索引不对。
• 输入音量被系统设为静音或过低。

检查方式：

python -c "import sounddevice; print(sounddevice.query_devices())"

然后确认默认输入设备是哪一个，必要时显式指定设备索引：

sd.rec(..., device=默认输入设备索引)

处理建议：先在系统设置中测试麦克风是否能正常录音，然后确认 Python 进程是否有权限访问设备。不要反复改代码，优先排除设备和系统权限问题。

6.2 STT 转写为空或乱码

现象：录音文件播放正常，但识别结果为空，或者文本和实际内容明显不符。

可能原因：

• 采样率不是模型期望的 16 kHz。
• 音频文件声道数或位深不符合要求。
• 模型文件损坏或版本不兼容。
• 语言参数设置错误，例如中文内容却传了 language="en"。

检查方式：用 Python 打开 WAV 文件，打印通道数、采样宽度和帧率；再用播放器确认音频内容。对比录音文件与测试文件的结构。

处理建议：统一音频参数。把录音数据 print 出来，确认数组形状是(samples,)而不是(samples, 1)。faster-whisper 对输入结构敏感，多试几次就能发现波形是否异常。若识别结果全乱码，可以先换一段公开的测试音频验证模型本身是否正常。

6.3 agent 回复慢导致用户重复说话

现象：用户说完后超过 3 秒没有反馈，于是又补了一句，结果 agent 把两句话都处理了。

可能原因：

• agent 推理时间过长，超过用户等待阈值。
• 请求重试机制导致同一输入被处理多次。
• 录音窗口设计不合理，结束条件依赖固定 seconds 而不是静音检测。
• 状态没有加锁，同一时刻多个线程进入主循环。

检查方式：观察日志中 agent 阶段耗时。如果耗时集中在 agent 推理，就缩短上下文长度、换小模型，或者增加用户侧“正在思考”的提示音，让用户知道系统在工作。

处理建议：第一层优化是降低 agent 单次推理耗时；第二层是引入静音结束检测，不要固定录 5 秒；第三层是在入口加互斥锁，避免并发进入主循环。这里最关键的一点是“让用户觉得系统在回应”，而不只是追求真实推理速度变快。

6.4 TTS 无声、延迟或爆音

现象：agent 已经生成回复文本，但扬声器没有声音，或者播放时出现明显爆破音和延迟。

可能原因：

• 默认播放设备错误。
• pyttsx3 依赖的系统语音引擎未安装。
• 音频数据经过多次格式转换后出现溢出。
• TTS 在阻塞线程里运行，拖慢了整个主循环。

检查方式：先单独运行tts.speak("测试")，确认基础语音能播放。如果单独播放也有问题，检查系统语音引擎和扬声器设备。如果单独播放正常，但主循环里有爆音，检查音频数据是否在 int16 和 float32 之间反复转换导致数值溢出。

处理建议：把 TTS 放到独立线程，不要在识别推理主线程里同步播放。需要播放时，先把 WAV 数据写入临时文件，再用系统播放器播放；需要实时播放时，使用支持流式写的音频库。爆音问题通常和样本位深、增益倍数有关，建议在音频转换时统一使用 float32 计算，最后再转回 int16。

7. 生产级语音链路的最佳实践与下一步扩展

最小示例跑通后，距离生产环境还有一段路程。最明显的差距是：最小示例是单机、单会话、无状态、无监控的，而真实使用场景会有多个用户、多次会话、设备变化和异常恢复。

7.1 学习环境与生产环境对照

生产环境最重要的一件事是让每个语音请求都可以被追踪。至少要记录请求 ID、用户 ID、各个阶段耗时、识别文本、agent 回复、模型 token 用量和最终状态。没有这些信息，用户反馈“语音偶尔没反应”时，你根本无从定位。

7.2 用 WebSocket 或 WebRTC 承载实时音频流

最小示例使用的是“录完整段再处理”，离 instant 还有明显距离。要降低首字延迟，需要把音频采集和识别改成流式。

常见的承载协议：

• WebSocket：适合服务端到服务端、或浏览器到服务端的准实时音频帧传输。
• WebRTC：适合需要低延迟且需要双向音频流的场景，自带回声消除和网络自适应。
• 自定义 UDP 音频流：适合局域网设备，但需要自己处理丢包、乱序和时钟同步。

音频帧协议至少要包含采样率、帧序号、时间戳、编码格式和载荷数据。不要只传裸音频字节，否则对端无法判断这一段音频是什么时候采集的、应该用什么参数解码。

把链路改成流式后，VAD 的判断时机也要提前。不要等整句话录完，而是持续检测人声开始和结束：人声开始后立即把切片送识别，静音结束后组装完整结果。这能显著缩短用户说完到 agent 开始处理之间的等待时间。

7.3 上线前可复用清单

下面这份清单适用于任何需要接入本地模型语音链路的项目，不管是桌面助手、会议纪要工具还是语音机器人。

1. 音频参数统一：确认采集、识别、TTS 输出三处采样率和声道是否对齐。
2. 默认设备确认：启动时打印默认输入输出设备，异常时给出可读提示。
3. 依赖版本锁定：requirements.txt 或 poetry.lock 记录精确版本，避免更新后行为变化。
4. 模型文件离线：确认模型文件路径、版本和缓存目录，内网部署时不依赖外网下载。
5. VAD 已接入：静音不会进入识别阶段，用户停顿有明确结束判断。
6. 阶段耗时日志：录音、STT、agent、TTS 四段分别有耗时记录。
7. 超时与重试：LLM 调用有超时时间，失败时降级为文本提示或规则回复。
8. 并发互斥：单机场景防止多个语音请求同时占用资源。
9. TTS 可关闭：调试和生产具备文本回退能力，避免语音故障阻塞整个 agent。
10. 数据安全：语音文件不持久化保存，或保存前做脱敏和权限控制。

7.4 从本地单机走向多用户接入的关键改造点

单机语音链路变成服务后，需要考虑用户隔离、队列调度和资源弹性。每个用户会话要有独立的上下文，不能把 A 用户的历史记录混入 B 用户的对话。语音识别模型可以共享，但每个会话的 VAD 状态和断句状态要独立。

多用户场景下，本地模型资源会成为瓶颈。常见做法是使用推理服务统一管理模型并发，前端语音请求只负责推送音频和接收回复事件，不直接加载模型。这样语音链路和模型推理解耦，模型升级时不需要改动语音入口。

对于刚开始接触这一类项目的开发者，最有效的练习顺序是：先把最小闭环跑通，然后加入静音检测和文本回退，再换成本地 LLM，最后尝试流式音频接入。每一步都保留一份能运行的代码，避免在整链改造时无从排查。

语音链路的本质不是模型多强大，而是用户能以多自然的节奏和 agent 交互。Riffn 这类工具的价值就在于把“说话”这件事变成 agent 的标准输入之一，让本地模型不再是只能接收文本的控制台，而变成随时可以对话的通道。理解了四段链路和它们之间的参数关系，再去读任何相关项目的文档或源码，都会更容易看懂它到底在编排哪些环节。