车载Agent设计：先Job再模型与六步落地法

当行业热议将手机 Multi-agent 搬上车时，本文冷静指出：车规级芯片、安全冗余与 10 年生命周期等硬约束，决定了座舱 Agent 不能照搬手机逻辑。文章提出「先 Job，再模型」的 AI Native 设计路径，从身份、记忆、授权三件套到六步落地法，为产品经理提供了一份可操作的座舱个人 Agent 构建指南。

01 开篇：别把手机 Agent / Multi-agent 的热闹搬上车

最近和几个 Tier1 的智舱供应商聊过，他们都在盲目追 Multi-agent，甚至想在端侧模型里也上一套。这概念不是没有未来，但真正卡人的，是车这边的硬约束。

这半年座舱圈也确实热闹：千问上车红旗等车型、吉利推 Agent OS / Eva、比亚迪“迪迪虾”首搭腾势 N8L、火山引擎“豆包座舱助手”已经上车。

尽管行业这么热闹，很多人下意识还是那句：“把最近贼鸡儿火的 Muse / Dots / Grok Bot 那套搬到车机上不就完了？”或者“端侧再叠几个 Agent 角色，不就更聪明了？”

这个判断其实完全错了。车的设计理念和手机完全不同：车自始至终第一优先级都是保证用户驾驶前、中、后的人身安全，其次才是其他；手机更注重算力、续航、成本和每年一换的刷新速度。

更具体一点，比如车规级芯片和手机芯片的要求差得很远。车规级要过 AEC-Q100 应力测试：座舱芯片常见 Grade 2（−40～105℃）、Grade 3（−40～85℃），要求更高的才上 Grade 1（−40～125℃）甚至 Grade 0（−40～150℃）。涉及安全的还要按 ISO 26262 算账，ASIL D 的随机硬件失效目标不超过 10 FIT。手机芯片更看重峰值性能和功耗，验证走 JEDEC 那套方法，工作温度常见 0～70℃，设计寿命 3～5 年，坏了换机就行。

说白了：把手机方案或云侧 Multi-agent 热闹平移到车上，结果往往水土不服。不是模型不够聪明，是约束函数换了——断网、多音区、驾驶注意力、10～15 年生命周期、误执行的代价，全都不是手机那套假设。

所以我这篇文章的立场就一句话：

先 Job，再模型；先把“用户雇助手办什么事”钉死，再谈端云、全双工。

这是就是TM真正的 AI Native 体验 vs 传统体验的分水岭：传统是先功能清单再 AI 赋能；Native 是先 Job 与场景约束，再决定哪段用模型、哪段用规则。

不绕弯子，下面按“硬约束（物理六条 + 产品两条）→ 从零到一六步（第 0～5 步）→ 安全与落地顺序 → 交互前瞻”把座舱个人 Agent 梳一遍。先看总表，每步该干什么、该交什么。

表看完就往下翻——顺序是先约束、再交付物，别一上来就画架构图。

02 硬约束：为什么车上必须是 Agent，而不只是“语音助手”

车上真正卡死人的，我会拆成两层：六个物理硬约束（车端客观条件），再加两道产品约束。

2.1 六个物理硬约束

不爱看表也没关系。大白话就是：手机 Agent 默认你“坐着、有网、能看屏幕、错了能撤销”；车里默认你“握着方向盘、可能没网、不能盯屏、错了可能要命或至少要命的注意力”。六个物理硬约束不是吓你的清单，是产品需求的坐标系。

行业里对这条线其实已经说得很死：短期落地要把硬性安全规则写死在代码里，别交给模型；再往前一步，部署还需要一个独立于模型的强制执行层，在调任何车控前核对权限与车辆状态。你做产品时如果还在争论“要不要多给模型一点自由”，先把这两条贴在墙上。

2.2 两道产品约束

物理六条讲的是“车这台机器”；个人 Agent 真正难的，还有两道人 × 会话的约束：

第 7 条回答“为谁做事、记住什么、对谁说”；第 8 条回答“话说到一半被掐，事怎么办完”。全双工、双流式端到端再炫，这两条没定，还是语音遥控器。

物理六条 + 产品两条叠在一起：“听懂一句话”只是地板，“办完一件事且不搞砸、不对错人”才是天花板。

2.3 为什么是 Agent，不只是“多几个命令”

业界其实已经在往这条路上走：理想同学从“助手”到“智能体”；小鹏 Master Agent 拆任务调度垂直 Agent。但各家定义并不统一——所以咱们别把任何一家的架构图当成行业标准。

03 第 0 步：定 Job、划场景与 ODD

别一上来就画什么 Multi-Agent 大架构图。先问自己三句：

• 用户到底想要助手完成什么 Job？
• V1 圈多大？
• 什么条件下坚决不做？

3.1 四象限选场景

按“使用频次 × 语音比手动方便多少”把意图分进四个格子：

产出物：一张V1 做什么 / 不做什么清单。不做什么写清楚，比做什么更见产品勇气。

3.2 谁在车里

车里会说话的人不止车主：主驾（行车 / 停车）、副驾、后排 / 儿童、临时访客。这四类人决定了记忆作用域和授权档，V1 至少要写清哪几类人不在你的服务范围内。

3.3 ODD 初稿

ODD（Operational Design Domain，运行设计域）原来是自动驾驶的概念，放到 Agent 上同样适用，也最容易被忽视。做法很简单：先把 Agent 允许做什么、禁止做什么、越界怎么退写清楚，再谈模型。

04 第 1 步：个人 Agent 三件套——身份 / 记忆 / 授权

2026 年 8–9 月，Personal Agent 在消费端大爆发：Meta Muse、OpenAI Dots、Grok Bot……共同点是“云端有个自己的电脑 + 后台持续干活 + 敏感动作先问你”，长期记忆各家进度不一。我的想说的是：车是“端点”，不是“记忆的主人”。真正稀缺的不是再堆一个模型，而是身份–记忆–授权在车内外的可携带性。

4.1 为什么主打“个人 Agent”而不是“又一个座舱大模型”

To be honest大模型会越来越同质化；核心差别在“它是不是你的”：认不认得你、记不记得该记的、碰不碰不该碰的、跨手机和车时还是不是同一个人。Ford 的路径是 app 先行、2027 再进车；理想 2025 年就在家庭账号和对话历史上做了多端打通；拼图还没拼完——这恰恰是产品判断空间。

把 Muse 类能力搬上车时，我的排序是：

• 出行决策减负（接送、途经点、充电规划话术）
• 舱内身份连续（谁在说话、偏好是否串号）
• 敏感动作审批 UX（确认档、接管、审计）

4.2 身份：谁在说话

三类：车主、在车乘员、访客。“车内的人”≠“账号主人”。认错人要有兜底：声纹不确定就只答不做，别硬猜。

4.3 记忆：先分“四种记忆”，再叠作用域

座舱记忆常被糊成“长期 preference 一张表”。我把它拆成正交两轴：四种记忆（存什么、活多久）× 四个作用域（谁能看）。架构图里常写的“工作 / 会话 / 长期 / 车辆状态”是工程分层，不是记忆分类——别拿分层当类型，也别只用作用域冒充记忆类型。

4.3.1 四种记忆（层）

按产品侧的拆法，就固定这四类。

口诀：短期管这一步/这一趟话，长期管习惯，情景管“那一次”，Wiki 管“关于我的可编辑事实”。

4.3.2 四个作用域（谁能看）

作用域按“谁能看”分四层：

每条记忆最好带：来源、有效期、可见范围、是否可上云。再列 3 条“绝对不记 / 只在车里记”。

4.4 五档授权

行车时，部分档位自动降一档。

这套分档不是拍脑袋来的，和业界常见的 7 类决策（执行、拒绝、澄清、要求确认、要求人工接管、紧急响应、不调工具）基本对得上。原则只有一条：部署需要一个独立于模型的强制执行层。

05 第 2 步：能力图 · 场景闭环 · 回复（+ 主动服务边界）

5.1 能力图（Capability Graph）

先说明：这是我的归纳，不是业界标准名。节点 =原子能力/ 工具 / 第三方 Agent；边 = 依赖、互斥、替代、前置状态（车速 < X）、权限等级、ODD 可用性、延迟与可靠性。规划时只暴露“当前状态可用且被授权”的子图——工具集过大，Agent 会犯迷糊。

落到产品上：能力图管“现在能调什么”；下一节的元数据卡管“调的时候要命的细节”——两层缺一，规划要么选糊，要么给你调到西伯利亚去。

5.1.1 原子能力设计：不是车控 API 裸奔

很多方案把 SOA / 车控接口直接塞给模型，当“工具”。这在车上很危险：模型看到的是set_temp(24)，看不到“谁有权、车速允不允许、失败怎么回读、能不能撤销”。

原子能力 ≠ 车控 API 裸奔。它是包了一层产品语义的可调用单元：入参出参清晰，挂着 ODD、权限、可逆性、确认等级、失败码和读回字段。规划器看见的是“带说明书的积木”，不是“裸函数指针”——这也是“能力层与模型解耦、元数据给决策层消费”的具体落点。

和能力图的关系（别混）：

• 节点= 一张原子能力卡（模板见下）
• 边= 依赖 / 互斥 / 前置状态（例：开窗依赖车速限幅；导航回家依赖家地址已设）
• 运行时：先按车速 / 挡位 / 身份 / 网络裁一版可用子图，再让规划选工具——这就是“工具集可裁剪”在座舱的落地

原子能力卡模板

三张示例卡（模板，不是实车数据）

①climate.set_temp（调空调目标温度）

②window.open（开车窗）

③nav.goto_home（导航回家）

设计原则（写进方案，别只放附录）

• 先读状态再调（SFC）：没读挡位 / 车速 / 童锁就调，等于闭着眼睛动车控。
• 工具集可裁剪子图：同一句“开窗”，高速子图里可能只剩“开缝”节点；规划看不见“全开”，比事后靠模型自觉靠谱。
• 失败可回收：每个失败码都要有下一步（重试 / 限幅 / 改提议 / 硬拒绝），这也是工具设计里最朴素的常识——座舱版就是失败码表 + NLG 指针。
• 危险动作永不静默执行：确认等级写进卡，强制层按卡拦；模型再自信也不能跳过。
• 和中断可恢复对齐：长耗时能力（导航算路、媒体登录）要声明打断后默认取消 / 挂起 / 续跑哪一态；高风险被打断 → 默认取消或转确认。

5.2 场景闭环：触发 → 感知 → 执行 → 反馈

把“条件 / 动作 / 参数 / 异常”做成用户能用自然语言创建、工程能稳定执行的编排层。

示例闭环

场景名示例：“下班上车 → 自动调温 + 播路况摘要”

5.3 NLG：三类意图怎么回（按评测口径倒推）

能力、场景都定了，最后都要落到“怎么回话”。NLG（Natural Language Generation，说白了就是助手怎么把结果说出口）这块，产品经理最容易只顾着讲怎么执行，忽略怎么回复。我把回复拆成三种最常见的意图形态——单句模糊、多意图全标准、标准 + 模糊，正好覆盖评测里最常考的模糊意图、复杂 / 多意图和两者的混合。

横切原则就一句：先报做成了什么，再报卡在什么；能静默就不废话；冲突时说明“听谁的”。下面按这三种形态拆开讲。

5.3.1 单句模糊

5.3.2 多意图全标准

5.3.3 标准 + 模糊

横切：失败兜底公式就记：原因 + 已成功项 + 下一步。“音乐暂时打不开，因为账号未登录；空调已调到 24 度。需要我打开登录页吗？”

音色 / 语气压短说：成功短而稳；追问轻、可打断；失败平静说明，不卖萌遮丑；后排娱乐可稍活泼，驾驶相关保持克制。

5.4 主动服务：别做“脑残的主动”

有同行批评过“一上车就报天气”这类“脑残的主动”，真正有用的主动得靠时间线预测和触发条件（类似 heartbeat / loop 的机制）。落到产品就是：

• 主动环默认只读提议，不直接执行高风险动作；
• 提议要带“为什么是现在”——否则用户觉得烦人；
• 取消与降敏必须好点，取消要写回策略（下次降低触发强度）。

06 第 3 步：架构——分环 / 端云

6.1 先把“图”和“环”的态度说清

Loop engineering / Graph engineering 这套词最近在编程 Agent 圈很火，但没有统一标准定义。我这里借用它们，只为说清三件事：

• 座舱要分频：安全环不能等 LLM；
• 座舱要显式状态与失败路由：失败后去哪、何时找人；
• 座舱要能力 / 场景 / 人-记忆三张图分开维护，别糊成一张“知识图谱”大饼。

6.2 产品架构：六层分层

我先把产品切分钉死：六层从上到下——交互 → 感知 → 认知 → 决策 → 能力 → 基础。

核心原则：上层可以换（模型、供应商、交互壳），下层尽量复用（车控原子能力、SOA、鉴权）；别跨层穿透——认知层别直接拧信号，能力层别偷偷调云模型。

落点就一条：能力层与模型解耦——换模型 / 换供应商，车控能力不跟着破碎。

交互层（最上）

装什么： – 多模态入口：语音为主，屏、方向盘按键、可选手势为辅 – 多模态出口：TTS、卡片、短提示音；行车少字、停车可稍闲 – 会话状态可见：正在听 / 正在办 / 等待确认 / 已打断——别让用户猜“它死没死” – 可打断：全双工接入点在这里（嘴），脑在决策 / 能力层 – 角色感知的话术档：主驾简报 vs 后排娱乐，别一套嗓子通吃

感知层

装什么： – 语音前端：多音区、AEC（回声消除）、降噪、声源定位 – ASR：端侧优先短指令；云增强长句 / 噪声差场景（可降级） – 身份线索：声纹、账号、座位占用 – 车身 / 环境：车速、挡位、门锁、空调、导航主动线 – 乘员状态：DMS / OMS（注意力、儿童在场）——喂给授权与主动服务边界

认知层

装什么： – 意图路由三档：极快（向量 / 规则命中）/快（端侧 Omni 或 ASR+NLU）/慢（云端长推理）——分流比例按自己 Job 集标定，别抄别人海报占比 – 上下文：本轮槽位、上一轮未完成项、音区归属 – 记忆读写接口：短期 / 长期 / 情景 / 个人 Wiki 四种记忆，认知层只读“策略允许的” – 轻量 RAG：车主手册、本车功能说明——别把整本百科塞进端侧 – 拒识与域外：不是对助手说的、超能力图的，早退

决策层

装什么： – 任务规划与分解：多步 Job 拆成原子能力序列 – 工具选择：只看见“当前身份 × ODD”下的可用子图 – 冲突仲裁：音区争抢、同资源互斥、安全 vs 舒适 – 澄清策略：何时追问、何时限幅执行、何时改提议 – 何时不该 Multi-agent（呼应开篇）：短车控、单域标准指令、断网核心路径——别为了“显得智能”硬拆角色；真要拆，也是瘦路由 + 可控垂直能力，不是端侧群聊

能力层

装什么： – 原子能力注册表 + 元数据卡（确认等级、可逆性、ODD、权限、回读……见 5.1.1） – 编排：串行 / 有限并行、中间态、取消点 – 回读与回滚：调完读真实状态；可逆则提供撤销钩子 – 外部能力：导航、媒体、MCP、A2A（Agent 间协作协议）、GUI 兜底——同样挂元数据，别裸调 – 失败码表：给决策层 / NLG 可解释的原因，不丢黑盒异常

基础层（最下）

装什么： – 车内 SOA / 信号与服务发现 – 端云通信：弱网策略、超时、重试、证书 – 鉴权与审计：谁调了什么、是否越权——可回放 – 埋点与评测回流：意图维、确认档、打断三态 – OTA、配置开关、灰度 – 监控与告警：端侧健康、云侧配额、安全环命中率

一次请求怎么走：六层 → 一条链路

六层是货架，摆的是职责；真跑起来，一次请求是这么走的：

端云怎么分

六层和这张图怎么对上

• 货架 vs 路径：交互 / 感知在上段；认知 ≈ 理解路由；决策 ≈ 规划；能力 ≈ 工具；基础托底（图里不单独成框——它不跑每一次请求的热路径，但断了上面全瘫）。
• 中间虚线是记忆：规划要读四类记忆，外加车辆实时状态——“回家”指向谁的家。
• 护栏是独立竖条：安全环不过 LLM；强制层按原子能力卡 + ODD 裁决。
• 最底下箭头指回感知：全双工打断不是只掐 TTS，要回到“还能不能继续办事”——取消 / 挂起 / 续跑。

复杂任务先路由再专项、工具失败可回收——映射到座舱就是快路径别进重规划，重规划别堵死语音线程。

6.3 走通一句口语：从识音到回读

纸上分层看完，最好拿一句真实口语走一遍——不是再贴一张抽象漏斗图，而是把端 / 云 / 规则标在每一步上。选这条组合句（模糊 + 标准；故意不用“有点闷”单句体感故事，改成空调 + 导航确认）：

主驾：“有点冷，顺便导航回家。”

假设：车主声纹、行车中、网络尚可、家地址已设、空调可离线。

可选时序（同一 Job，压短版）：

6.4 座舱分环（Multi-rate Cockpit Loop）

座舱 loop 不是一个 while，而是不同频率、不同信任等级的几个环嵌套。

6.5 端云分工：端侧 PM 真正负责什么

端侧 PM 负责的不是“去训一个 7B”，而是：

• 能力边界：哪些意图必须离线可完成
• 时延预算：首响 / 打断 / 端到端
• 弱网降级话术与行为：断网时做什么、不做什么
• 与 ASR / TTS / Tool 的接口验收
• 安全默认：无网也不能乱执行车控

6.6 把“端到端双流”嵌进架构，而不是贴海报

端到端双流（产品理解）：语音进来、语音出去，中间不再死磕“ASR→大模型→TTS”三段硬串；用户音频流与助手音频流并行——这是全双工在模型形态上的说法。行业里“豆包座舱助手”提过双流式全双工；开源侧 Moshi 常被当作实时全双工 spoken LLM 的参照。

架构上怎么嵌：

• 语音层：可以走双流 / Live 形态，保打断与自然度；
• 办事大脑：（Tool、长推理、车控）仍走可控 Agent + 护栏，异步委托，别和语音线程死锁；
• 弱网时语音层可回落端侧短指令，大脑超时进降级阶梯。

这和 GPT-Live“听+说一体、复杂办事委派后端”是同一类拆法——只是办公电话场景换成了座舱。

07 第 4 步：降级与失败兜底

这一步是把第 0 步的 ODD 小表，落进“执行中途出了事怎么办”。核心就一句：能办 ≠ 全程按原计划办完；车上一半“聪明”其实来自降级策略，不是来自更大模型。手机上的 Agent 失败了可以重来一次，车上的 Agent 往往没有第二次机会。

有研究结论支持这一点：多步任务里“边做边说规划 + 中间结果”，主观速度感和信任更好——但建议随可靠性建立逐步少话痨。

7.1 降级阶梯

方法口诀：先判 ODD，再选阶梯，再选 NLG——模型可以建议阶梯，最终强制层必须是规则。

7.2 失败六层：各给一句车载例子

公式：原因 + 已成功项 + 下一步建议例：“导航失败，因为家地址未设置；空调已按偏好打开。需要我现在设置家地址吗？”部分成功 > 沉默失败；可解释 > 卖萌遮丑。