小米车辆助手公测：Agent开始控车

小米把 Agent 放进了汽车 App

小米汽车在 8 月 17 日开启「车辆助手」公测体验官招募，车主可以直接在小米汽车 App 内通过对话查询车辆状态、即时或定时控车、创建「小米超级任务」，还可以让系统总结驾驶风格、记忆日常用车习惯。

车辆助手是一个面向小米汽车车主的对话式 Agent，它会把自然语言需求拆解成车辆查询、车控操作和自动化任务。 与传统语音助手相比，它不只是回答“剩余电量多少”，还试图理解“我 10 分钟后出门去公司，把空调提前打开”背后的时间、目的地和车控意图，并在满足条件时执行相应操作。

IT之家 8 月 17 日报道显示，本轮公测面向全量车主招募，但并不意味着所有报名用户都会立即获得权限。小米将结合报名信息筛选首批体验官，审核结果计划在 8 月 26 日通过小米汽车 App 站内信和短信下发，用户也可以进入「我的—我的活动」查看结果。

这次测试不需要更新车机系统，是此次产品更新最值得注意的工程信号。 入选用户只需按照活动指引升级小米汽车 App 公测版本即可体验，说明车辆助手的主要交互入口、任务编排和模型能力大概率部署在手机端及云端，最终再通过已有的车辆远程控制通道下发指令，而不是给整车新增一套独立的控制系统。

它不是换了一层聊天皮肤

车辆助手的核心变化，是把车控入口从“用户找按钮”改成“系统理解目标”。 传统汽车 App 的典型逻辑是功能树：用户打开 App，找到空调页面，设定温度，再点击开启；对话式 Agent 的逻辑则是目标驱动，用户只需要描述什么时候出发、准备去哪里、希望车内达到什么状态。

以官方给出的场景为例，车主说“我 10 分钟后出门去公司，把空调提前打开”，系统至少需要完成四步处理：

1. 识别“10 分钟后”是一个相对时间条件；
2. 理解“去公司”代表一次即将发生的通勤；
3. 将“提前打开”映射到车辆空调控制能力；
4. 在执行前确认车辆在线、权限有效，并按照安全策略下发指令。

Agent 与普通聊天机器人的区别，是前者能够围绕目标调用工具并产生实际结果。 如果系统只是回答“好的，建议您提前打开空调”，它仍然只是问答机器人；只有当它能读取车辆状态、创建计划、调用车控能力并反馈执行结果时，才真正进入 Agent 范畴。

从目前公布的信息看，小米车辆助手已经覆盖四类能力：

| 能力类型 | 官方示例 | 系统需要调用的能力 | 相比传统 App 的变化 | |---|---|---|---| | 车辆状态查询 | 查询车辆状态、剩余权益 | 车辆数据、账户与售后数据 | 不再逐层查找页面 | | 即时与定时控车 | 10 分钟后打开空调 | 时间解析、车辆控制、结果回传 | 一句话组合时间与动作 | | 超级任务创建 | 工作日中午自动把车内调舒服 | 条件编排、设备动作、周期任务 | 用户不必手动配置多个条件 | | 驾驶与用车分析 | 最近一个月的驾驶风格画像 | 历史行程、驾驶行为统计、文本总结 | 从数据列表升级为自然语言洞察 | | 出行规划 | 北京到乌兰布统自驾 7 天 | 路线规划、地点检索、行程组织 | 从单点导航扩展到多日计划 | | 功能咨询 | 儿童锁怎么开 | 车辆手册、车型配置、服务知识库 | 让说明书变成可追问的问答系统 |

这张能力表也说明，车辆助手的价值并不平均分布在所有场景里。 查询电量、打开空调本来就能通过 App 按钮完成，Agent 只是少点几下；真正有增量的是跨越时间、车辆状态和多个动作的复杂任务，例如工作日午休自动调节座舱，或者先分析现有任务，再指出哪些自动化规则可能重复、冲突或没有必要。

「超级任务」可能比聊天本身更重要

小米超级任务是由触发条件和执行动作组成的车辆自动化规则。 它可以被理解为汽车版的智能家居场景：当日期、时间、位置或车辆状态满足条件时，系统自动执行一组预设操作。

过去创建自动化任务往往需要用户理解“如果—那么”结构，例如先选择工作日，再选择中午时段，然后配置空调温度、座椅状态或其他可用动作。车辆助手把这个配置过程变成自然语言，用户可以直接说：“创建一个超级任务，工作日中午我回车里午休时，就把车里调得舒服一些。”

自然语言降低了创建任务的门槛，但也引入了新的歧义。 “中午”究竟是 12 点整还是 11:30 至 13:30，“舒服一些”对应多少摄氏度，是否需要同时打开座椅通风，以及节假日是否继续执行，这些都不是语言模型可以擅自决定的细节。

因此，一个成熟的车控 Agent 不应该追求“一句话之后什么都不问”，而应该在关键参数不明确时主动追问，在生成任务后给出结构化预览。例如系统可以明确显示：工作日 12:00、车辆停放状态下、开启空调至 24 摄氏度、持续 30 分钟。用户确认后再保存，远比模型自行猜测更可靠。

车辆助手还具备分析并优化现有任务的潜力。 官方示例中，用户可以要求系统查看当前有哪些任务，并分析是否存在可优化之处。这意味着 Agent 不只是负责创建规则，也可能识别两个任务在同一时间重复开启空调、某项任务长期没有触发，或者多个条件之间存在互相覆盖的问题。

这类能力对小米尤其合适，因为小米汽车并不是孤立产品。小米澎湃 OS 强调“人车家全生态”，汽车、手机、智能音箱和米家设备可以共享账号与部分场景能力；如果车辆助手未来获得更多生态工具调用权限，它可以把“准备出门”同时翻译成车辆备车、家庭设备关闭和路线规划，而不只是远程开一次空调。

从按钮、语音到 Agent，交互逻辑变了

车辆助手代表了汽车交互从命令式操作向意图式操作迁移。 命令式操作要求用户知道设备能做什么、功能在哪里；意图式操作允许用户先表达目标，再由系统选择工具和步骤。

| 交互方式 | 用户需要知道什么 | 能否组合多个步骤 | 能否记忆习惯 | 主要优势 | 主要问题 | |---|---|---:|---:|---|---| | App 按钮车控 | 功能入口和操作路径 | 较弱 | 通常不能 | 结果明确、可预测 | 操作步骤多 | | 固定语音指令 | 预设说法和指令边界 | 有限 | 较弱 | 速度快、适合车内 | 容错率依赖指令设计 | | 对话式车辆助手 | 用户只需描述目标 | 较强 | 支持 | 可处理复杂、模糊需求 | 歧义、误执行与隐私风险更高 | | 辅助驾驶模型 | 驾驶目标与道路环境 | 面向驾驶决策 | 不等同于个人记忆 | 处理道路感知与轨迹决策 | 必须由驾驶员持续监督 |

车辆助手不能与小米 XLA 认知大模型画等号。 小米 XLA 是面向辅助驾驶的模型架构，重点处理道路场景、多模态感知、行为推理和车辆运动决策；此次公测的车辆助手则主要位于 App 与车主服务层，负责对话理解、信息查询和远程车控任务编排。

两者都使用“大模型理解意图”的产品叙事，但安全边界完全不同。车辆助手执行提前开空调或查询保养权益，不等于它可以通过聊天直接控制方向、加速或制动，也不代表车辆获得了自动驾驶能力。现阶段将其称为“对话式控车 Agent”更准确，而不是“用大模型开车”。

不更新车机，意味着迭代能更快

无需车机 OTA 能明显缩短车辆助手的迭代周期。 车机软件更新通常需要经过车型适配、整车测试、版本发布和安装验证，而 App 公测版本可以更快修复对话理解、界面呈现和任务编排问题。

这种架构还有一个现实好处：车辆助手可以在车主离车之后使用。用户可以在办公室里规划下班路线、在电梯中提前备车，或者在睡前检查次日的自动化任务，不需要坐进车里再唤醒座舱语音助手。

App 侧迭代更快并不意味着车控安全要求可以降低。 即便模型负责理解自然语言，真正执行车辆动作的部分仍然应该经过确定性的权限校验和规则引擎。语言模型可以把“十分钟后备车”转换成候选操作，但账户身份、车辆归属、设备在线状态、敏感操作确认和执行结果，都不应该由模型自由生成。

目前小米尚未在公开招募信息中披露车辆助手的完整可控功能清单，也没有详细说明哪些操作需要二次确认、对话数据保存多久、驾驶画像是否可以关闭，以及记忆数据如何删除。对于一项能够读取车辆状态并调用车控能力的产品，这些信息与模型回答是否自然同样重要。

最大挑战不是听懂，而是别做错

车控 Agent 的第一优先级应该是可控性，而不是拟人化。 聊天机器人答错一个景点信息，用户最多重新搜索；车辆助手如果误解时间、车辆或动作，可能造成空调长时间运行、车辆在错误时间执行任务，甚至带来账户与隐私风险。

公测阶段至少有四项能力值得重点观察：

• 执行前确认： 涉及解锁、车窗、后备厢等敏感操作时，系统是否明确展示目标车辆与具体动作；
• 执行后回执： 指令下发成功是否等于车辆实际完成操作，失败后是否会解释原因；
• 任务可撤销： 定时控车和超级任务能否快速暂停、删除或回滚；
• 多车与多人权限： 同一账户或家庭成员绑定多辆车时，Agent 是否会确认操作对象和授权范围。

“记忆用车习惯”同样是一把双刃剑。 系统如果记得用户每周二去某处、每天几点出门，以及常用的空调温度，确实能减少重复设置；但这些数据也可以组合出工作地点、家庭住址、作息规律和出行轨迹，因此用户需要清楚知道系统记住了什么，并拥有查看、修改、关闭和删除记忆的入口。

驾驶风格画像也不应只生成一句“驾驶较为激进”的模糊评价。更有用的产品形态应该说明统计周期、样本里程和判断依据，例如急加速次数、急减速次数、平均能耗与高速行驶占比，并区分车辆数据事实与模型生成的建议。否则所谓画像很容易沦为看起来聪明、实际上无法验证的总结。

小米的优势在生态，短板也在复杂度

小米做车辆 Agent 的最大优势，是已有的手机、汽车和智能家居设备入口。 单一车企可以做好车内语音，但很难同时掌握用户的手机系统、家庭设备和汽车账号；小米则有机会让同一个 Agent 跨越多个终端，并延续统一的用户身份和自动化规则。

这种生态优势也会带来权限复杂度。一次“我要出门”的请求可能涉及家庭摄像头、门锁、空调、手机日历和车辆位置，系统调用的设备越多，错误影响范围越大。小米需要把每个动作的授权边界讲清楚，而不是只强调“一句话完成所有事情”。

首轮公测的成败不会取决于它能聊多少话题，而取决于高频车控能否稳定闭环。 对车主最有价值的不是再多一个万能聊天窗口，而是少点几次屏幕、少配置几层菜单，同时仍能看清 Agent 准备做什么、什么时候做、最终是否做成。

从产品方向看，小米车辆助手值得肯定。它没有把大模型只放在车机里陪聊，而是开始接管查询、规划、任务创建与真实车控工具，把汽车 App 从遥控器推进到个人出行控制台。不过，本次仍是名额有限的公测招募，外界还无法据此判断其识别准确率、执行延迟和长期稳定性，小米也尚未公布相关量化数据。

车辆助手真正的分水岭，是能否在“聪明”和“可靠”之间建立明确边界。 如果它只是用自然语言替换几个按钮，产品新鲜感很快会消失；如果它能稳定处理跨时间、跨设备和跨场景的自动化任务，并让所有关键动作可确认、可追踪、可撤销，它才可能成为小米“人车家全生态”里最重要的 Agent 入口之一。

公测信息一览

• 招募时间节点： 2026 年 8 月 17 日已开启招募；
• 招募对象： 面向全量小米汽车车主报名；
• 开放方式： 根据报名信息综合筛选，首批名额有限；
• 审核结果： 计划于 8 月 26 日通过站内信和短信通知；
• 查询路径： 小米汽车 App「我的—我的活动」；
• 升级要求： 无需更新车机，按活动指引升级 App 公测版本；
• 主要功能： 查车、即时或定时控车、创建和管理超级任务、规划行程、总结驾驶风格、记忆用车习惯、咨询车辆功能及服务权益。

参考来源

• IT之家：小米汽车 App「车辆助手」开启公测招募——整理了公测时间、招募方式、升级要求及官方场景示例。