自托管语音助手架构实战：从语音识别到语音合成的完整实现

看到一个名为S.A.T.U.R.D.A.Y的项目时，第一眼很难把它和语音助手联系起来。名字像“周六”，定位却写得很明确：serf-hosted speech to text AI assistant。项目标题里的 serf-hosted，按社区更常见的说法应该是 self-hosted，也就是自托管。意思是一套完整的语音转文字 AI 助手链路，部署在你自己控制的机器上，而不是依赖某个厂商提供的云端语音助手。

这类项目近两年越来越多，背后逻辑很直接：大语言模型已经能处理很复杂的对话语义，语音识别（Speech-to-Text，STT）和语音合成（Text-to-Speech，TTS）的开源方案也足够成熟，那么把三者串成一个“本地版 JARVIS”，就变成了一个很有吸引力的个人项目。

本文不只看这个项目的表面功能，而是从架构角度拆解一个自托管语音 AI 助手需要哪些组件，并给出一套可以直接运行的最小实现。读完你会掌握：语音采集、语音转文字、大模型对话、语音回复、意图执行这几个核心模块的衔接方式，以及在实际部署中容易踩到的坑。无论你是想复刻一个同类项目，还是想把语音交互能力集成到自己的产品里，这套思路都适用。

1. 背景与核心概念

1.1 什么是 S.A.T.U.R.D.A.Y 这类自托管语音助手

S.A.T.U.R.D.A.Y 本质上是一个“本地优先”的语音助手项目。所谓本地优先，强调的是语音数据不出内网，识别、理解、回复的整个闭环都在自有的硬件上运行。这和我们在手机上用到的语音助手不同：手机助手通常会把录音传到云端，经过云端识别后再返回结果；自托管方案则希望把这个过程留在本地，从而获得几个好处：

• 隐私可控。录音内容不必上传到第三方服务器。
• 离线可用。在没有公网环境时，只要本机有模型，依然能完成语音交互。
• 行为可定制。识别到什么指令、调用什么工具、返回什么语气，全部可以用代码控制。
• 无按量付费。模型部署在自己的机器上，没有 API 调用费用的概念。

不过，自托管不等于“完全离线”。实际项目中，很多人会把本地 STT 和云端 LLM/TTS 混用，因为本地跑大语言模型对硬件要求较高。更准确的分类是：

• STT 层：本地部署为主，比如 faster-whisper、Vosk。
• 语义理解层：可以本地部署（Ollama、llama.cpp），也可以调用云端 OpenAI 兼容接口。
• TTS 层：可以本地部署（pyttsx3、Piper、Coqui TTS），也可以使用在线合成服务。

S.A.T.U.R.D.A.Y 这个名字本身没有太多隐藏含义，更多是项目作者希望给助手一个类似“JARVIS”的人格化命名。周六意味着“可以陪你度过休息日的助手”，也暗示了项目的个人项目属性。

1.2 speech to text 在整条链路中的位置

语音助手的工作流可以抽象成下面这条链路：

麦克风采集 -> 语音转文字(STT) -> 语义理解(LLM/规则) -> 文字转语音(TTS) -> 扬声器播放

其中 speech-to-text 是第一个关键环节，也是最容易出错的环节。它负责把麦克风采集到的 PCM 音频，转换成文本字符串，供后续的语义模块使用。如果你用过 OpenAI Whisper，应该知道它在这方面的效果已经相当好，尤其是中文识别准确率，足以应付日常对话场景。

在自托管场景里，STT 的选择往往决定整个项目的基础体验：

• Whisper 系列：准确率高，但模型体积和推理耗时也高。
• faster-whisper：Whisper 的高效复现，CPU 上也能跑到可接受的实时率，是自托管项目的首选。
• Vosk：轻量级，适合离线关键词和命令词识别，但长句效果不如 Whisper。
• sherpa-onnx：新一代推理框架，适合嵌入式设备和端侧部署。

理解 STT 在链路中的位置很重要。很多人第一次做语音助手时，把精力全放在“让 LLM 回答更聪明”上，结果录音、识别、播放这些基础链路没打通，体验非常差。反过来，先把 STT 到 TTS 的最小闭环跑通，再逐步提升语义能力，这才是工程上更稳的推进路径。

2. 系统架构与关键组件

2.1 整体模块划分

把 S.A.T.U.R.D.A.Y 这类项目拆开看，核心模块并不多。我在实现自己的演示项目时，倾向于把它们分成五个部分：

模块	职责	典型实现
音频采集模块	从麦克风获取音频，支持录音时长的控制	sounddevice、PyAudio、PortAudio
语音识别模块 STT	将音频转成文字	faster-whisper、openai-whisper、Vosk
语义理解模块	对识别结果做出响应，决定助手“说什么”	规则引擎、Ollama、OpenAI 兼容接口
语音合成模块 TTS	将回复文本转成语音	pyttsx3、edge-tts、Piper、Coqui TTS
执行器模块	调用外部工具，比如打开浏览器、查时间、控制智能家居	Python 函数、Home Assistant API、命令行工具

模块之间建议通过函数解耦，不要全部写在一个文件里。原因有两点：第一，语音识别和语义理解通常耗时较高，解耦后可以单独优化或替换；第二，后续想加入 wake word（唤醒词）或流式对话时，只需要在对应模块上做扩展，不会影响已有功能。

2.2 音频采集层的注意点

音频采集是自托管语音助手最容易被忽略、也最容易出问题的一层。很多代码在开发机上跑通了，换到树莓派或另一台笔记本上就没声音，原因往往不在代码，而在音频设备配置。

采集时需要注意几个指标：

• 采样率：Whisper 要求输入音频为 16kHz 单声道。麦克风可能默认是 44.1kHz 或 48kHz，需要做重采样。部分音频库在采集时可以指定 samplerate，实际上由底层驱动重采样。
• 位深与格式：推荐使用 float32 格式的 PCM 数据，这也是 faster-whisper 直接支持的输入格式。
• 声道数：多声道麦克风直接转成单声道，否则会出现识别结果混乱或者音量异常。
• 静音检测：固定时长录音会让交互很生硬。更合理的做法是检测到用户连续 1.5 秒没有说话就停止录音，再交给 STT 模块处理。

2.3 语义理解层：从规则到 LLM

早期语音助手大多用规则匹配，比如“如果文本里包含‘时间’，就返回当前时间”。规则实现简单、延迟低、完全可控，适合固定场景。

但 S.A.T.U.R.D.A.Y 这类项目之所以叫 AI assistant，是因为语义层可以接入大语言模型。LLM 的优势在于：能理解同一句话的多种表达方式，能进行多轮对话，还能通过 Function Calling 或工具调用执行复杂任务。

工程上常见的做法是“规则 + LLM”混合：

• 简单命令走规则，响应快、不依赖模型。
• 复杂对话走 LLM，识别用户意图更准确。
• 对家庭自动化场景，优先规则；对开放式的“陪我聊天”场景，优先 LLM。

在后面的实战 demo 中，我会先给出一个纯规则的 brain 模块，再补充一个可选的 LLM 调用方式。这样即使你没有 GPU，也能把整条链路跑通。

3. 环境准备与版本说明

3.1 运行环境

由于 S.A.T.U.R.D.A.Y 这类项目没有统一的官方安装包，这里以我实现的最小 demo 为例，说明环境准备工作。你需要准备：

• 操作系统：Ubuntu 22.04 / Windows 11 / macOS 均可。本文代码以桌面 Linux 为例，Windows 下需要确保麦克风权限已开启。
• Python：3.10 或 3.11。faster-whisper 对 Python 版本要求不算严格，但 3.10 以上兼容性最好。
• 音频设备：USB 麦克风、笔记本内置麦克风都可以。建议使用耳机，避免扬声器播放 TTS 时被麦克风重新采集，形成回声。
• 硬件建议：纯 CPU 也可以运行，识别速度取决于模型大小。如果使用 GPU，需要安装对应版本的 CUDA 和 cuDNN。

版本需要根据你的实际环境调整，本文示例以常见环境为例，重点演示配置思路，不锁死具体的依赖版本号。

3.2 创建项目结构与虚拟环境

先创建项目目录：

mkdir saturday-demo cd saturday-demo python3 -m venv venv source venv/bin/activate

然后创建requirements.txt：

faster-whisper sounddevice pyttsx3 numpy

安装依赖：

pip install -r requirements.txt

这里有几个值得说明的点：

• faster-whisper 依赖 ctranslate2，安装时会自动处理 CPU 或 GPU 版本。默认安装通常只支持 CPU 推理，若需 GPU 加速，请查阅 faster-whisper 官方文档按环境安装对应版本的 ctranslate2。
• sounddevice 在 Linux 上依赖 PortAudio 库，如果安装后录音报错，需要先安装系统级音频依赖。Ubuntu 下可以执行sudo apt install libportaudio2。
• pyttsx3 在 Linux 上需要 espeak 或 espeak-ng 作为后端。

项目结构如下：

saturday-demo/ ├── requirements.txt ├── config.py ├── stt.py ├── brain.py ├── tts.py └── main.py

这个结构足够简单，也能清晰体现模块化思路。

4. 完整实战案例：一个可运行的本地语音助手

下面进入核心部分：用 Python 实现一个最小可运行的语音助手。这个 demo 可以完成“按回车开始录音 -> 语音转文字 -> 规则或 LLM 回复 -> 语音播放回复”的完整闭环。

4.1 配置文件 config.py

配置集中在一个文件里，便于后续修改模型大小、采样率、设备编号。

# 文件路径：saturday-demo/config.py # 音频参数 SAMPLERATE = 16000 # Whisper 要求的采样率 RECORD_SECONDS = 8 # 默认录音时长 SILENCE_THRESHOLD = 0.02 # 静音音量阈值，低于该值认为是静音 SILENCE_SECONDS = 1.5 # 连续静音多少秒后停止录音 MAX_RECORD_SECONDS = 15 # 最长录音时长 # whisper 模型配置 WHISPER_MODEL = "small" # tiny / base / small / medium / large-v3 WHISPER_DEVICE = "cpu" # 有 GPU 可改为 "cuda" WHISPER_COMPUTE_TYPE = "int8" # 量化类型，CPU 上推荐 int8 # 语言 LANGUAGE = "zh" # 可选：LLM 配置，使用 OpenAI 兼容接口 LLM_BASE_URL = "http://localhost:11434/v1" LLM_MODEL = "qwen2.5:7b" LLM_ENABLED = False

说明一下关键配置：

• SAMPLERATE必须设置为 16000。faster-whisper 内部对输入音频的处理以 16kHz 作为基准，如果传入其他采样率，识别效果会明显下降。
• WHISPER_MODEL选small是 CPU 推理时比较均衡的选择。tiny和base更快，但中文识别会有更多错误；large-v3准确率最高，但 CPU 上实时率很低。
• WHISPER_COMPUTE_TYPE设为int8，可以在 CPU 上大幅降低内存占用和推理时间。如果使用 GPU，可以保持 float16。

4.2 语音识别模块 stt.py

这个模块负责两件事：录音和语音转文字。为了方便演示，我先提供固定时长录音的实现，再给出一个静音检测自动停止录音的进阶版本。

# 文件路径：saturday-demo/stt.py import numpy as np import sounddevice as sd from faster_whisper import WhisperModel import config _model = None def get_model(): """懒加载 Whisper 模型，避免重复初始化。""" global _model if _model is None: _model = WhisperModel( config.WHISPER_MODEL, device=config.WHISPER_DEVICE, compute_type=config.WHISPER_COMPUTE_TYPE, ) return _model def record_audio(samplerate=config.SAMPLERATE, duration=config.RECORD_SECONDS): """录制一段固定时长的音频，返回 float32 的一维数组。""" print("开始录音，请说话...") audio = sd.rec( int(duration * samplerate), samplerate=samplerate, channels=1, dtype="float32", ) sd.wait() print("录音结束") return audio.flatten() def record_until_silence( samplerate=config.SAMPLERATE, max_duration=config.MAX_RECORD_SECONDS, silence_threshold=config.SILENCE_THRESHOLD, silence_seconds=config.SILENCE_SECONDS, ): """智能录音：检测到连续静音后自动停止。""" print("开始录音，请说话...") frames = [] silence_chunks = 0 chunk_seconds = 0.2 chunk_samples = int(samplerate * chunk_seconds) max_chunks = int(max_duration / chunk_seconds) with sd.InputStream(samplerate=samplerate, channels=1, dtype="float32") as stream: for _ in range(max_chunks): block, overflowed = stream.read(chunk_samples) if overflowed: print("警告：音频缓冲区溢出，部分数据可能丢失") frames.append(block.copy()) volume = np.abs(block).mean() if volume < silence_threshold: silence_chunks += 1 else: silence_chunks = 0 if silence_chunks >= int(silence_seconds / chunk_seconds): break print("录音结束") return np.concatenate(frames).flatten() def transcribe(audio): """将音频数组转换为文字。""" model = get_model() segments, info = model.transcribe( audio, language=config.LANGUAGE, beam_size=5, vad_filter=True, ) text = " ".join(segment.text.strip() for segment in segments) return text

这里有几个实现细节值得解释：

• model 使用懒加载：首次调用时创建，后续直接复用。Whisper 模型加载比较耗时，如果每次录音都重新加载，交互体验会很差。
• record_audio使用sd.rec，适合最简单的情况，但录音时长固定。实际使用中，用户可能说 2 秒就结束，也可能说 10 秒，固定时长不好把握。
• record_until_silence是进阶版。它使用sd.InputStream以流的方式持续读入音频块，每 200ms 计算一次音量。当音量低于阈值且持续 1.5 秒时，认为说话结束。流式读取的好处是内存占用稳定，不会一次性申请超大连续缓冲区。
• transcribe中开启了vad_filter=True，可以过滤掉前后端的静音片段，减少无效识别。如果环境中没有安装 onnxruntime，可以把这个参数改为 False，或者按提示安装缺失依赖。

4.3 语义理解模块 brain.py

语义模块决定助手听到一句话后“怎么想”。先给一个规则版本，再把 LLM 接入方式作为补充。

# 文件路径：saturday-demo/brain.py import datetime import webbrowser import urllib.request import json import config def process(text): """规则版本：根据关键词返回回复。""" t = text.strip().lower() if "时间" in t or "几点" in t: now = datetime.datetime.now().strftime("%H:%M") return f"现在是 {now}" if "打开浏览器" in t or "上网" in t: webbrowser.open("https://www.bing.com") return "已经为你打开浏览器" if "你好" in t or "hello" in t: return "你好，我是 Saturday 语音助手" if "退出" in t or "再见" in t: return "好的，再见" return "我暂时还不理解这个指令，你可以试试问时间，或者让我打开浏览器" def chat_with_llm(messages): """使用 OpenAI 兼容接口调用本地或云端大模型。""" payload = json.dumps({ "model": config.LLM_MODEL, "messages": messages, "temperature": 0.7, }).encode("utf-8") req = urllib.request.Request( config.LLM_BASE_URL + "/chat/completions", data=payload, headers={"Content-Type": "application/json"}, ) with urllib.request.urlopen(req, timeout=30) as resp: data = json.loads(resp.read().decode("utf-8")) return data["choices"][0]["message"]["content"]

规则版本的优点是零依赖、零延迟、行为可预测。比如控制智能家居时，你肯定不希望在“打开客厅灯”这句话上等 LLM 推理 3 秒。函数内部对文本做了大小写归一化，再通过关键词匹配决定执行动作。

chat_with_llm是比较灵活的 LLM 接入方式。它没有使用 openai 官方 SDK，而是直接用 urllib 请求 OpenAI 兼容接口。这样无论后端是 Ollama、vLLM、LM Studio 还是云端 API，只要路径符合/chat/completions协议，这段代码都能工作。实际使用时，需要注意模型名LLM_MODEL要和你部署的服务保持一致。

如果你想在process中优先启用 LLM，可以这样调整：

def process_with_llm(text): if config.LLM_ENABLED: messages = [ {"role": "system", "content": "你是一个简洁友好的中文语音助手，回答控制在两句话以内。"}, {"role": "user", "content": text}, ] try: return chat_with_llm(messages) except Exception as e: return f"调用大模型失败：{e}" return process(text)

4.4 语音合成模块 tts.py

TTS 模块的目标是把助手的回复文字读出来。这里我用 pyttsx3 作为基础演示方案，因为它是纯离线方案，不需要申请任何云端密钥。

# 文件路径：saturday-demo/tts.py import pyttsx3 _engine = None def get_engine(): global _engine if _engine is None: _engine = pyttsx3.init() _engine.setProperty("rate", 180) return _engine def speak(text): engine = get_engine() engine.say(text) engine.runAndWait() if __name__ == "__main__": speak("你好，我是 Saturday 语音助手")

pyttsx3 在 Windows 上使用 SAPI5，在 macOS 上使用 NSSpeechSynthesizer，在 Linux 上需要 espeak-ng。如果你想获得更自然的音色，可以改用 edge-tts，它提供微软神经语音，但属于在线服务，需要在有网络的环境下运行：

# 文件路径：saturday-demo/tts_edge.py（可选） import asyncio import edge_tts VOICE = "zh-CN-XiaoxiaoNeural" async def speak_to_file(text, output_path="output.mp3"): communicate = edge_tts.Communicate(text, VOICE) await communicate.save(output_path) def speak(text): asyncio.run(speak_to_file(text)) # 这里可以再调用播放器播放 output.mp3 # 例如 Linux 下使用 aplay，macOS 下使用 afplay

edge-tts 的输出是 mp3 文件，需要额外调用系统播放器播放。这也是工程上常见的做法：TTS 生成文件，播放器负责发声，职责分离。

4.5 主循环 main.py

主循环负责把录音、识别、语义、语音串起来。

# 文件路径：saturday-demo/main.py from stt import record_until_silence, transcribe from brain import process from tts import speak def main(): print("Saturday 语音助手已启动") print("按 Enter 开始录音，输入 q 退出") while True: cmd = input("> ").strip() if cmd.lower() in ("q", "quit", "exit"): break audio = record_until_silence() text = transcribe(audio) print(f"[识别] {text}") reply = process(text) print(f"[助手] {reply}") speak(reply) if __name__ == "__main__": main()

这里采用阻塞式交互，每轮执行完才等待下一次输入。对大模型推理和 TTS 播放来说，阻塞意味着一次完整交互可能需要 3 到 8 秒。作为最小 demo 可以接受，但工程化时应该改成异步或队列模式。

4.6 运行与验证

在项目目录下运行：

python main.py

预期流程：

1. 程序输出启动提示。
2. 按回车后，程序开始录音并提示“开始录音，请说话...”。
3. 说一句“现在几点”，停顿 1.5 秒后，程序停止录音。
4. 控制台显示识别文本，例如[识别] 现在几点。
5. 控制台显示[助手] 现在是 14:30。
6. 扬声器播放语音：“现在是 14 点 30 分”。

如果首次运行模型下载较慢，可以先手动下载 whisper 模型文件到本机缓存目录，再重新运行。faster-whisper 会从 Hugging Face 拉取模型，网络状况不好时容易失败。更稳妥的方式是把模型下载到本地后，在WhisperModel中传入模型目录或模型文件路径。

5. 常见问题与排查思路

自托管语音助手的环境问题远比代码逻辑多。下面列出高频问题，基本能覆盖大部分开发者的踩坑场景。

问题现象	常见原因	解决思路
录音没有任何声音	麦克风设备未选中或采样率不匹配	用sounddevice.query_devices()查看设备，在代码中指定设备 ID
识别结果为空或乱码	输入音频采样率不是 16kHz，或者音频太短	统一SAMPLERATE = 16000，开启vad_filter
程序启动后长时间卡住	Whisper 模型首次加载，或模型文件下载失败	提前下载模型到本地，检查模型文件完整性
CUDA out of memory	GPU 显存不足	换小模型、改用compute_type="int8"，或使用 CPU 推理
Linux 下 pyttsx3 无声	缺少 espeak-ng 后端	sudo apt install espeak-ng，重启 Python 进程
麦克风采集到扬声器声音	没有使用耳机，TTS 播放被二次采集	使用耳机；或加入回声消除模块
响应延迟太高	模型太大、量化不到位、串行处理	使用 small/base 模型，开启 int8，语义层用流式接口
识别结果总把“现在几点”听成别的	中文口音或背景噪声影响	使用 larger 模型，用record_until_silence去掉静音，必要时做降噪

排查音频类问题有一个固定顺序：先确认系统能录音，再确认 Python 能拿到音频数据，最后再调试识别模型。很多人跳过前面两步，直接在 Whisper 上报错信息里找答案，效率很低。

下面再补充几个容易踩的坑：

• sd.InputStream返回的音频块是二维数组，shape 为(chunk_samples, channels)，累加后要用np.concatenate(frames).flatten()拉平成一维。
• 如果vad_filter=True报缺失依赖，需要安装 onnxruntime。不想引入额外依赖时，可以关闭该参数。
• faster-whisper 第一次运行会下载模型到~/.cache/huggingface目录。如果你看到网络超时错误，可以先配置 Hugging Face 镜像，或者手动把模型文件放到这个缓存目录。

6. 最佳实践与工程建议

6.1 模块解耦与进程隔离

最小 demo 里所有模块都在同一个 Python 进程内运行。一旦某个调用阻塞，比如大模型推理卡了几秒，整个语音交互就暂时不可用。为了提升稳定性，可以把模块拆成独立进程或微服务：

• STT 服务：常驻内存，接收音频数据，返回文本。
• Agent 服务：接收文本，调用 LLM 和工具，返回回复。
• TTS 服务：接收文本，生成语音文件或音频流。
• 主控服务：负责调度和状态管理。

模块之间可以使用 MQTT、Redis Streams 或简单的 HTTP 接口通信。如果你之前接触过 Spring AI，会发现它的思路和这个非常像：把模型调用抽象成统一接口，上层负责编排。

6.2 配置管理和密钥管理

自托管项目虽然不依赖云端，但很多人依然会混合调用云端 LLM 或 TTS。这类情况下，API Key 绝对不要硬编码在代码里。

建议：

• 配置文件只存放非敏感参数，比如模型名、语言、采样率。
• API Key 使用环境变量或.env文件管理。
• .env文件加入.gitignore，避免提交到仓库。
• 日志里不要打印完整的识别文本，如果要调试，只打印脱敏后的内容。

6.3 日志与可观测性

语音助手的调试难度比普通 Web 应用高，因为问题可能出现在音频采集、识别、语义、合成任何一个环节。建议在关键节点打点：

import logging logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") logger = logging.getLogger(__name__) logger.info("audio duration: %.2f s", len(audio) / config.SAMPLERATE) logger.info("asr_text: %s", text) logger.info("reply_text: %s", reply) logger.info("tts_elapsed: %.2f s", tts_elapsed)

这样每一轮交互的耗时和输入输出都有迹可循，后续做性能优化时也能快速定位瓶颈。

6.4 性能优化方向

如果觉得助手响应“不够快”，可以按优先级做下面几件事：

1. 减小 Whisper 模型：从medium降到small或base，识别耗时可能下降一半以上。
2. 开启vad_filter：过滤静音，避免无效音频进入模型。
3. 降低beam_size：beam_size=1是贪心解码，速度最快；beam_size=5会更准确但更慢。
4. TTS 提前生成：对于固定欢迎语、固定错误提示，可以预生成音频文件，播放时直接读取。
5. 采用流式识别：faster-whisper 支持分块识别，可以在用户说话过程中同步输出中间结果，大幅降低“等待时间”的感受。
6. 将 LLM 推理放到独立进程或独立服务器：避免 STT 和 LLM 抢 CPU 资源。

6.5 从语音助手到 AI Agent

S.A.T.U.R.D.A.Y 这类项目的下一步进化方向是 AI Agent。语音只是入口，真正的能力来自工具调用。比如：

• 理解“帮我订一个明早九点的闹钟”，调用系统定时任务。
• 理解“明天会下雨吗”，调用天气 API。
• 理解“打开客厅灯”，通过 Home Assistant 发送控制指令。
• 理解“总结一下今天的新闻”，调用 RSS 抓取和 LLM 摘要。

工程上，工具调用通常采用 Function Calling 机制。LLM 输出结构化的函数参数，代码解析后执行对应的 Python 函数。相比关键词规则，这种方式的扩展性和泛化能力都更强。

要保证工具调用的安全性，这里有一个基本原则：所有涉及真实环境变更的操作，都必须经过明确授权，并且在测试环境先行验证。比如语音助手控制插座、门锁、文件删除这一类动作，不能只凭一句话就执行。建议在代码里加入二次确认，例如回复“确定要执行吗？请回答是或否”。

7. 总结与下一步学习方向

通过 S.A.T.U.R.D.A.Y 这个项目，我们拆解了一个自托管语音 AI 助手的完整技术链路：麦克风采集音频，faster-whisper 完成语音转文字，规则或大模型负责语义理解，pyttsx3 或 edge-tts 完成语音合成，最后通过执行器调用真实工具。这个链路是当前很多本地语音助手项目的基础骨架。

如果你决定自己动手实现或复刻一个同类项目，建议按下面的顺序推进：

1. 先把录音 -> STT -> 文本打印 的最小链路跑通，不做任何语义处理。
2. 再加入 TTS，让助手能“开口说话”。
3. 第三轮再加入规则引擎，让助手能完成简单的命令。
4. 最后再接入 LLM 和工具调用，逐步增加复杂对话能力。

每一步都验证通过后再进入下一步，排查问题时边界会清晰很多。就我个人的经验来说，自托管语音助手最大的门槛不在模型，而在音频链路和环境适配。只要跨过了麦克风采集和模型加载这两道坎，剩下的事情更像是在组装积木。下一步可以关注 wake word 唤醒、流式对话、RAG 知识库以及智能家居集成，这些方向都能让语音助手从“能对话”进化为“能干活”。