智能座舱Agent架构升级项目

在项目初期，我们需要先弄明白“用户会说什么？”“用户真正想要什么？”“有什么场景是值得做的？”

我们结合线上用户表达数据、关键词归纳分析，以及访谈和问卷等方式，持续整理高频需求和典型表达模式，从中识别出了温度舒适、氛围营造等一批高价值的车内场景。

接下来，我们进一步梳理和定义了 13 个核心场景的体验目标与能力边界。对于每个场景，我们都可以拆出来：用户一般会这么说，希望系统达到什么样的策略效果，需要接入哪些Function 能力，需要接入哪些context情境信息、memory记忆偏好，以及Prompt设计上需要注意什么。

以温度舒适场景为例，用户一句“我好冷”并不只是触发某个固定功能，而是需要结合车内当前温度、风速状态、车外环境以及用户习惯温度，综合决定是否调高空调温度、降低风速、开启座椅加热，或者调整其他相关能力。

通过这一步，原本比较抽象的“让 NOMI 更智能”转化成了一套更可落地的场景配置框架。这个框架后续不仅用于前期方案设计，也成为后续链路推进、评测验收和版本迭代的重要基础。对我来说，这一阶段最重要的不是定义了多少场景，而是逐步把“用户意图—情境信息—function call范围—响应策略”之间的关系结构化了。

原有的One Step老链路使用Qwen3-8B的基座模型，更偏向单步策略选择，对复杂情境、多轮信息和多样化策略支持有限；

新链路中我们采用使用Qwen3-32B作为基座模型，并结合业务场景通过 SFT 与 LoRA 进行微调训练，希望让模型在云端实时结合用户表达（query）、车辆状态（context）、用户偏好（memory）和可调用车控工具列表（tool list），完成更为智能的意图理解、推理和规划。

训练数据构建：

训练数据主要分为两类：一类是面向车控通用能力的训练数据，整体规模超过 10W条，用于保持模型基础车控工具调用能力；另一类是围绕核心场景沉淀的高质量数据集，原始构造1.5W条，基于规则和人工review过滤后得到1.2W条，用于强化模型在重点体验场景中的理解与决策能力。

训练数据构建过程中，产品侧明确结构化的要素如下：核心场景、query、context和memory变量、 tool边界。我们将多样化的上下文信息告诉Claude4-sonnet，让它推理得出意图，再通过原有模型将意图“翻译”成对应的车控工具。

实践的过程中，用户的表达往往是模糊的，因此我们针对“表达模糊/意图模型”分别进行了大量的特殊数据构造，进一步培养模型的泛化能力。

此外，我学会的经验是：1.单条数据质量足够高和足够接近真实场景时，效果会比大规模低质数据更好。我们可以以一条高质量数据为本体，通过同场景不同query、同query不同context等方式作为变体，来构建大量数据。2、输入的context会很影响结果，篇幅过短丢失信息、过长会无关干扰以及增加大量时延，格式最好是简单清晰的JSON格式。

评测集设计：

核心评测集共有300条，其中产品侧重点定义了50条golden case样本，用于校准标注规则和典型样例。每条样本输入下列内容：query表达、 context情境信息、memory记忆偏好与 tool list，并且人工标注出预期的tool call答案（必选策略/可选策略/禁选策略）。

在具体的方案打分时，我们对「方案质量」进行0-5的打分，关注答案与预期tool call答案的匹配度，并结合「响应时延」「意图理解」「策略顺序」等因素进行硬约束（如超时或严重错答直接判定为0分）。现阶段打分主要通过“规则自动判定+人工review”的方法，在后期的RL阶段深化中，我们过强化学习模型来实现自动化打分。

模型评测的目的，是验证模型能否在特定场景，结合给定的context、memory信息，正确识别用户意图并给出合理的策略。并且在后续RL阶段，我们希望通过强化学习，进一步平衡模型准确性和推理长度。

对于智能座舱 Agent 的效果评估，模型效果仅是其中一环。真实车辆环境中，从语音输入 ASR 识别、query 分类路由、车辆实时情境context获取、云端模型推理与 tool call 下发，到车机端实际执行、GUI 展示和 TTS 播报反馈，每个环节都会影响最终用户体验。

在项目初期 POC 阶段，链路各环节都存在不稳定问题，仅用“成功/失败”无法有效定位问题来源。因此，我们逐步形成了“质量评分 + 问题归因”的评估方法：一方面通过0/0.5/1的打分方式衡量单条样本的任务完成情况，判断全链路任务成功率；另一方面进行badcase 归因，拆解为模型理解、参数调用、context / memory 获取、工具调用、车机执行、GUI 展示、NLG/TTS 播报等问题类型，从而更清晰地定位问题，快速推进模型、链路、交互等团队进行修复。

在测试集设计上，我们围绕 13 个核心场景构建实车测试样本，覆盖典型指令、模糊表达、情境依赖、记忆依赖、多意图组合和边界 case 等不同类型。每轮测试会根据当前版本的优化重点、场景成熟度和历史问题情况，选择重点验证的场景与 query；对于效果已经较稳定的场景，会降低测试频率，而对新改动场景、高风险链路和历史 badcase 进行重点复测。

测试前，我们会为样本配置对应的Prompt、所需情境记忆函数、场景候选tool list等内容。由于真实车辆环境中的 实时context会随车辆状态、座舱环境和用户设置动态变化，实车测试无法提前固定唯一的预期执行结果。因此，在测试过程中，我们会同步记录每条样本触发时的实际 context，结合 query、memory、tool call和最终链路表现进行综合标注，逐条判断实车测试的综合效果。

相比单纯的模型评测，实车评估更接近真实用户体验验证。它的重点不是预设唯一标准答案，而是在动态真实环境中记录变量、统一评分口径、判断决策合理性，并通过问题归因推动链路各模块逐步优化。

经过几个月的努力，项目共推进了 10+ 轮实车测试与 4 个关键版本迭代，全链路任务成功率由 19% 提升至 87%，从POC转入正式开发阶段。

技术理解是AI PM的基准线

在这段长期实习中，我最大的感受是：AI 产品经理不能只停留在需求和体验层，必须持续深入理解技术。技术理解决定了产品经理能否和模型、算法、端侧、云端、交互等团队有效沟通；而产品能力决定了能把技术能力带到多远、落到多具体的用户场景里。

这个过程中，我也系统训练了产品经理的基础能力，从竞品分析、需求拆解、PRD 撰写，到跨团队沟通、问题追踪和工程推进，都经历了比较完整的训练。也更加认识到，很多事情要先推动它跑起来，再在真实问题中持续把它做好。

评估体系的方法论

在这段实习中，我接触并参与了多种评估体系：既有面向模型能力的离线评测，也有面向真实车辆环境的实车效果评估；此外，还包括垂域 Agent 评估、澄清 Agent 评估、负反馈优化评估等专项评估。它们的评估对象、样本设计和评分口径并不完全一样，但底层逻辑可以大致抽象为三类：指标评估、badcase 归因和回归验证。指标评估用于判断整体效果是否达标，badcase 归因用于定位具体问题来源，回归验证则用于判断历史问题是否在新版本中真正收敛。

这也让我意识到，评估本身不仅是验收手段，也是推动 AI 产品持续迭代的重要工具。尤其在输入变量复杂、没有唯一标准答案的真实场景中，产品经理需要在统一评分口径和场景化判断之间找到平衡。

Agent 的智能体验来自全链路收敛

我也更深刻地理解到在工程场景中，Agent 的“智能”和“好用”并不只由大模型本身决定，链路的每个环节都至关重要。从前端 ASR 识别、query 路由、context / memory 获取，到模型推理、Tool Call、车机执行、GUI 展示和 NLG/TTS 播报，每一环都与用户体验直接相关。

很多看似不直接属于 Agent 模型能力的工作，例如GUI 反馈时机、流式展示、思考过程是否外显、播报语义是否自然等，都会影响用户是否觉得这个助手可靠、聪明、可用。

对我来说，这段经历最大的价值，是让我从“理解 AI 能力”进一步走向“理解 AI 产品如何被真正落地”。AI 产品经理真正要做的，不只是定义一个 Agent 能力，而是推动模型、链路、交互和真实场景体验一起收敛成一个可用的产品。