企业级 Voice Agent 架构解析：从音频流到会话状态的实战链路

如果你负责过一个企业级语音助手的选型或开发大概率遇到过这种尴尬场景Demo 阶段一切流畅你对着麦克风说一句话语音识别、大模型回复、语音合成一气呵成但一旦接入真实的呼叫中心、车载系统或智能硬件问题立刻暴露——首响延迟不稳定、用户中途插话被忽略、长时间会话后上下文混乱、并发一高服务直接超时。为什么会这样因为很多团队把 Voice Agent 理解成了“ASR LLM TTS”三段拼接而真正的企业级 Voice Agent是一个需要围绕实时性、状态管理、打断机制和可观测性重新设计的全链路系统。这篇文章打算帮你把 Voice Agent 项目从“能跑 Demo”推进到“能上生产”。我会先讲清楚智能语音体的架构本质再拆解一条完整的企业级实战链路并给出可以直接改用的核心代码片段。同时文章后半部分会整理一套从零开始的学习路线和配套资料清单方便你按阶段推进。全文偏实践默认你有 Python 基础了解基本的 Web 服务和异步编程。需要先说结论决定 Voice Agent 生产可用性的不是某一个模型的智商而是整条链路的延迟预算、断言语义和会话状态管理。论文里常把 Voice Agent 称为“实时对话系统”它的核心挑战不是生成文字而是在几百毫秒内完成“听清—听懂—回复”的闭环并在用户随时插话时保持对话不崩。下面我们从架构开始拆。1. Voice Agent 不是什么新概念但这次真的不一样语音助手并不新鲜。十年前 IVR交互式语音应答系统就能听懂“查余额”“办挂失”这类固定指令医疗、金融、政务行业也早就有基于关键词匹配的语音机器人。但传统方案本质上是“指令识别 流程跳转”用户只能说系统预设好的话不能自由表达更不能进行多轮复杂对话。大模型出现后语音交互的体验边界被彻底拉开。现在的 Voice Agent 可以做到用户用自然语言描述一个复杂诉求比如“帮我查一下上个月所有超过两千元的餐饮消费然后按金额降序整理出来”系统能理解意图并调用工具完成。用户随时打断 Agent 的回答说“等一下我改一下时间范围”Agent 能及时停止播放、更新上下文并给出新回复。Agent 在不同业务之间切换时能保持对话记忆知道用户是“那位上周咨询过企业年检的财务”。这套能力的背后是大模型对语义的理解、工具调用的规划能力以及语音链路本身的高效协同。所以现在讨论的 Voice Agent本质上是“语音交互界面 Agent 决策大脑 企业业务系统”三者的融合体。它解决的不再是“听懂指令”而是“完成目标”。关于名称行业里还有几个常见叫法Voice Agent、语音智能体、Speech Agent、Conversational AI Agent。它们指向的核心基本一致区别更多在厂商包装和落点侧重。Voice Agent 更强调语音输入输出端到端的体验Agent 智能体强调自主规划与工具调用Conversational AI 则偏整体对话系统。企业选型时不必太纠结叫法重点看三件事ASR 的准确率和延迟、LLM 在一次完整对话中的稳定表现、TTS 的自然度和响应速度。2. 理解 Voice Agent 的三大核心模块与一条关键链路一个可用的 Voice Agent 系统至少包含四个部分语音识别模块、大模型决策模块、语音合成模块、会话状态管理模块。前三个负责完成“听、想、说”的基本闭环第四个负责把多轮交互串成有记忆的连贯对话。先看一条典型的 Voice Agent 执行链路用户说话 - 前端采集 - VAD 检测 - ASR 识别 - LLM 推理与工具调用 - TTS 合成 - 音频播放 - 用户听到回复 \--------------------------- 打断检测可以随时介入链路中三个关键模块的作用分别是什么我在这里做一个对比模块负责内容典型技术生产关注点ASR将语音转为文本Whisper、Paraformer、Kaldi识别准确率、首字延迟、方言/专业词适配LLM Agent理解意图、生成回复、调用工具GPT-4o、Qwen、DeepSeek、GLM推理延迟、上下文管理、工具调用稳定性TTS将文本转为自然语音CosyVoice、Edge TTS、ElevenLabs合成延迟、自然度、情感表达状态管理维护多轮会话上下文Redis、MongoDB、内存态会话一致性、超时策略、并发隔离这里要特别强调 VAD语音活动检测。VAD 解决的关键问题不是“识别这句话说了什么”而是“判断用户什么时候开始说话、什么时候说完”。这个判断直接影响两个体验指标一是“首字延迟”因为系统要等到检测到用户说完才能触发 ASR二是“打断体验”因为系统需要实时监测用户是否有新语音进入。很多团队在 Demo 阶段不太关注 VAD直接用录音结束作为触发条件但到了真实环境就会发现电话录音有静音段、有背景噪声还有用户边说边停顿。VAD 参数调不好要么一句话被切成两半要么系统迟迟不触发识别。所以我们在工程实现中通常把 VAD 单独抽象成一个组件并且允许针对不同场景配置不同的静音阈值和触发时长。3. 企业级项目真正的门槛延迟、状态与并发从架构图上看Voice Agent 似乎不复杂就是把三个模型串起来。但企业级项目与个人 Demo 之间隔着几个非常现实的问题。延迟预算是第一个门槛。语音对话的心理学研究表明超过 600ms 的响应延迟就会让用户明显感到“不自然”。电话场景的容忍度略高但也不能超过 1 秒。这个延迟是 ASR、LLM、TTS 三者之和。ASR 通常需要 100-300msTTS 需要 200-400ms留给大模型的时间只有 300-500ms。大模型通常要 1 秒以上才能生成完整回复所以在生产系统里我们不可能等 LLM 完整输出后再开始合成语音。常见的做法是流式输出LLM 一边生成文本TTS 一边消费文本流合成音频音频一边推给播放端。这样首句响应时间可以压缩到 500ms 左右后续内容持续流入。会话状态管理是第二个门槛。Demo 阶段每次对话可以独立处理但企业级场景里用户会连续说好几轮Agent 需要记住用户刚才提过的条件、已经查过的数据、正在进行的操作。如果每轮都把全部历史记录塞给大模型Token 消耗会快速膨胀还会引入大量无关信息干扰判断。实际工程中更常见的是维护一个结构化会话对象当前会话 ID、用户画像、业务上下文、最近 N 轮摘要、正在执行的工具任务。在关键节点做摘要压缩而不是无脑拼历史。并发与资源隔离是第三个门槛。一个呼叫中心可能同时有几百路通话每一路都是一条完整的 ASR LLM TTS 链路。如果全部接入同一个大模型服务容易出现限流和互相挤占。生产系统一般会做会话级并发控制限制单会话并发数、设置队列超时、为大模型调用配置独立的速率配额。不同业务线之间也尽可能隔离避免某个高并发业务把资源池占满后影响其他业务。这四个模块连起来才算一条能够支撑企业级项目的主链路。下面我们直接进入实战先准备好环境。4. 实战前提环境准备与技术栈选型本文的实战代码以 Python 为主使用 FastAPI 搭建服务端使用 WebSocket 传输语音流ASR 和 TTS 模块采用接口适配器模式便于替换成不同厂商的服务。这里不绑定具体云厂商也不依赖特定大模型的私有 API重点是让你理解链路是怎么串起来的。建议环境如下Python 3.10需要支持 asyncio。FastAPI 和 uvicorn用于搭建 WebSocket 服务。一个可用的 ASR 服务接口可以是本地模型封装也可以是云端 API。一个可用的 LLM API支持 OpenAI 兼容格式即可。一个可用的 TTS 服务接口输出音频 base64 或二进制。安装基础依赖pip install fastapi uvicorn websockets pydantic openai如果你的 ASR 和 TTS 使用本地开源模型例如用 Whisper 做识别、CosyVoice 做合成还需要额外安装对应依赖。这里为了避免绑定特定模型我先用接口适配器的方式封装这样无论你后续接阿里、腾讯、字节、百度的语音服务还是自建模型都只需要替换底层实现。核心工程结构建议如下voice-agent-project/ ├── main.py # FastAPI 入口WebSocket 路由 ├── modules/ │ ├── asr.py # ASR 适配器 │ ├── llm_agent.py # LLM Agent 封装 │ ├── tts.py # TTS 适配器 │ └── session.py # 会话状态管理 ├── config.py # 全局配置 └── requirements.txt这种模块化划分的好处是链路中的任何一环都可以独立替换和升级。你换一家 ASR 厂商或换一个 LLM不会影响其他模块的代码。5. 核心链路代码实现从音频流到语音回复5.1 定义会话状态管理模块会话管理是 Voice Agent 与普通问答机器人最大的区别。我们先用一个轻量级 SessionManager 管理会话上下文它会保存对话历史并在超过一定轮数后做摘要压缩避免 Token 无限膨胀。# 文件路径modules/session.py import time import uuid from typing import Dict, Optional class Session: def __init__(self, session_id: str, user_profile: Optional[dict] None): self.session_id session_id self.user_profile user_profile or {} self.history [] # 保存最近对话记录 self.summary # 超过轮数后保存历史摘要 self.created_at time.time() self.last_active_at time.time() self.current_tool_task None # 正在执行的工具任务 def append(self, role: str, content: str): self.history.append({role: role, content: content}) self.last_active_at time.time() if len(self.history) 8: self.summary self._compress_history() def _compress_history(self): # 实际工程中可以调用 LLM 做摘要这里用截断方式简化 recent self.history[-4:] return f[历史摘要] {self.history[:-4]} 后续对话见详细记录。 def build_messages(self, user_query: str) - list: messages [] if self.summary: messages.append({role: system, content: self.summary}) for item in self.history[-6:]: messages.append({role: item[role], content: item[content]}) messages.append({role: user, content: user_query}) return messages class SessionManager: def __init__(self, timeout_seconds: int 1800): self.sessions: Dict[str, Session] {} self.timeout_seconds timeout_seconds def get_or_create(self, session_id: Optional[str] None) - Session: if session_id and session_id in self.sessions: session self.sessions[session_id] session.last_active_at time.time() return session new_id session_id or uuid.uuid4().hex session Session(new_id) self.sessions[new_id] session return session def cleanup(self): # 定期清理超时会话避免内存泄漏 now time.time() expired [sid for sid, s in self.sessions.items() if now - s.last_active_at self.timeout_seconds] for sid in expired: del self.sessions[sid]这段代码的重点在于 build_messages 的设计。在真实项目中我们并不会把全部历史都送给大模型而是保留最近几轮配合历史摘要。这样既能维持对话连续性又能控制 Token 消耗。5.2 定义 ASR 与 TTS 适配器为了让代码不被具体厂商绑定ASR 和 TTS 都采用适配器模式。你只需要实现对应的 process 方法就能替换底层引擎。# 文件路径modules/asr.py from abc import ABC, abstractmethod class BaseASR(ABC): abstractmethod async def transcribe(self, audio_bytes: bytes) - str: 将音频字节流转为文本 pass class MockASR(BaseASR): 本地模拟 ASR方便在没有真实语音服务时调试 async def transcribe(self, audio_bytes: bytes) - str: # 实际项目中这里调用云厂商 ASR 服务 return 帮我查一下上周的销售数据# 文件路径modules/tts.py from abc import ABC, abstractmethod class BaseTTS(ABC): abstractmethod async def synthesize(self, text: str) - bytes: 将文本合成为音频字节流 pass class MockTTS(BaseTTS): 本地模拟 TTS async def synthesize(self, text: str) - bytes: # 实际项目中这里调用 TTS 服务获取音频 return bmock_audio_data实际开发时你可能要处理音频编码格式转换、采样率对齐、vad 检测等细节。这里先把接口抽象出来后续替换实现时核心链路代码不用大改。5.3 封装 LLM AgentLLM Agent 是 Voice Agent 的决策核心。我们使用 OpenAI 兼容的接口协议请求格式统一这样你可以随意切换不同厂商的模型服务。# 文件路径modules/llm_agent.py import os from openai import OpenAI class LLMAgent: def __init__(self, model: str gpt-4o-mini, base_url: str None, api_key: str None): self.model model self.client OpenAI( base_urlbase_url or os.getenv(LLM_BASE_URL, https://api.openai.com/v1), api_keyapi_key or os.getenv(LLM_API_KEY, ), ) async def chat(self, messages: list, stream: bool False): if not stream: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperature0.7, ) return resp.choices[0].message.content # 流式模式返回生成器便于 TTS 边生成边合成 def gen(): stream_resp self.client.chat.completions.create( modelself.model, messagesmessages, streamTrue, temperature0.7, ) for chunk in stream_resp: delta chunk.choices[0].delta.content if delta: yield delta return gen()stream 参数在这里很关键。企业级 Voice Agent 必须使用流式输出大模型生成文本时TTS 已经可以把已生成的句子合成为音频。这样用户不用等大模型把整段回复写完才能听到声音。5.4 WebSocket 语音服务入口下面是最核心的部分WebSocket 服务把音频流、ASR、LLM、TTS、Session 串成一条完整的 Voice Agent 链路。# 文件路径main.py import asyncio import base64 import json from fastapi import FastAPI, WebSocket from modules.asr import MockASR from modules.tts import MockTTS from modules.llm_agent import LLMAgent from modules.session import SessionManager app FastAPI() asr MockASR() tts MockTTS() llm_agent LLMAgent() session_manager SessionManager(timeout_seconds1800) app.websocket(/voice-agent) async def voice_agent_endpoint(websocket: WebSocket): await websocket.accept() session session_manager.get_or_create() print(fNew session: {session.session_id}) try: audio_buffer bytearray() while True: message await websocket.receive_text() data json.loads(message) if data.get(type) ping: await websocket.send_text(json.dumps({type: pong})) continue if data.get(type) audio: # 前端上传的音频分片这里累积成一段完整音频 audio_chunk base64.b64decode(data[data]) audio_buffer.extend(audio_chunk) # 判断是否为一段话的结束这里简化处理前端标志 bit_done if data.get(bit_done): # 1. ASR 识别 user_text await asr.transcribe(bytes(audio_buffer)) print(f[ASR] {user_text}) audio_buffer.clear() if not user_text: await websocket.send_text(json.dumps({type: error, message: 未识别到有效语音})) continue # 2. 拼接待发送消息 messages session.build_messages(user_text) session.append(user, user_text) # 3. LLM 流式生成 generator await llm_agent.chat(messages, streamTrue) full_answer for chunk in generator: full_answer chunk # 这里可以做增量 TTS 或累积后 TTS本文简化处理 session.append(assistant, full_answer) print(f[LLM] {full_answer}) # 4. TTS 合成 audio_bytes await tts.synthesize(full_answer) # 5. 返回结果 await websocket.send_text(json.dumps({ type: answer, session_id: session.session_id, text: full_answer, audio: base64.b64encode(audio_bytes).decode(utf-8), })) elif data.get(type) clear: # 清空会话上下文重新开始对话 session session_manager.get_or_create() await websocket.send_text(json.dumps({type: cleared})) except Exception as e: print(f[ERROR] {e}) await websocket.send_text(json.dumps({type: error, message: str(e)})) finally: await websocket.close()这段代码的流程就是 Voice Agent 的最小完整闭环接收语音分片攒够一句话后触发 ASR得到文本后交给 LLM拿到答案后合成语音返回。前端收到音频后播放给用户。需要注意的是这是一个最小闭环的简化实现它还没有处理流式 LLM 与流式 TTS 的细致协同。生产环境通常会把 LLM 的输出做流式中转TTS 按句子切分消费避免一次性等待完整回复但这已经足够帮你跑通整个链路。5.5 启动服务并测试服务写好后用 uvicorn 启动uvicorn main:app --host 0.0.0.0 --port 8000 --reload浏览器或爬虫工具访问ws://localhost:8000/voice-agent发送一段 json 音频包即可看到完整链路执行过程。简单模拟可以用 websocket 客户端脚本发送假音频# 文件路径test_client.py import asyncio import base64 import json import websockets async def test(): async with websockets.connect(ws://localhost:8000/voice-agent) as ws: # 发送一段模拟音频 audio bfake_audio_data msg { type: audio, data: base64.b64encode(audio).decode(utf-8), bit_done: True } await ws.send(json.dumps(msg)) while True: resp await ws.recv() print(f收到响应: {resp}) break asyncio.run(test())如果代码与配置没问题你会看到类似下面的输出New session: b3a1c1d2... [ASR] 帮我查一下上周的销售数据 [LLM] 根据您的要求正在查询上周的销售数据...这里因为我们用了 MockASR 和 MockTTS所以 ASR 文本是写死的TTS 返回的是假音频。接入真实服务时替换适配器即可。6. 打断检测与流式交互生产体验的分水岭如果你已经跑通了上面的链路会发现一个体验问题当 LLM 正在生成回复、TTS 正在播放语音时用户如果想插话系统完全没有感知。用户只能等 Agent 说完机器不会“闭嘴”。打断处理是 Voice Agent 从“能用的 Demo”走向“可用的产品”最明显的一道分水岭。没有打断能力的语音助手在真实场景中基本无法使用。试想一下电话客服场景用户对某个回答不满意想立刻纠正但 Agent 还在一字一句播报上一段回复用户只能强忍着听完这种体验远谈不上“智能”。工程上实现打断通常分成两层第一层是语音层面的打断。前端或服务端持续做 VAD 检测一旦检测到用户开始说话立即停止 TTS 播放。这一步不需要理解用户说了什么只需要检测到新的语音能量进入。第二层是语义层面的打断。检测到用户说话后把用户的新语音转成文字结合对话历史判断用户是否真的在发起新请求还是只是环境声。例如 Agent 正在播报时用户说“好了我知道了”系统应终止当前播报并准备进入下一轮如果用户只是咳嗽一声系统应继续完成当前回复。在代码层面打断机制涉及的改造点包括WebSocket 消息需要支持同时双向传输、前端需要实时上传音频同时接收音频流服务端需要为每个会话维护状态机状态分为 IDLE、LISTENING、PROCESSING、SPEAKING。当用户在 SPEAKING 状态触发 VAD状态切换为 LISTENING并中断 TTS 播放。这部分改造工作量不小但属于语音交互产品的必选项。7. 运行验证与效果评估链路跑通后最好不要只看“能播报”就觉得完成了。作为企业级项目你需要一套效果评估方法。建议从四个维度评估一个 Voice Agent 项目ASR 准确率。取一段真实业务录音转写后用字错误率衡量。如果业务存在专业术语、地名、产品名一定要加入自定义词表测试。比如金融场景中“定期理财”“基金定投”这类词通用模型可能识别成同音字。你需要准备一份热词表交给 ASR 服务。端到端响应延迟。从用户说完最后一个字到 Agent 播放第一个音频字节的时间差。企业级项目一般要求控制在 800ms 以内。测试时要注意延迟不能只测一次成功案例要统计多次取 P95。因为真实环境里大模型偶尔会慢P95 更接近用户感知。多轮对话保持能力。连续对话 10 轮以上检查 Agent 是否记得用户最初提出的条件。比如用户第一轮说“预算十万以内”第五轮问“那帮我推荐一款”Agent 的回答不应出现“我理解您的预算是二十万”这种错误。建议把多轮对话用例固化成一个测试集每次改动后自动回归。任务完成率。如果是业务型 Agent还要评估最终目标是否达成。比如一个查快递的 Voice Agent用户问“我的快递到哪了”正确的完成态是 Agent 告知当前物流节点而不是只返回“查询成功”这类无意义回复。如果测试中发现 ASR 识别不准优先检查音频采样率、编码格式、VAD 切句阈值。如果 LLM 回复质量不稳定优先检查提示词设计和上下文裁剪策略。如果延迟超标优先检查是否使用了流式 LLM 输出以及 TTS 是否按句子切分合成而不是等整段文本生成完再合成。8. 常见问题与排查思路这套链路项目做多了一些问题几乎每次都会遇到。我整理了一张排查表方便你排错时直接对号入座。问题现象可能原因排查方式解决方案ASR 识别结果为空音频采样率不匹配或声音过小查看音频格式与 ASR 服务支持格式是否一致统一音频格式与采样率适当做增益处理首响延迟大于 1 秒等 LLM 完整输出后再合成 TTS检查链路是否使用 stream 模式改为流式输出LLM 边输出 TTS 边合成用户打断没反应前端未做实时 VAD 检测检查前端是否在上传音频同时接收音频增加双向 WebSocket 通道实现实时 VAD多轮对话后上下文混乱历史消息未做裁剪与摘要检查 Session 中 build_messages 逻辑限制最近轮数增加摘要压缩机制高并发时大量超时所有会话共享同一大模型配额查看大模型 API 限流信息增加队列、超时和会话级并发控制TTS 语音听起来很机械未启用情感控制或声音选择不当检查 TTS 参数配置调整音色、语速、韵律参数或换用更自然的合成引擎每个问题在第一次遇到时都可能让人困惑但背后的原理并不复杂。Audio 链路的问题先看数据格式文本链路的问题先看上下文管理并发链路的问题先看配额与资源竞争。按这个思路排查大部分问题都能在半小时内定位。9. 企业级落地的最佳实践从代码 Demo 走向生产需要在多个方面补足工程细节。我总结了几条最容易踩坑的原则。对话状态必须持久化。进程重启后会话状态不能丢。生产环境使用 Redis 保存会话数据设置过期时间定期清理超时会话。跨多个实例部署时需要保证同一会话的请求路由到同一个实例或者全部状态都放到共享存储中否则出现会话漂移问题。最少权限原则调用企业工具。Voice Agent 接企业内部系统时一定要做好权限控制。比如接入 CRM 查询客户信息Agent 只能访问当前用户有权访问的数据范围不能因为 Agent 有更高权限就绕过业务权限体系。所有工具调用都要有审计日志。随时准备失败降级。大模型和语音服务属于外部依赖可能出现超时、限流、返回异常。生产系统必须为每个环节设置超时时间和降级方案。例如 LLM 超时后可以返回一句固定兜底话术“抱歉我现在无法处理您的请求请稍后再试。” 虽然不够智能但至少不会让用户面对死循环或无响应。可观测性要单独设计。Agent 项目比普通 Web 项目更难调试因为链路过长且涉及多个模型。建议在每一步关键节点记录日志接收到音频、ASR 完成、LLM 开始生成、LLM 结束生成、TTS 完成。用 trace_id 贯穿整条链路方便在一次对话中搜索所有环节的日志和耗时。语音交互是强实时场景日志采样率不要低于 100%否则生产问题几乎无法复盘。相比之下普通 Web 接口可以按百分比采样语音链路建议全量记录只对音频原始内容做脱敏处理。10. 学习路线与资料方向如果你是从零开始接触 Voice Agent建议按照下面的路线推进避免一上来就陷入模型参数细节。第一阶段打牢语音基础。理解 ASR、TTS、VAD 三个概念解决什么问题分别有哪些代表技术。这个阶段推荐重点学习语音信号基础知识和开源工具用法尝试用现成模型跑通“录音 - 识别 - 合成”的最小流程。第二阶段上手 Agent 概念。Agent 的核心不是调用大模型而是理解“工具调用”和“任务规划”。建议先把 OpenAI Function Calling 或 ReAct 模式的官方示例跑一遍理解大模型如何根据用户意图选择工具并组织参数。这是 Voice Agent 能和企业系统打通的关键。第三阶段串起完整链路。把你掌握的 ASR、LLM Agent、TTS 三个模块串起来做一个最小语音对话服务。关键不是写代码而是理解每一环之间的数据流怎么传递以及延迟瓶颈在哪里。第四阶段工程化与生产化。学习 FastAPI WebSocket 服务、Redis 会话管理、Docker 部署、并发控制与可观测性。这个阶段建议直接找一个真实业务场景比如“会议室预订语音助手”或“企业知识库问答语音助手”从头到尾完成需求分析、开发、部署和评估。学习资料方面可以重点关注几类内容各语音厂商的官方文档通常包含 API 示例和最佳实践大模型 Function Calling 的官方文档与示例代码开源语音项目的源码比如语音识别和语音合成相关的代表性开源项目还有真实场景的系统设计案例。如果在学习过程中卡住我建议优先回到链路本质想问题这一步是在“听话”还是在“思考”还是在“说话”只要你能判断当前卡点属于哪个环节就能快速找到对应的资料和解决方案。11. 写在最后Voice Agent 是一个非常典型的“看起来简单做起来复杂”的方向。简单在于概念链路清晰ASR LLM TTS 三个模块谁都能说出来复杂在于真实产品的延迟控制、打断处理、状态管理、工具调用和并发稳定性每一个环节都需要大量工程细节堆叠。这几年 Agent 的技术迭代速度很快模型能力也在持续提升但底层的工程挑战不会消失。掌握从音频流到会话状态的完整链路是做好任何一个智能语音产品的根基。这篇文章给出的代码是一个最小闭环可以作为你学习或启动项目的脚手架但不要停在 Demo 阶段。建议接下来把 MockASR 替换成真实 ASR 服务把 MockTTS 替换成真实 TTS 服务然后接一个你自己的业务工具体验一次完整的“用户说一句话、Agent 完成一个任务”的全过程。到那一步你对 Voice Agent 的理解会比看一百篇文章都深入。