过去几年，智能座舱的交互方式一直在快速迭代。大模型出现之前的固定指令方案，能做的事情有限，效果往往不够理想。引入大模型后，自然语言理解和多轮对话的能力上限大幅提升，但如何把数百个座舱信号有效地组织起来、让智能体真正可用，行业仍然没有标准答案。

本文是 EMQ 在这条路上的一次工程实践探索——讨论如何用多智能体协作的方式，支撑起大量原子能力的智能体开发与运行。

座舱智能体开发的挑战

原子能力多，Agent 开发吃力

一个典型的中高端新能源车型，可控制或可查询的信号点覆盖空调、座椅、车窗、天窗、氛围灯、HUD、导航、媒体、驾驶模式、ADAS、充电管理等功能域，数量在数百到上千。如果试图将所有能力装进一个 Agent，实际运行中会出现几个问题：

一款中高端新能源车型，能控制或查询的信号点分布在空调、座椅、车窗、天窗、氛围灯、HUD、导航、媒体、驾驶模式、ADAS、充电管理等功能域，数量从几百到上千。要把这些全塞进一个 Agent，实际跑起来有几个问题：

• 构建 Agent 的过程比较麻烦，除了本身的代码，需要花费大量时间和精力对接各种车端的服务。
• Agent 工具列表太长，大模型每一步推理都需要从一堆工具里挑，选项一多就容易出错。
• 每次推理的上下文都需要携带全部工具定义，token 消耗大，推理延迟高。
• 修改或新增任何功能域，都可能影响其他功能域的行为稳定性。

拆成多个 Agent，协作成为新难题

按职能拆分为多个 Agent 似乎是直接的解法，但拆分之后新问题随之而来。

空调 Agent 和车窗 Agent 如何协作处理「开窗后自动调节空调」？导航 Agent 和充电管理 Agent 如何共同完成「沿途充电规划」？

• Agent 之间缺乏标准化的通信协议。要么硬编码联动逻辑，难以维护；要么引入中央调度器，又走回单体的老路。
• 协作的时序、依赖、冲突都需要额外的机制去处理，「各自处理完再汇总」根本走不通。
• 没有统一的编排视图，用户和开发人员都看不清跨 Agent 的调用链路。

供应商多，集成协调成本高

座舱能力来自多家供应商：空调控制是 Tier 1，导航是地图服务商，语音识别是语音技术商，媒体内容是互联网服务商。每家都有自己的接口规范、数据格式和交付节奏。跨供应商对齐接口、联调测试、排查问题，这些事情占掉了大量项目时间。改一个联动逻辑，经常要多家供应商同步排期，变更周期要以月为单位。

Agent 开发不够灵活

座舱的联动逻辑是持续演进的。今天新增一个「露营模式」，明天调整「下班回家」的协作流程，后天为某个车型增加定制场景。传统模式下，每增加一个场景，都要完整走一遍开发、测试、发布、OTA 的流程。缺乏运行时编排能力，场景扩展严重依赖整车软件发版节奏，无法灵活响应需求变化。

EMQ Device Agent 方案：多智能体协作架构

Device Agent 是什么

Device Agent 是一个 AI 设备智能体平台。它的核心思路是：用自然语言定义设备能力，按职能拆分为多个智能体，再通过协议让这些智能体自主协作。运行时的核心是一个 Harness 架构——事件驱动的运行时容器，而非固定执行流程的 Workflow 引擎。这个架构在车端带来几个关键能力：

• 多入口并行接入：语音、中控屏、方向盘按键、手机 App 可以同时与不同的 Agent 交互，互不阻塞。
• Agent 热插拔：新增或更新一个 Agent 无需重启运行时，OTA 下发配置后即时生效。
• 离线/在线无缝切换：网络断开时自动降级为车端推理，恢复后自动切回。

这些能力是座舱场景的刚需。语音交互不能等待网络、新增场景不能等待整车固件升级、地库和隧道不能停摆——Harness 架构从一开始就在为此设计。

自然语言快速开发 Agent

Agent 的创建不依赖手写代码。开发者用自然语言把 Agent 的能力范围说清楚，系统自动生成结构化的 Agent 规格和代码框架。例如，描述一个空调 Agent：

创建一个空调 Agent，支持温度设置（16-32°C）、风量调节（1-7 档）、模式切换（吹脸/吹脚/除雾）、分区控制（主驾/副驾/后排）。上报当前温度、目标温度、风量、模式。当温度超过设定值 3°C 时触发告警。

系统通过解析这段描述，自动生成 Agent 规格——包含命令参数、遥测字段和事件定义。开发人员确认后，Agent 就能在运行时中直接创建并启用。

按职能拆分多 Agent

有了 Device Agent 之后，就可以快速生成各种智能体。将座舱能力按职能拆分为多个独立 Agent，每个 Agent 管理一个明确的能力域。Agent 的类型划分可以参考 VSS（Vehicle Signal Specification）等行业标准的信号分类，也可以由车企根据自身功能域和供应商情况自行决定。常见的划分方式包括：

• 空调 · 微气候：温度、风量、模式切换、分区控制、座椅加热和通风。
• 车身控制：车窗、天窗、门锁、尾门、充电口、雨刮、后视镜。
• 导航 · 行程：GPS 定位、导航规划、电池电量、续航估算、充电站推荐、驾驶模式切换。
• 座舱体验 ：座椅位置、氛围灯、天窗遮阳帘、场景模式（迎宾/休息/露营）。
• 信息娱乐：媒体播放、音量调节、均衡器、音区控制、HUD、仪表盘设置。
• 安全· 辅助：ACC 设定、车道保持、自动泊车、胎压监测等。

这种拆分方式的好处在于：每个 Agent 的工具数量控制在 15-30 个，大模型推理上下文精简，工具选择准确率提升，推理速度更快，token 成本更低。各供应商负责各自的 Agent（Tier 1 负责空调 Agent，地图商负责导航 Agent），职责边界清晰，开发互不干扰。一个 Agent 的升级不影响其他 Agent，可以独立迭代。

Agent 内部的工作流编排

Agent 的命令定义了它可以执行什么操作，但实际业务中往往需要按顺序执行多个命令，并在中间加入条件判断——这就是工作流。

Device Agent 支持为单个 Agent 定义内部工作流，把多个命令编排成有序步骤，用自然语言描述条件和动作规则。以导航 · 行程 Agent 的「低电量充电推荐」工作流为例：

当电池电量低于 20% 时：

1. 查询最近的充电站及其距离
2. 判断剩余续航是否能到达最近的充电站
3. 如果能到达，规划导航路线，切换空调到节能模式以延长续航，并在中控屏弹出充电提示
4. 如果不能到达，建议用户靠边停车并呼叫道路救援

「当车辆到达充电站后，自动打开充电口盖板」这个工作流涉及查询、判断、导航、空调控制、屏幕显示、车身控制等多个步骤，但全部定义在导航 · 行程 Agent 内部。开发人员用自然语言描述上述流程，系统将其转换为一组有序的步骤——每个步骤的输入、输出、条件分支和依赖关系。

传统模式下，需要工程师编写代码实现每个步骤的逻辑（查询充电桩 API + 距离计算 + 分支判断 + 各系统对接），涉及多个团队联调。

工作流模式下，产品经理用自然语言描述完整流程，系统自动生成可执行的工作流定义，分钟级完成编辑，小时级完成验证和下发。当流程需要调整时（比如修改「低电量」的阈值或更换充电站推荐策略），只需修改工作流描述，不需要修改代码。

如果业务流程涉及多个 Agent 之间的协作，则由下一节介绍的编排能力处理。

A2A over MQTT

Agent 之间的协作基于 A2A（Agent-to-Agent）协议，使用 MQTT 作为传输层。

• Agent 注册与发现：每个 Agent 上线时向 A2A Registry 注册自身能力，其他 Agent 可以动态发现并与之通信
• 异步消息通信：Agent 之间通过 MQTT 消息进行请求和响应。空调 Agent 需要查询电量和行程规划时，向对应的 Agent 发送消息，无需同步等待。MQTT 的发布-订阅模型天然支持一对多广播——一个 Agent 发布的事件（如：打开车门）可以同时通知多个订阅 Agent
• 编排结果可视化：当用户发起一个跨 Agent 请求时，AI 编排出的 Agent 调用顺序以 DAG 图形式呈现。用户可以看到请求被分解为哪些步骤、每个步骤由哪个 Agent 执行、步骤之间的依赖关系。可追溯、可验证。

跨 Agent 的协作模式

跨 Agent 的编排支持两种工作方式，分别对应不同的使用场景：

编排模式（Orchestration Mode）：预定义的跨 Agent 协作流程，适合固定的高频场景。

以「露营模式」为例：

用户说「开启露营模式」：

1. 车身控制：关闭所有车窗，锁车门，关闭天窗遮阳帘
2. 空调 · 微气候：切换到外循环，温度设为 22°C，开启座椅通风
3. 座舱体验：氛围灯切换到暖色调，亮度调低至 30%
4. 信息娱乐：播放预设的露营歌单，切换仪表盘显示到户外模式

四个步骤预先编排好，执行时按固定流程运行。每个步骤的 Agent 和参数都是确定的，可测试、可回滚，适合安全相关的场景。编排结果以 DAG 图展示完整的调用链路。

任务模式（Task Mode）：由大模型实时规划 Agent 的调用顺序，适合开放性的临时请求。

以用户说「我有点累了」为例：大模型分析后判断这是一个需要缓解疲劳的多步响应，动态规划：

1. 空调 · 微气候：调低温度到 20°C，开启座椅通风
2. 座舱体验：调节座椅到休息位置
3. 信息娱乐：播放提神的音乐，适当降低音量
4. 导航·行程：如果导航中，建议途经服务区休息

每个请求的规划结果不同。如果是冬天说「有点累了」，可能不会调低温度而是调高并开启座椅加热。这种模式灵活覆盖长尾需求，但相比编排模式有额外的推理延迟。两种模式可以共存。固定场景走编排模式保证准确性，临时请求走任务模式保持灵活性。

部署方式

Device Agent 支持灵活的部署方式，车企可以根据量产阶段和网络条件灵活选择。

云端部署

将所有 Agent 运行在云端服务器上，车机通过 T-Box 与云端 Agent 交互。它的优势是不占用车端算力、可以调用云端大模型处理复杂推理，缺点是对网络质量依赖强、时延较高、不支持离线场景，适合概念验证阶段或需要大模型深度推理的特定请求。

车端部署

将 Agent 运行时直接部署在座舱域控制器或车机 SoC 上。安装包仅 45MB，运行时内存约 250MB，无需独立 AI 芯片即可运行。由于数据在车机本地流转，响应在毫秒级；如果配置了车端的大模型，可以实现车内数据不出车，满足安全合规要求；车辆在地库、隧道或偏远地区无网络时，Agent 仍可正常工作。这是量产高端车型的主要部署方式。

结语

座舱智能化的演进方向，是从一个「什么都能做」的单体助手，转向一组各司其职、协同工作的智能体网络。Device Agent 在这个方向上的选择是明确的：不是简单地在车机上接入一个大模型对话界面，而是重新思考座舱智能体的组织方式。

这套方案在实际落地中体现出几个明确的优势：

• 开发效率：用自然语言描述 Agent，在线模拟器调试，OTA 分钟级下发，从需求到上车的周期从月级压缩到天级。
• 准确执行：编排模式按预定义流程执行，可测试、可回滚，编排结果以 DAG 图展示完整的调用链路，开发者可以直观审查每一步的 Agent 调用。
• 灵活协作：Agent 之间通过 A2A over MQTT 标准化通信，松耦合、异步、可独立演进，新增或替换一个 Agent 不影响其他 Agent，第三方能力也可以方便地加入协作网络。
• 组织效率：各供应商负责各自的 Agent，职责边界清晰，不再需要一个中央团队维护所有的联动代码，部门间的协调成本大幅降低。

这套架构在车端落地的独特之处在于：轻量化部署使得整个运行时可以直接运行在现有座舱 SoC 上，无需额外 AI 芯片。这不是一个需要等待下一代硬件才能落地的方案——它在今天已经是可行的。