第 14 章 座舱多模对话机器人：可控、可靠、可解释
1. 开篇段落
智能座舱（Smart Cockpit）是多模态 AI 落地最复杂、要求最严苛的场景之一。与家庭音箱或手机助手不同，车载 Agent 运行在一个移动的、高风险的、多成员共存的物理空间中。
在这里，Agent 不仅仅是一个聊天机器人，它是车辆操作系统（OS）的人格化接口。它需要同时处理毫秒级的车辆控制指令（如“打开雨刮”）和开放域的知识问答（如“前面那个雕像是什么”）。
本章学习目标：
- 掌握端云混合架构：如何在无网、弱网环境下保证核心功能（车控）的绝对可用性。
- 理解多模态融合感知：结合麦克风阵列（听觉）、车内摄像头（视觉）和 CAN 总线（触觉/本体感觉）来精准理解意图。
- 构建安全护栏：设计符合驾驶认知负荷（Cognitive Load）的安全策略，确保 AI 不会成为“马路杀手”。
2. 核心技术论述
2.1 整体架构：端云协同与分层仲裁
车载环境的网络连接是不稳定的（隧道、地下车库、偏远山区），但车辆控制必须由 100% 的可靠性。因此，座舱 Agent 普遍采用 “端侧优先（Edge-First）” 的混合架构。
[ Architecture: Hybrid In-Cabin Agent ]
User Interaction (Voice / Gaze / Touch)
||
\/
+-------------------------------------------------------------+
| 1. PERCEPTION LAYER (Sensors & Signal Processing) |
| [Mic Array] -> Beamforming -> VAD -> [Wake-up Engine] |
| [Cabin Cam] -> Face ID -> Gaze Tracking -> Emotion Detect |
| [Vehicle Bus] -> Speed / Gear / Wiper / Temp / GPS |
+-------------------------------------------------------------+
|| (Clean Audio + Visual Context + Car State)
\/
+-------------------------------------------------------------+
| 2. ORCHESTRATION & ROUTING (The "Switch") |
| |
| Is it a Car Control Command? (e.g., "Windows down") |
| Yes -> [Edge NLU] (Fast, Offline, Deterministic) |
| No -> [Cloud LLM] (Slow, Online, Reasoning-heavy) |
+-------------------------------------------------------------+
// \\
// (Local Slot Filling) \\ (Reasoning & Tools)
// \\
+--------------+ +------------------+
| 3a. EDGE EXE | | 3b. CLOUD BRAIN |
| Rule Engine | | RAG / Search |
| Car Service | | Global Knowledge |
+--------------+ | Complex Planning |
| +------------------+
| |
+------------+---------------+
|
\/
+-------------------------------------------------------------+
| 4. ACTION & GENERATION LAYER |
| [Arbitration]: Safety Check (Speed > 0? Child Lock on?) |
| [Feedback]: TTS (Voice) + UI (Screen Card) + Ambient Light |
| [Actuation]: Send signal to ECU/BCM (Body Control Module) |
+-------------------------------------------------------------+
2.2 听觉感知的极限：声源定位与多音区
在车内，“谁在说” 和 “说什么” 同等重要。车内是一个典型的“鸡尾酒会效应”场景，充斥着风噪、胎噪、音乐声和乘客的交谈声。
2.3 视觉融合：从“语音助手”到“虚拟副驾”
视觉模态解决了语音交互中最大的痛点：指代不明。
2.4 安全护栏：驾驶员认知负荷管理
这是座舱 Agent 与 ChatGPT 最大的区别。ChatGPT 可以生成长篇大论，座舱 Agent 必须惜字如金。
3. 本章小结
- 混合架构是刚需：必须将高频、高安全要求的车控指令留在端侧（Edge），将长尾内容放至云端。
- 上下文包含物理状态：Prompt 中必须注入车辆状态（车速、档位、车窗开合度、胎压），否则 Agent 就是瞎子。
- 多模态即安全：利用视觉确认（FaceID）和声纹识别来防止未授权的操作（如儿童误操作）。
- 沉默是金：优秀的座舱 Agent 知道何时闭嘴，不干扰驾驶员的注意力是最高优先级。
4. 练习题
基础题 (50%)：逻辑与协议
Q1. 状态感知的 Prompt 构建
背景：你需要将用户的自然语言请求发送给云端 LLM 进行意图解析。
题目：请设计一个 JSON 结构的 System Prompt 上下文（Context），包含座舱场景必须的关键动态信息。请至少包含 4 类关键状态数据。
提示：想想如果用户说“我觉得有点闷”，Agent 需要哪些传感器数据才能决定是“打开窗户”还是“打开空调外循环”？
点击查看参考答案
```json
{
"system_context": {
"vehicle_state": {
"speed_kmh": 85, // 决定是否能开窗（高速开窗风噪大，倾向于空调）
"gear": "D",
"wipers_active": true, // 正在下雨，绝对不能开窗
"windows": { "fl": 0, "fr": 0, "rl": 0, "rr": 0 }, // 0=closed
"ac_mode": "recirculation" // 当前是内循环，可能导致闷
},
"environment": {
"outside_temp_c": 15, // 外面冷，可能不适合开大窗
"inside_temp_c": 26,
"air_quality_aqi": 45 // 空气质量良好，允许切换外循环
},
"user_state": {
"driver_drowsiness_level": "low", // 如果困倦，可能需要冷风刺激
"occupancy": ["driver", "passenger_front"]
}
},
"query": "我觉得有点闷"
}
```
**解析**：
* **雨刮器状态**是关键的一票否决权（下雨不开窗）。
* **车速**决定了开窗的噪音成本。
* **内外温差**辅助决策是调节温度还是仅仅换气。
Q2. 优先级仲裁逻辑
背景：Agent 接收到两个并发指令。
- 主驾（驾驶员）说：“导航去公司。”
- 副驾（乘客）说：“我要看电影。”
题目：请编写一段伪代码逻辑，处理这两个请求的冲突与并发。假设中控屏只有一个，且行驶中不能播放视频。
点击查看参考答案
```python
def arbitration(driver_intent, passenger_intent, car_state):
actions = []
# 1. 处理主驾请求 (高优先级)
if driver_intent.type == "NAVIGATION":
actions.append({
"target": "center_screen_map",
"action": "set_destination",
"value": "Work"
})
# 2. 处理副驾请求
if passenger_intent.type == "MEDIA_VIDEO":
if car_state.speed > 0:
# 安全限制：行驶中主屏禁播视频
if car_state.has_passenger_screen:
# 如果有专属副驾屏，重定向到副驾屏
actions.append({
"target": "passenger_screen",
"action": "play_video",
"value": passenger_intent.value
})
actions.append({"feedback": "好的，已为您在副驾屏播放。"})
else:
# 只有中控屏，拒绝请求
actions.append({"feedback": "为了安全，行驶中无法播放视频，我可以为您播放音频。"})
else:
# P档停车状态，可以抢占中控屏，但需询问主驾
actions.append({"feedback": "现在是停车状态，要在主屏播放吗？这会覆盖导航画面。"})
return actions
```
Q3. 离线意图表设计
背景：为了保证离线可用性，端侧 NLU 通常使用基于规则或轻量级 Slot-Filling 模型。
题目：列出 5 个必须在断网情况下依然能完美工作的指令类别（Domain）。
点击查看参考答案
1. **车控 (Vehicle Control)**：打开/关闭车窗、空调、座椅加热、后备箱、灯光。
2. **多媒体控制 (Media Control)**：上一首、下一首、暂停、播放、音量调节（针对本地/蓝牙音乐）。
3. **系统设置 (System Settings)**：调节屏幕亮度、连接蓝牙、切换驾驶模式（运动/舒适）。
4. **拨打电话 (Phone)**：呼叫通讯录中的联系人（通过蓝牙连接手机）。
5. **导航基础操作 (Navi Basic)**：取消导航、查看全览、回家/回公司（本存储的常用点）。
* *注：搜索新地点通常需要网络，但基础指令必须离线支持。*
挑战题 (50%)：架构与系统设计
Q4. “所见即所说” (Visible-to-Speak) 的实现方案
背景：用户希望不通过复杂的指令，直接读出屏幕上的按钮文字来触发点击。例如屏幕上有一个弹窗 “[同意] [拒绝]”，用户直接说“同意”。
题目：这涉及到 GUI 树与 NLU 的实时同步。请设计一个简要的数据流，说明当 UI 发生变化时，ASR/NLU 如何知道现在的热词是什么？
点击查看参考答案
**Hint**: 动态热词（Dynamic Hotwords）与 Accessibility 接口。
**参考架构流程**：
1. **UI 渲染层 (Android Framework)**：每当界面刷新（Activity/Fragment 变化），通过 Accessibility API 或自定义钩子，遍历当前的 View Tree。
2. **文本提取 (Text Extraction)**：提取所有 `clickable=true` 的控件的 `text` 或 `contentDescription` 属性（例如：“确认”、“取消”、“路线偏好”）。
3. **热词注册 (Hotword Registration)**：将提取到的文本列表（Context List）通过 IPC 推送给端侧的 ASR 引擎。
4. **ASR 偏好偏置 (Biasing)**：ASR 引擎动态提升这些词汇的识别权重。即使发音模糊，也优先匹配屏幕上的词。
5. **意图匹配**：当识别结果命中列表中的词时，NLU 输出特定的意图 `CLICK_ELEMENT`，携带参数 `target_text="确认"`。
6. **模拟点击**：系统层根据文字反查 View 坐标或 ID，执行模拟点击事件。
Q5. 多模态拒识 (Multimodal Rejection)
背景：车内有 4 个人在聊天，Agent 频繁被误唤醒（False Trigger）。
题目：利用视觉（摄像头）和声纹信息，设计一套严格的“唤醒校验”逻辑，以将误唤醒率降到最低。
要求：使用流程图逻辑描述。
点击查看参考答案
**逻辑程**：
1. **Stage 1: 音频唤醒 (KWS)** -> 检测到关键词 "Hey Agent"。
2. **Stage 2: 声源定位 (DOA)** -> 确定声音来自 `Zone_2` (副驾)。
3. **Stage 3: 视觉校验 (Visual Verification)**：
* 调用副驾摄像头。
* 检测副驾乘客是否有 **开口动作 (Lip Activity)**？
* 检测副驾乘客视线是否 **注视屏幕或仪表 (Gaze)**？（可选，视策略而定）。
* *Decision*：如果 KWS 触发但嘴巴没动（可能是广播声音），**立即丢弃**。
4. **Stage 4: 声纹校验 (VoicePrint)**（可选）：
* 提取声纹特征。
* 匹配是否为注册用户？或者是否为“非人类声音”（如合成语音）？
5. **Result**：只有通过所有校验，才点亮光圈，开始录音。
Q6. 极端场景下的 Handoff 设计
场景：车辆在高速公路上发生碰撞，气囊弹出。此时用户处于恐慌状态，语无伦次。
题目：设计此时 Agent 的行为模式（Emergency Mode）。它应该做么？不应该做什么？
点击查看参考答案
**策略设计**：
1. **触发条件**：从 CAN 总线接收到 `Airbag_Deployed` 信号 或 `G-Sensor` 剧烈碰撞信号。
2. **音频策略**：
* **立即静音**：关闭所有音乐、媒体播放。
* **最大音量**：将 TTS 音量调至最大（确保用户耳鸣时也能听见）。
* **全双工关闭**：此时不需要复杂的唤醒，直接进入监听模式或单向广播模式。
3. **主动行为**：
* **E-Call 自动触发**：倒计时 10 秒自动拨打救援电话（如果用户未取消）。
* **安抚交互**：TTS 播报：“检测到碰撞，正在为您连接救援中心。请保持冷静，报告车内人员受伤情况。”
* **解锁**：自动解锁车门，打开双闪，关闭高压电（EV车型）。
4. **禁忌 (Don'ts)**：
* 绝对禁止进行无关的对话（如“你需要听首歌放松一下吗？”）。
* 绝对禁止要求用户进行复杂的操作（如“请输入密码确认报警”）。
5. 常见陷阱与调试技巧 (Gotchas)
5.1 “幽灵刹车” 般的 “幽灵唤醒”
- 现象：车主在听广播，广播里的人说了一句类似唤醒词的话，或者歌词里有类似发音，Agent 突然跳出来说话，甚至执行指令。
- 调试技巧：
- AEC (回声消除) 穿透测试：播放高音量的 heavy metal 音乐，同时测试唤醒。AEC 必须能滤除 99% 的车机自身发出的声音。
- 置信度阈值动态调整：当车内分贝（dB）升高时，自动提高唤醒模型的置信度阈值（Threshold）。宁可拒识，不可误唤醒。
5.2 蓝牙连接后的“失语症”
- 现象：用户连接了手机蓝牙播放音乐。此时用户对车机说话，车机没反应，或者声音从手机听筒出来。
- 原因：音频通道（Audio Focus）被手机抢占，或者麦克风输入被路由到了 HFP (Hands-Free Profile) 用于通话，导致本地 ASR 拿不到数据。
- Fix：明确音频策略管理（Audio Policy Manager）。确保“语音助手”拥有最高的麦克风独占权或混音权，无论蓝牙状态如何。
5.3 隐私与数据合规的雷区
- 陷阱：为了调试方便，开发者记录了车内所有的原始音频和视频并在云端回放。
- 风险：这违反了 GDPR 和中国汽车数据安全法规（如《汽车数据安全管理若干规定》）。车内是私密空间。
- Rule of Thumb：
- 脱敏：上传云端的只能是提取后的特征（Features）或文本（Text），绝不能是原始人脸图像或原始音频（除非用户签署了极高等级的数据采集协议，通常仅限于测试车）。
- 座舱数据不出车：人脸识别、指纹识别必须在 TEE (可信执行环境) 中完成，只输出 Pass/Fail 结果。
5.4 延迟的“恐怖谷”
- 现象：用户说“打开车窗”，过了 3 秒窗户才动。用户会在这 3 秒内不仅感到困惑，还会重复指令，甚至手动去按按钮，导致系统随后执行多次。
- 标准：车控类指令的端到端延迟（TTS开始前或动作开始前）应控制在 800ms - 1s 以内。超过这个时间，用户体验将呈指数级下降。