基于 Amazon Bedrock AgentCore 构建智能座舱语音助手

摘要：绍基于 Amazon Bedrock AgentCore 的智能座舱语音助手方案，采用云端意图编排与边缘车机执行的协同架构，实现多意图理解、车控安全校验及 GUI 人在回路等能力。

01一、前言

02二、背景与挑战

03三、方案概述

04四、方案架构

05五、关键实现

06六、能力与效果示意

07七、落地注意点

08八、小结

09九、关于伙伴

一、前言

智能网联汽车的座舱语音，正在从「打开空调」这类单轮指令，走向「有点热，顺便导航去吃饭，再放部电影」这样的复合口语。本文介绍一套基于 Amazon Bedrock AgentCore 的边缘—云端协同方案：在云端完成多意图理解与工具编排，在车机侧安全执行车控、导航与 GUI 操作，并通过 SSE 流式回传，让驾驶员用一句话完成多任务协同。

本方案主要介绍如下内容：

为何要把多意图编排放在云端 Agent，而把实际环境执行留在车机；
一次复合语音请求的端到端数据流（鉴权 → 分类 → 编排 → 边缘执行 → 流式反馈）；
车控白名单、GUI 人在回路（截图中断—续跑）如何划清信任边界；
如何用 Amazon Bedrock AgentCore Runtime、Memory 与观测能力支撑可扩展交付。

二、背景与挑战

新能源与智能网联车普及后，座舱交互从命令式单轮控制升级为对话式多任务协同。传统车载语音助手常见三类痛点：

只能识别固定指令，难以理解复合与口语化表达，例如「有点热顺便找个地方吃饭再放首歌」；
车控、导航、车机应用（视频 / 电商等）分属不同子系统，缺少统一的智能编排入口；
端侧算力与模型能力有限，难以稳定承载大模型推理，同时要兼顾账号、隐私与功能安全。

因此，我们采用「边缘车机负责感知、执行与安全闭环；云端 Amazon Bedrock AgentCore 负责意图理解、多意图拆分与工具编排」的分工：云端做聪明的编排，车机做可控的动作。

三、方案概述

典型控制指令：「打开空调到 22 度，导航到最近的加油站，再打开爱奇艺放一部电影。」系统在云端完成意图理解与任务编排，边缘车机分别执行车控、地图导航与车机 App 自动化，全程语音播报、SSE 流式响应。

一次请求的处理步骤如下

语音输入与鉴权：车机完成语音前端（VAD / 降噪等）与 ASR 转写后，通过 Amazon Cognito 获取 JWT，以 Bearer Token 调用 Amazon API Gateway 或 AgentCore Runtime 的 POST /invocations，并携带会话 ID（X-Amzn-Bedrock-AgentCore-Runtime-Session-Id）。TTS 仍在车机侧播报。
多意图分类：云端 Agent 使用 Amazon Bedrock 基础模型，将复合请求拆分为有序的 navigation（导航）/ chat（车控与问答）/ gui（车机应用操作）子意图，并识别「先…再…」等顺序词排序。
任务编排与执行：非 GUI 意图并发执行；GUI 意图串行执行（依赖端侧截图回传）。编排采用 model + tools + system prompt，由大模型在 tool-calling 循环中决定调用。
边缘执行：车控经白名单与数值域校验后，以 data-vehicle-control 事件下发；导航结果以结构化 POI / 路线下发；GUI 以 data-interrupt 请求端侧截图并执行点击 / 滑动 / 输入，结果回传后云端续跑（人在回路的中断—续跑）。
流式响应与记忆：全过程通过 SSE（text/event-stream）逐 token 返回；短期会话与长期偏好写入 Amazon Bedrock AgentCore Memory，检索摘要注入 system prompt，用于个性化（如习惯温度、常去地点）。

四、方案架构

整体为「边缘车机 + 亚马逊云科技云端」分层协同。云端侧以 Amazon Bedrock AgentCore Runtime 承载自定义编排服务；边缘侧负责语音前端、本地决策与物理执行。

4.1 云端：接入、编排与模型

接入与鉴权：Amazon Cognito 签发 JWT；Amazon API Gateway HTTP API 或 AgentCore Runtime 入站 JWT Authorizer 校验令牌，会话与用户绑定，执行角色遵循最小权限。
智能编排：以容器形式部署在 AgentCore Runtime 上的 FastAPI 服务（提供 POST /invocations 与 GET /ping），内含意图路由器与 chat / navigation / gui 三类编排器。
模型与记忆：Amazon Bedrock 基础模型负责意图理解与生成；AgentCore Memory 提供短期会话与长期偏好。演示环境中还按需挂载了 AgentCore 受管工具能力，主路径的车机 GUI 仍以端侧截图中断—续跑为准，避免云端直接操控车内不安全界面。
观测：Amazon CloudWatch Logs 采集运行日志与 TTFT（首 token 时延）等指标，并配合记忆 TTL / 压缩 / 用户级清除等运维脚本。

[图 1 – 云端架构示意：鉴权接入、多意图路由、编排器、Memory 与 SSE 回传车机]

4.2 边缘：车机分层与本地决策

车机侧从硬件、HAL、语音前端到应用层分层清晰。决策模块可对简单车控走本地解析，复杂或多意图请求再上云，从而在弱网或低时延场景保留降级路径。语音链路在端侧完成采集、前端处理、ASR 与 TTS；云端主要接收文本意图并回传结构化事件。

[图 2 – 边缘车机分层架构：语音前端、本地 SLM / 决策、车控与导航执行、云客户端]

4.3 数据流（复合请求）

车机(语音→文本) --Bearer JWT--> API Gateway / AgentCore Runtime
  → 鉴权 + 会话绑定 → 多意图分类(Amazon Bedrock)
  → [chat 车控] 并发  ┐
  → [navigation] 并发 ┤→ 按序 SSE 流式回传
  → [gui 车机 App] 串行┘  (data-interrupt ↔ 端侧截图，人在回路)
  → AgentCore Memory 存取(短期会话 / 长期偏好)
车机解析 SSE(text-delta / data-vehicle-control / data-interrupt) → 执行 + TTS

五、关键实现

5.1 多意图并发与 GUI 串行编排

入口在 POST /invocations：先分类意图，再对非 GUI 并发、对 GUI 串行，最后以 SSE 结束标记收尾。示意如下（节选）：

intents = classify_intents(user_text)  # navigation / chat / gui
non_gui = [i for i in intents if i.type != 'gui']
gui     = [i for i in intents if i.type == 'gui']

# 非 GUI 并发（同步 generator 放入线程池，避免阻塞事件循环）
results = await asyncio.gather(*[
    _run_sync_intent_in_thread(make_stream(i)) for i in non_gui
], return_exceptions=True)
for r in results:
    for chunk in r:
        yield chunk

# GUI 串行（依赖端侧截图的中断—续跑）
for i in gui:
    async for chunk in gui_runtime.run_stream_async(...):
        yield chunk
yield 'data: [DONE]\n\n'

5.2 基于 Amazon Bedrock 的多意图分类

分类器通过 Converse API 调用基础模型，温度设为 0 以提高稳定性，再按行解析为「类型|子句」，并按顺序词重排：

resp = client.converse(
    modelId=CHAT_MODEL_ID,
    system=[{'text': MULTI_INTENT_SYSTEM_PROMPT}],
    messages=[{'role': 'user', 'content': [{'text': user_text}]}],
    inferenceConfig={'maxTokens': 300, 'temperature': 0.0},
)
# 输出按行解析为 <类型>|<子句>，并按「先…再…」顺序词重排

5.3 车控白名单与数值域校验

云端只下发结构化车控事件，不直接触碰 CAN 总线。设备与动作走白名单，温度、风量、音量等做数值域校验，非法指令拒绝并澄清：

DEVICE_ACTIONS = {
    'air_conditioning': {'on', 'off', 'decrease', 'increase',
                        'set_temperature', 'set_fan_speed', ...},
    'windows': {'open', 'close'},
    'volume':  {'up', 'down', 'set'},
    'music':   {'play', 'pause', 'next', 'previous'},
}
# 数值域：温度 16–30 / 风量 1–7 / 音量 0–100
# 校验通过后以 data-vehicle-control 事件下发车机

事件顺序与接口契约对齐：data-vehicle-control → data-routing-state(delegated) → 文本流 → [DONE]。

六、能力与效果示意

6.1 自然语言多意图理解与协同编排

一句话同时包含车控、导航、车机应用时，系统拆成有序子任务：非 GUI 并发、GUI 串行，按语义顺序执行并流式反馈。

示例输入：「打开空调温度设置 22 度，导航到南京南站」
语音结果：打开空调温度设置 22 度 → navigation｜导航到南京南站 → gui｜打开高德地图

[图 3 – 识别到连续语音中的多指令，并完成车控意图和导航意图拆分]

[图 4 – 通过 GUI Agent 拉起高德地图 APP，开始导航]

6.2 安全可控的车辆控制与个性化

空调 / 车窗 / 音量 / 音乐等走白名单与数值域校验；结合 AgentCore Memory，可在对话中引用用户习惯（例如偏好较凉的温度与低风量）并主动确认，而不是静默改写车控。

[图 5 – 结合长期偏好的主动确认示意（提示信息由 AI 生成，需用户确认后再执行车控）]

6.3 车机应用 GUI Agent（人在回路）

对第三方电商应用等车机 App，云端通过 data-interrupt 请求端侧回传屏幕截图，结合视觉理解决策 tap / click / swipe / input 等动作；端侧执行后回传结果，云端续跑直至完成。全过程可中断、可观测，并与 Edge-Cloud API 契约对齐。

[图 6 – 开发车机上的电商 APP]

[图 7 – GUI Agent 执行：点击和输入操作]

[图 8 – GUI 操作完成回传：任务结束并提示完成意图]

七、落地注意点

区域与合规：运行区域已开通所需 Bedrock 模型与 AgentCore 能力；跨区域推理要单独评估时延、成本与数据出境。
安全边界：车控必须白名单 + 数值域 + 端侧二次校验；涉及行驶安全的动作（如车门、驾驶模式）应默认拒绝或仅本地高可信路径。
GUI 自动化：优先人在回路；对支付、账号登录等敏感页设置硬拦截，避免 Agent 误触。
体验指标：建议在联调中公布 TTFT P50 / P95、复合意图端到端耗时与失败重试率，用数据替代「延迟低」等定性描述。
可复现交付：固定模型 ID、提示词版本、接口契约与样例话术集，便于车厂 / Tier-1 回归。

八、小结

本方案用 Amazon Cognito、Amazon API Gateway、Amazon Bedrock 与 Amazon Bedrock AgentCore（Runtime + Memory）搭起云端多意图 Agent，用车机侧白名单执行与 GUI 中断—续跑守住安全边界，使驾驶员能够用自然语言一次完成车控、导航与车机应用协同。下一步可将观测指标固化进发布门禁，并按中国区服务清单裁剪模型与区域配置。

九、关于伙伴

软通动力信息技术（集团）股份有限公司是亚马逊云科技合作伙伴，在汽车智能网联与大模型应用交付方面有实践经验。本方案由其基于 Amazon Bedrock AgentCore 完成边缘—云端协同的架构、研发与联调验证。

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客