从智能座舱到语音客服：基于qwen-audio-agent构建实战场景全解析

【免费下载链接】qwen-audio-agentA realtime voice runtime that keeps Agents talking, working, and present. Real-time Voice Runtime for AI Agents项目地址: https://gitcode.com/gh_mirrors/qw/qwen-audio-agent

qwen-audio-agent 是一个面向 AI Agent 的实时语音运行时，它让 Agent 不仅能"听、说、聊"，还能真正"动手办事"。基于它，社区已经沉淀出一批可运行的实战场景：在 docs/scenarios/index.zh.md 的示例索引中，智能座舱（用自然语音控车、导航、放音乐）和语音客服（零售订单查询、退款、航旅改签）是最有代表性的两个——一个演示了"语音 × 硬件设备"的边界，另一个演示了"语音 × 企业业务流程"的边界。

本文将带你拆解这两个场景的设计思路、架构分工与落地步骤，帮你看懂"实时语音 + 工具调用 + 后台 Agent"这一套组合拳，并给出复用到自己业务的替换路径。

三个核心概念：看懂实时语音 Agent 的分工

在深入场景之前，先花两分钟理解 qwen-audio-agent 的三层接入参考架构，后面所有场景都是这个骨架的"换装"。

理解这张图的关键在于spawn_thinking：当用户的一句话需要多步业务操作（比如"取消订单并退款"）时，前台不阻塞通话，而是把它结构化成任务委托给后台 Agent，前台继续和用户说话。任务完成后，结果再以"一句话摘要 + 完整文本"的形式回到前台播报。

这一设计同时出现在智能座舱和语音客服两个场景里——前台管快，后台管深，是所有场景复用的核心模式。

场景一：智能座舱，用自然语言开车

智能座舱示例（examples/smart-cockpit/README_ZH.md）让用户通过语音完成车控、导航、音乐、天气、闪购和自定义技能，座舱 UI 同步展示车辆与任务状态。它是框架"前台实时对话 + 工具调用 + 可替换后台 Agent"三种能力的完整组合。

38 个 MCP 工具覆盖 6 大车载领域

座舱 Service 把车上的能力统一定义为 MCP 工具，模型看到的是一个干净的"函数工具面"：

工具目录与注册方式见 examples/smart-cockpit/service/tools/README.md。

前台快、后台深：座舱如何分工

前后台分工不是拍脑袋定的，而是靠一份路由配置决定。打开 examples/smart-cockpit/service/tools/surface-routing.json 就能看到每个工具归属前台还是后台：

• 前台 Realtime 直调：车控、导航、音乐、天气——要求秒级响应，平均工具返回时延约1.48 秒；
• 后台 Agent 委托：闪购下单、多来源新闻研究等长任务——平均时延约 3.56 秒，但执行期间前台不中断，你还可以继续跟它聊天。

官方评测数据（短用例 86 例整例通过率 97.67%，500 轮长对话逐轮工具准确率 99.80%）也验证了这套"前后台分流 + 运行时保护"的稳定性，明细见示例 README 的评测章节。

智能座舱架构：谁负责什么

四个组件各司其职，任意一个都可以被你的自有实现替换：

注意Service 不是额外的 Agent 层，而是前后台共享的"环境与基础设施"：车辆状态、路线、订单都存在这里，界面通过 SSE 通道实时投影——这正是"语音说话、屏幕同步亮灯"体验的来源。

本地跑起一个智能座舱

在仓库根目录执行（首次使用先克隆仓库：git clone https://gitcode.com/gh_mirrors/qw/qwen-audio-agent）：

cp examples/smart-cockpit/.env.example examples/smart-cockpit/.env.local # 在 .env.local 中填入 DASHSCOPE_API_KEY（地图 Key 可选） npm run example:smart-cockpit:install npm run example:smart-cockpit

一条命令会同时拉起 service、agent、gateway 和 client 四个进程，浏览器打开http://localhost:5173即可对着麦克风说"把空调调到 22 度"。

场景二：语音客服，从订单查询到退款办结

客服示例（examples/customer-service/README_ZH.md）把同一套前后台架构搬进了企业业务流程：语音前台负责沟通、身份核验与只读查询，涉及金额、不可逆或组合型操作则通过 A2A 交给后台 Agent 执行。

两个行业域，同一套流程

最值得关注的设计：写操作必须先预览、再批准

语音客服最容易踩坑的地方是"模型自作主张改了数据"。这个示例给出了教科书式的解法——批准不是模型填一个 true：

1. 写工具首次调用只生成预览和内部审批令牌，不落库；
2. 客户听到的是可读的预览（"将取消订单 #W1082334，退款 ¥xxx 原路退回"）；
3. 客户说"同意取消"，前台把决定回传，executor 才真正提交原操作；
4. 拒绝、取消或超时（5 分钟有效期）一律撤销令牌，参数漂移（比如预订已变化）也会拒绝提交；
5. 每笔写操作逐笔重新批准，不共用上一次同意。

资格、金额、库存规则不靠模型记忆，而是由服务层的guards.json决策表执行（examples/customer-service/service/guards.mjs），policy 缺口或超权限金额会明确转人工，而不是让模型编规则。

三张"管理台"，把运营也做进示例

启动方式同样简单：

npm install npm run example:customer-service:install npm run example:customer-service # 零售域 # 或 npm run example:customer-service:airline # 航空域

打开工作台后允许麦克风访问，按 README 给出的口令（如"查询订单"→"取消订单"→先说"不取消了"再说"同意取消"）即可完整体验"预览 → 批准 → 办结"的闭环。

实测数据：前后台架构值多少分？

示例内置了 EVA Airline 50 任务的公开评测，三条路径对比很有说服力：

结论清晰：纯语音前台无法独立完成复杂业务，但"语音前台 + 后台委托"把完成率从 44% 拉到 62%，接近纯文本上限，同时保留了自然的语音交互。完整口径见 examples/customer-service/benchmark/。

两个场景的共性：一张可复用的架构配方

对比下来，两个场景其实是同一张配方的两份填法：

这张配方可以抽象成四步，套用到你自己的业务：

1. 定义领域工具：把业务能力写成 MCP 工具，放入 Service；
2. 划前后台边界：低延迟查询走前台，写操作/长任务走后台（客服场景写操作必须留在后台，因为前台没有可挂起的批准生命周期）；
3. 接入协议：客户端用 Gateway Client Protocol 对话，后台 Agent 用 A2A 接入，协议文档见 docs/gateway-protocol.zh.md；
4. 界面同步：用 HTTP/SSE 把业务状态投影到你的 UI。

下一步：把配方搬进你的业务

最后提醒：示例均为本地演示环境，进程重启后内存状态会清空，也不具备生产级鉴权，接入生产前需要补充持久化与访问控制。但从"能跑起来"到"改成自己的"，两个示例已经铺好了最短路径——跑通一个，你就拿到了整个实时语音 Agent 的架构手感。

【免费下载链接】qwen-audio-agentA realtime voice runtime that keeps Agents talking, working, and present. Real-time Voice Runtime for AI Agents项目地址: https://gitcode.com/gh_mirrors/qw/qwen-audio-agent