开源实时语音交互系统CortiLoop：从架构到实现的完整指南

1. 项目概述：一个开源的实时语音处理循环

最近在语音AI和实时交互的圈子里，一个名为CortiLoop的开源项目引起了我的注意。它不是一个单一的模型或工具，而是一个精心设计的、端到端的实时语音处理循环系统。简单来说，它能把麦克风里收到的声音，实时地转换成文字，再让一个大语言模型（LLM）去理解并生成回复，最后通过语音合成（TTS）说出来，整个过程延迟极低，形成一个流畅的“听-想-说”闭环。

这个项目解决的核心痛点非常明确：如何低成本、高可控地构建一个类似电影《Her》里“萨曼莎”那样的、能进行自然连续对话的AI语音助手原型。市面上虽然有不少语音助手，但要么是闭源的黑盒服务，定制化困难；要么延迟高、交互不连贯，说一句话要等好几秒；要么部署成本高昂。CortiLoop 瞄准的就是这个缝隙，它提供了一套完整的、可拆解、可魔改的Python实现，让开发者、研究者甚至是爱好者，都能在自己的机器上跑起来一个“灵魂伴侣”或智能客服的雏形。

它适合谁呢？首先肯定是AI应用开发者和人机交互研究者，你们可以把它作为基础框架，快速验证语音交互的新想法。其次是对语音AI感兴趣的极客和创客，想亲手搭建一个会聊天的桌面助手。最后，对于学生或初学者，这也是一个绝佳的学习项目，你能清晰地看到语音识别（ASR）、大语言模型（LLM）、语音合成（TTS）以及音频流处理是如何被串联成一个实时系统的。

项目的核心价值在于其“Loop”（循环）的设计哲学。它不是一次性的问答，而是一个持续的状态机，需要处理语音端点检测（VAD）、推理延迟、上下文管理、打断机制等一系列在实时场景下才凸显出来的工程挑战。接下来，我们就深入这个循环的内部，看看它到底是怎么转起来的。

2. 系统架构与核心设计哲学

CortiLoop 的架构清晰反映了其应对实时性挑战的思路。整个系统可以看作一个由多个专业模块串联而成的实时音频流水线，核心是维持一个稳定、低延迟的循环。

2.1 核心循环流程拆解

典型的单次循环流程如下：

1. 音频采集与预处理：系统从麦克风捕获原始PCM音频流。这里的第一步往往是降噪和增益控制，但为了追求最低延迟，CortiLoop 可能采用轻量级的前处理，或者将这部分交给后续模块。关键的一步是语音活动检测（VAD）。VAD模块持续监听音频流，像一名警觉的哨兵，只有当检测到有效人声时，才会触发后续流程，避免环境噪音导致无意义的循环空转。

2. 流式语音识别（Streaming ASR）：这是降低延迟的关键。与传统的“说完一整句再识别”不同，流式ASR能够“边听边转”。当VAD检测到语音开始，音频流就被送入ASR模型。模型会实时输出部分识别结果（即“临时转录”），并不断修正。这允许系统在用户还没说完时就开始思考，极大地减少了“等待说完”的时间。

3. 大语言模型（LLM）推理与上下文管理：转录文本被送入LLM生成回复。这里的挑战在于：

   • 低延迟推理：需要选择响应速度快的模型或使用量化、推理优化技术。
   • 上下文窗口管理：对话历史需要被精心维护。CortiLoop 需要决定保存多少轮历史，如何修剪过长的上下文，以及如何将系统指令、用户查询和模型回复格式化成LLM能理解的Prompt。
   • 生成控制：为了配合TTS，可能需要控制LLM的回复长度和句式，避免生成过于冗长或包含特殊标记的文本。

4. 流式语音合成（Streaming TTS）：LLM生成的文本被送入TTS引擎，转换成语音音频流。同样，为了追求实时性，这里也可能采用流式或分块合成的方式，即生成一部分音频就立刻播放一部分，而不是等整句话合成完毕。

5. 音频播放与状态复位：合成的语音通过扬声器播放。同时，系统状态需要复位，VAD重新开始监听，准备下一次用户发言。这里还需要设计打断机制：当系统在说话时，如果用户强行插话，系统应能立即停止播放并开始处理新的输入。

2.2 模块化设计与技术选型考量

CortiLoop 的强大之处在于其模块化设计。每个环节（VAD, ASR, LLM, TTS）都是可插拔的，这带来了巨大的灵活性。

• VAD模块：可以选择轻量高效的本地模型，如silero-vad，它速度快、准确率高，非常适合实时场景。也可以使用云服务提供的VAD，但会引入网络延迟。
• ASR模块：选型围绕“精度”与“速度”的权衡。
  • 本地模型：如faster-whisper（Whisper的优化版）、Paraformer或NemoASR。优势是隐私性好、延迟稳定；缺点是需要一定的计算资源，且模型越大，延迟可能越高。
  • 云API：如Azure、Google的语音转文本服务。优势是识别准确率高，尤其是对于多语种和复杂环境；劣势是会产生网络延迟和费用，且不适合完全离线的场景。
• LLM模块：这是系统的“大脑”，选型至关重要。
  • 本地推理：使用ollama、lmstudio或vLLM等框架部署量化后的开源模型，如Qwen2.5-7B-Instruct、Llama-3.2-3B-Instruct或Gemma-2。这是保证隐私和可控性的最佳方式，但对GPU内存有一定要求。
  • API调用：使用OpenAI、Anthropic或国内大模型的API。开发简单，模型能力强，但成本、延迟和隐私是需要考虑的问题。
• TTS模块：同样面临本地与云的选择。
  • 本地TTS：如Coqui TTS、VITS系列模型或StyleTTS2。可以生成非常自然、富有情感的语音，但好的模型推理速度可能较慢。
  • 云TTS/边缘TTS：如Azure TTS、Google TTS，或利用系统边缘计算的pyttsx3（语音质量一般）。云服务音质好、选择多；边缘TTS延迟极低但声音机械。

设计心得：在搭建自己的CortiLoop时，建议从“云ASR/云TTS + API LLM”的组合开始。这样能快速验证整个流程的可行性，排除音频硬件和基础代码的问题。待流程跑通后，再逐步将模块替换为本地版本以优化延迟和成本。例如，先将TTS换成本地的Coqui TTS，感受延迟变化；再将ASR换为faster-whisper；最后挑战本地LLM部署。

2.3 状态管理与循环控制

这是实现流畅对话的“隐形引擎”。系统需要维护几个核心状态：

• 对话状态：当前是“等待用户说话”、“正在识别”、“LLM思考中”、“正在播放回复”中的哪一种？
• 音频缓冲区：存放正在采集或待处理的音频数据块。
• 对话历史：一个结构化的列表，保存着多轮(role, content)格式的对话。
• 中断标志：当用户打断时，如何优雅地停止当前TTS播放并清空相关缓冲区。

一个健壮的状态机是实现自然交互（如打断）的基础。通常，我们会用一个主循环配合异步线程或事件驱动框架（如asyncio）来实现，确保音频采集、推理、播放这些耗时操作不会阻塞彼此。

3. 核心模块深度解析与实操要点

理解了宏观架构，我们深入到每个模块的“黑盒”内部，看看具体实现时有哪些坑要避开，有哪些技巧能提升体验。

3.1 语音活动检测：不只是静音检测

VAD模块的准确性直接决定了系统的响应性和抗噪能力。一个糟糕的VAD会导致频繁误触发（背景噪音触发ASR）或漏触发（用户说话没反应）。

• 原理浅析：好的VAD模型通常是一个轻量级神经网络，它分析一小段音频（如30ms）的频域特征（梅尔频谱图），判断该帧是否包含人声。它需要克服背景音乐、键盘声、风扇声等干扰。

• 实操要点与参数调优：

  • 触发阈值与释放延迟：这是最重要的两个参数。threshold（如0.5）决定了判断为人声的置信度门槛，越高越不易误触发，但也可能漏掉轻声说话。min_speech_duration_ms（如200ms）和min_silence_duration_ms（如500ms）用于防止抖动。比如，设置检测到200ms以上人声才认为语音开始，持续500ms静音才认为语音结束，能有效过滤短促的咳嗽声。
  • 采样率与模型匹配：确保你的音频采样率（如16kHz）与VAD模型训练时的采样率一致，否则性能会严重下降。
  • 在嘈杂环境中的使用：如果环境固定嘈杂，可以在音频送入VAD前，先经过一个轻量的噪声抑制模块，如noisereduce库，能显著提升VAD表现。

  # 以 silero-vad 为例的伪代码展示参数使用 import torch model, utils = torch.hub.load(repo_or_dir='snakers4/silero-vad', model='silero_vad') get_speech_timestamps, read_audio, save_audio = utils # 读取音频，重采样至16kHz audio = read_audio('audio.wav', sampling_rate=16000) # 获取语音时间戳，调整参数以适应场景 speech_timestamps = get_speech_timestamps( audio, model, threshold=0.5, # 调高可减少误触发 min_speech_duration_ms=250, min_silence_duration_ms=400, window_size_samples=512 # 每次处理的样本数 )

3.2 流式语音识别：追求“零”感知延迟

流式ASR是实时性的灵魂。它的目标是将端到端延迟（用户说完一个字到屏幕上出现这个字）降到最低。

• 工作原理：模型不再等待整个句子，而是处理一个滑动窗口的音频，并输出当前窗口的识别结果。由于缺乏未来上下文，流式识别在句首准确率可能稍低，但会随着音频流入快速修正。许多模型（如Whisper）本身并非为流式设计，需要通过缓存key-value状态、重叠分块等技术来实现流式化。

• 实操要点：

  • 使用优化后的推理引擎：直接使用transformers库加载原始Whisper模型进行流式推理效率很低。faster-whisper使用了CTranslate2后端，支持beam search并进行了大量优化，是本地部署的首选。它内置了vad_filter选项，可以与VAD模块协同工作。
  • 处理中间结果：流式ASR会返回is_final标志和partial文本。你需要妥善处理这些中间结果：partial文本可以实时显示在UI上以提供反馈；只有当is_final=True时，才将完整的句子送入LLM。
  • 内存与性能：流式推理需要持续占用计算资源。选择合适的模型尺寸（如tiny,base,small），在速度和精度间取得平衡。对于桌面应用，base或small通常是甜点。

  # 使用 faster-whisper 进行流式识别的简化思路 # 注意：这不是完整代码，需在异步循环中实现 from faster_whisper import WhisperModel model = WhisperModel("base", device="cuda", compute_type="float16") segments, info = model.transcribe( audio_stream, # 需要是一个可迭代的音频块生成器 beam_size=5, vad_filter=True, # 启用内部VAD过滤 vad_parameters=dict(min_silence_duration_ms=500), word_timestamps=False # 根据需求开启 ) for segment in segments: print(f"[{segment.start:.2f}s -> {segment.end:.2f}s] {segment.text}") if segment.text: # 处理segment.text

3.3 大语言模型：对话的灵魂与性能瓶颈

LLM模块负责生成智能回复，也是延迟和成本的主要贡献者。

• Prompt工程：这是引导LLM行为的关键。一个典型的Prompt结构如下：

  <|system|> 你是一个友好且乐于助人的AI助手。请用简洁自然的语言回答用户的问题。如果用户打招呼，请友好回应并询问对方需要什么帮助。</s> <|user|> {当前用户输入}</s> <|assistant|>

  你需要将完整的对话历史（可能经过摘要或截断）和当前问题一起格式化后送入模型。系统指令决定了AI的“人设”，务必精心设计。
• 本地部署优化：
  • 模型量化：将FP16的模型权重转换为INT8或INT4，能大幅减少内存占用和提升推理速度，对精度损失很小。使用llama.cpp,AutoGPTQ,AWQ等工具进行量化。
  • 推理框架：ollama对新手极其友好，一键拉取运行量化模型。vLLM以其高效的PagedAttention技术闻名，特别适合批量推理和长上下文。TensorRT-LLM则在NVIDIA GPU上能提供极致的性能。
  • 上下文窗口管理：当对话轮数增多，上下文会超出模型限制。需要实现一个“滑动窗口”或“摘要”策略。例如，只保留最近10轮对话，或者用一个更小的模型将早期对话总结成一段文字，再放入上下文。
• API调用注意事项：如果使用API，务必处理网络超时和重试机制。设置合理的timeout，并实现指数退避的重试逻辑。同时，注意API的速率限制和成本，在代码中加入简单的调用计数和成本估算。

3.4 语音合成：赋予AI声音与情感

TTS的目标是生成自然、延迟低、符合场景的语音。

• 本地TTS模型选择：
  • 速度优先：Coqui TTS中的Tacotron2或Glow-TTS结合HiFi-GAN声码器，在中等硬件上可以达到较快的合成速度。
  • 音质优先：VITS系列是端到端模型，音质非常自然，但推理速度相对慢一些。StyleTTS2在音色和韵律控制上表现出色。
  • 超级轻量：如果需要极致的速度，可以考虑Edge-TTS（调用系统语音）或pyttsx3，但音质会显得机械。
• 流式合成与播放：为了实现“边合成边播放”，可以将文本分成短句或短语，分别合成并立即送入音频播放队列。这需要TTS引擎支持增量合成，或者使用一个后台线程持续合成和喂数据给播放器。
• 语音中断：当用户打断时，必须立即停止当前TTS的合成和播放线程，并清空音频缓冲区。这涉及到多线程/进程间的通信，一个通用的做法是设置一个全局的stop_event，当打断发生时，设置这个事件，所有相关线程检查到事件后立即退出。

4. 从零搭建：完整实现流程与核心代码剖析

假设我们基于本地模型来构建一个简化版的CortiLoop，技术栈选择：silero-vad+faster-whisper+ollama(运行Qwen2.5:7b) +Coqui TTS。我们将使用asyncio和sounddevice来处理音频流。

4.1 环境准备与依赖安装

首先创建一个干净的Python环境（推荐3.9+），并安装核心依赖。

# 创建虚拟环境 python -m venv cortiloop_env source cortiloop_env/bin/activate # Linux/Mac # cortiloop_env\Scripts\activate # Windows # 安装核心库 pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu118 # 根据CUDA版本调整 pip install faster-whisper pip install sounddevice # 音频采集播放 pip install numpy pip install scipy # 可能用于音频处理 pip install coqui-tts # TTS # Silero VAD 通常通过 torch.hub 加载，无需单独安装 # Ollama 需要单独安装客户端，并从其官网下载

对于ollama，需要去官网下载并安装对应系统的客户端，然后在终端运行ollama run qwen2.5:7b来拉取和运行模型。

4.2 核心循环的异步实现

我们使用asyncio来管理并发的音频I/O和模型推理任务，避免阻塞。

import asyncio import queue import numpy as np import sounddevice as sd from faster_whisper import WhisperModel import torch import tts # Coqui TTS from ollama import chat # Ollama Python客户端 # 1. 初始化全局组件 class CortiLoopSystem: def __init__(self): self.audio_queue = asyncio.Queue() # 存放采集的音频块 self.vad_model, self.utils = torch.hub.load(repo_or_dir='snakers4/silero-vad', model='silero_vad') self.asr_model = WhisperModel("base", device="cuda", compute_type="float16") self.tts = tts.TTS(model_name="tts_models/en/ljspeech/tacotron2-DDC", progress_bar=False).to('cuda') self.conversation_history = [] # 存储对话历史 self.is_speaking = False # 系统是否正在播放TTS self.stop_event = asyncio.Event() # 用于打断 async def audio_callback(self, indata, frames, time, status): """声音采集回调函数，将音频块放入队列""" if status: print(f"Audio status: {status}") # indata 是 numpy 数组，我们将其拷贝并放入队列 self.audio_queue.put_nowait(indata.copy()) async def vad_monitor(self): """VAD监控协程，从队列取音频，检测语音活动""" speech_buffer = [] is_speech_active = False while True: try: audio_chunk = await asyncio.wait_for(self.audio_queue.get(), timeout=0.1) # 转换为VAD模型需要的格式 (单声道， 16kHz) # 注意：这里需要重采样，假设采集是16kHz则省略 audio_int16 = (audio_chunk[:, 0] * 32767).astype(np.int16) # 取单声道并转换 # 使用VAD模型检测 speech_prob = self.vad_model(torch.from_numpy(audio_int16), 16000).item() if speech_prob > 0.5: # 阈值 if not is_speech_active: print("[VAD] 检测到语音开始") is_speech_active = True speech_buffer.append(audio_int16) else: if is_speech_active and len(speech_buffer) > 0: # 静音持续，认为一句话结束 print("[VAD] 检测到语音结束，开始识别...") full_audio = np.concatenate(speech_buffer) asyncio.create_task(self.process_speech(full_audio)) # 触发ASR任务 speech_buffer = [] is_speech_active = False except asyncio.TimeoutError: continue # 队列为空，继续循环 async def process_speech(self, audio_data): """处理检测到的语音：ASR -> LLM -> TTS""" # 1. ASR segments, info = self.asr_model.transcribe( audio_data, beam_size=5, vad_filter=False # 因为我们自己做了VAD，这里关闭 ) user_text = " ".join([seg.text for seg in segments]).strip() if not user_text: return print(f"[ASR] 识别结果: {user_text}") # 2. 更新对话历史并调用LLM self.conversation_history.append({"role": "user", "content": user_text}) # 保持历史长度，例如只保留最近5轮对话 if len(self.conversation_history) > 10: self.conversation_history = self.conversation_history[-10:] llm_response = await self.call_llm(self.conversation_history) print(f"[LLM] 回复: {llm_response}") # 3. TTS并播放 self.conversation_history.append({"role": "assistant", "content": llm_response}) await self.speak_text(llm_response) async def call_llm(self, history): """调用Ollama本地模型""" # 格式化历史为Ollama API需要的格式 messages = [{"role": "system", "content": "你是一个友好的助手。"}] messages.extend(history) try: response = chat(model='qwen2.5:7b', messages=messages) return response['message']['content'] except Exception as e: print(f"LLM调用失败: {e}") return "抱歉，我暂时无法处理你的请求。" async def speak_text(self, text): """使用TTS合成并播放语音，支持打断""" if self.is_speaking: print("检测到打断，停止当前语音") self.stop_event.set() # 触发停止事件 await asyncio.sleep(0.1) # 等待播放线程停止 self.stop_event.clear() self.is_speaking = True # 这里简化处理，实际应将合成和播放放入独立线程/协程，并检查stop_event try: # Coqui TTS 合成 wav = self.tts.tts(text=text) # 使用 sounddevice 播放 (需将wav转换为numpy数组) # 注意：这是一个阻塞调用，在实际应用中应异步化 sd.play(wav, samplerate=22050) sd.wait() # 等待播放完成 except asyncio.CancelledError: print("TTS播放被取消") finally: self.is_speaking = False async def run(self): """主运行循环""" print("启动CortiLoop...") # 开始音频流采集 stream = sd.InputStream( channels=1, samplerate=16000, callback=self.audio_callback, blocksize=1024 # 每次回调的帧数 ) with stream: # 启动VAD监控任务 vad_task = asyncio.create_task(self.vad_monitor()) await asyncio.Future() # 永久运行，直到被取消 # 运行系统 if __name__ == "__main__": system = CortiLoopSystem() asyncio.run(system.run())

代码解析与注意事项：

1. 异步架构：audio_callback由sounddevice在音频线程中调用，通过asyncio.Queue将数据安全地传递到主事件循环。vad_monitor是一个独立的协程，持续消费队列中的音频并进行VAD判断。
2. 状态管理：is_speaking和stop_event用于协调TTS播放和用户打断。当process_speech触发时，如果系统正在说话，会先尝试停止。
3. 简化与不足：为了清晰，上述代码省略了错误处理、音频重采样、TTS异步播放、更复杂的打断逻辑以及LLM上下文长度精确管理。在实际项目中，这些都需要完善。
4. 性能：ASR和TTS的模型加载与推理是计算密集型任务，在主事件循环中直接调用（如self.tts.tts）会阻塞整个循环，导致音频采集卡顿。最佳实践是将这些耗时操作放入ThreadPoolExecutor或单独的进程池中执行。

4.3 关键参数配置与调优建议

一个可用的系统离不开精细的参数调校。下表列出了一些关键模块的调优参数及其影响：

调优流程建议：

1. 先调VAD：在目标环境中录音，反复调整threshold和静音时长，直到能稳定、准确地捕捉你的语音开始和结束，且不被背景噪音干扰。
2. 再调ASR延迟：测试从开始说话到看到识别结果的延迟。可以尝试不同的model_size和beam_size。如果延迟过高，考虑升级硬件或换用更小的模型。
3. 最后调交互体验：调整LLM的max_tokens和temperature，让回复长度和风格符合预期。调整TTS的speed，使语音听起来自然舒适。

5. 常见问题排查与实战避坑指南

在实际搭建和运行过程中，你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的排查清单和解决方案。

5.1 音频链路问题

• 问题：没有声音输入或输出。

  • 排查：首先确认系统音频设置是否正确。使用sounddevice.query_devices()列出所有设备，确认你使用的设备ID是否正确。在代码中，InputStream和OutputStream的device参数需要指定正确的ID。
  • 注意：在Linux上，可能需要处理PulseAudio/ALSA的权限问题。在Mac上，注意系统可能会要求麦克风权限。

• 问题：音频有严重的回声、啸叫或噪音。

  • 排查：这是声学反馈。确保扬声器和麦克风没有正对，或物理上隔开。可以在软件层面尝试启用回声消除（AEC），但sounddevice不直接提供。一个简单的方案是使用pyaudio并配合webrtcvad（虽然它是VAD，但其预处理包含噪声抑制）。更专业的方案需要集成像Speex或WebRTC的音频处理模块。

• 问题：音频流延迟很高，感觉卡顿。

  • 排查：
    1. 检查blocksize：过大的blocksize会增加处理延迟。尝试减小到512或256。
    2. 检查队列积压：如果audio_queue堆积严重，说明消费速度（VAD/ASR）跟不上生产速度（采集）。需要优化模型推理速度，或者使用更大的blocksize来降低生产频率。
    3. 系统负载：检查CPU/GPU占用。ASR、LLM、TTS可能都在争抢资源。考虑使用线程池，并将不同模型分配到不同的CPU核心上。

5.2 模型推理与性能问题

• 问题：ASR识别速度慢，跟不上实时说话。

  • 方案：
    1. 降模型尺寸：从small降到base甚至tiny。
    2. 启用GPU：确保faster-whisper使用了device=“cuda”。
    3. 量化：使用compute_type=“int8_float16”或“int8”进行推理，速度提升显著。
    4. 优化流式处理：确保使用的是transcribe流式接口，并且及时处理segments，不要等整个音频结束。

• 问题：LLM回复速度太慢，每次要等10秒以上。

  • 方案：
    1. 换更小的模型：从7B换到3B或1.5B的模型。
    2. 量化：使用ollama运行qwen2.5:7b-q4_K_M这类4位量化模型，速度和内存占用都会大幅改善。
    3. 调整参数：减少max_tokens，降低temperature。
    4. 检查上下文长度：过长的对话历史会拖慢推理。实现上下文截断或摘要。
    5. 硬件：确认GPU是否足够强大（如RTX 4060以上），或者考虑使用CPU推理搭配大内存。

• 问题：TTS合成一句话要很久，导致对话不连贯。

  • 方案：
    1. 选择更快模型：Tacotron2通常比VITS快。
    2. GPU加速：确保TTS模型也跑在GPU上。
    3. 流式/分句合成：不要等整段长文本合成完再播放。将LLM回复按句号、问号分割，逐句合成并播放，可以极大提升响应感知速度。
    4. 预加载：如果有一些固定回复（如“嗯”、“我在听”），可以预先合成好并缓存。

5.3 交互逻辑与体验问题

• 问题：无法打断AI的说话。

  • 方案：这是多线程/异步编程的典型问题。你需要一个全局的、线程安全的中断标志（如threading.Event或asyncio.Event）。
    1. 在VAD检测到新语音时，设置这个事件。
    2. TTS播放循环需要频繁检查这个事件，如果被设置，则立即跳出循环，停止播放并清空音频缓冲区。
    3. 播放结束后或被打断后，记得清除事件标志。

• 问题：AI回复总是重复或者偏离主题。

  • 排查：
    1. 检查对话历史：可能是上下文管理出了问题，导致历史信息混乱。打印出每次发送给LLM的完整Prompt，检查格式和历史内容是否正确。
    2. 调整系统指令：在系统指令中明确要求“避免重复之前的回答”、“如果不知道就坦诚告知”。
    3. LLM温度：过高的temperature（如>1.0）可能导致回复随机性过大。尝试调低到0.7。
    4. 模型本身：某些小模型或量化不当的模型可能出现重复问题。尝试换一个模型。

• 问题：在安静环境下，系统偶尔会自己“触发”（误识别）。

  • 方案：
    1. 提高VAD阈值：这是最直接有效的方法。
    2. 增加min_speech_duration_ms：要求更长的持续语音才被确认，可以过滤掉偶然的撞击声。
    3. 添加能量门限：在VAD之前，先计算音频块的能量（RMS），如果能量低于某个绝对阈值，直接丢弃，不送VAD判断。

搭建一个稳定、流畅的CortiLoop是一个不断迭代和调优的过程。从最简单的管道开始，每加入一个模块就充分测试，记录延迟和准确率，逐步优化。这个项目最大的乐趣和收获，正是在于亲手将一个个独立的AI组件，编织成一个能与你自然对话的智能循环。