Formula E赛车AI副驾：手机端Gemini Nano实战

把大模型塞进时速200公里的赛车座舱，还要让它在没有稳定网络的环境下实时回答车手提问——这听起来像是科幻电影的情节，但Google Cloud团队真的在Goodwood速度节上把它跑通了。在最近的一场技术分享中，来自Google Cloud CTO办公室的Alistair和Formula E的Oli详细拆解了这个项目的技术栈与踩坑经历。

为什么要在赛车上跑端侧Agent？

项目的出发点很明确：验证Agent在极端边缘环境下的可行性。赛车内高温、蓝牙信号被碳纤维车身屏蔽（用演讲者的话说，"这辆车基本就是个法拉第笼"）、现场数十万观众导致网络拥塞、车手以超过200公里时速行驶时对响应延迟的容忍度极低——这几乎集齐了端侧AI部署的所有噩梦场景。

但团队很快意识到，需要的所有"原料"其实已经存在：Android作为宿主平台，ADK（Agent Developer Kit）负责Agent逻辑，Gemini Nano通过ML Kit调用端侧模型，加上完全离线的语音识别与TTS API。Google Pixel手机内置的TPU为端侧模型提供了硬件加速，让这套方案不需要额外定制微控制器。

系统架构：从CAN总线到座舱对话

数据链路：Raspberry Pi做"翻译官"

整车数千个传感器数据点通过CAN总线汇总到VCU（车辆控制单元）。团队将一台Raspberry Pi直接接入VCU，负责解码原始信号、做变换并降采样到约10Hz——对于副驾场景已经足够。随后Pi通过MQTT协议把精炼后的数据发布给座舱内的Pixel 10 Pro。

CAN总线（Controller Area Network）是汽车电子中广泛使用的串行通信总线标准，采用差分信号传输，具备强抗电磁干扰能力，整车ECU、传感器和执行器都挂载其上。原始CAN帧只包含ID和最多8字节载荷，具体含义由各厂商的DBC文件定义，因此需要专门的解码逻辑把比特位映射为车速、油门开度等物理量。VCU（Vehicle Control Unit，整车控制器）是电动车中的核心控制节点，负责协调动力系统并汇聚整车状态。由于CAN数据频率高、维度多，直接上送会给手机带来负担，项目才在Pi上做变换与降采样。

Agent运行时：ADK + Gemini Nano

手机端App基于ADK for Android构建Agent，核心模型是ML Kit承载的Gemini Nano。输入有两路：一路是MQTT传来的遥测数据，另一路是Android语音识别转写的车手语音。Agent输出也有两个方向：通过TTS直接与车手对话，或通过A2A（Agent-to-Agent）协议调用云端Agent处理更复杂的任务——比如查询当前比赛名次，这类信息赛车本身并不掌握，需要云端协同。

交互设计上，车手说出唤醒词后提问，Agent会在回答后继续监听约五秒，支持追问，模拟真实比赛工程师的对话节奏。多轮对话能力让Agent可以访问历史上下文，保持对话连贯。

A2A（Agent-to-Agent）协议是Google主导的开放协议，旨在让不同框架、不同厂商构建的AI Agent之间能够互相发现、通信与协作。它定义了Agent之间交换任务、状态和结果的标准化消息格式，通常基于HTTP/JSON实现。在本项目中，车载端侧Agent通过A2A把赛车自身不掌握的信息（如实时比赛排名）委托给云端Agent处理，云端完成后再把结果回传，形成端云协同的分工模式。这与MCP（Model Context Protocol，面向模型与工具/数据源的连接）定位不同：MCP解决的是Agent如何调用工具，A2A解决的是Agent之间如何互相调用。

Gemini Nano是Google Gemini模型家族中面向端侧设备的轻量版本，按参数规模分为Nano-1和Nano-2等档位，经过量化与蒸馏以适配手机内存和算力预算。它通过ML Kit（Google的移动端机器学习SDK）以GenAI API的形式暴露给Android应用，推理可借助Pixel设备内置的TPU加速，数据不出设备即可完成。相比云端大模型，Nano的上下文窗口和知识广度有限，因此适合做意图理解、摘要、短对话等任务，复杂查询则需回退到云端——这也正是本项目采用端云混合架构的原因。

代码结构：简单到出乎意料

演讲者特别强调代码并不复杂：几行调用ML Kit加载Gemini Nano，用ADK定义Agent名称和两类指令。静态指令定义Agent的人设与赛道知识，动态指令则在每次查询时根据最新遥测摘要和对话历史生成，确保Agent始终掌握车手当前状态。工具层面则注册了会话数据回溯、云端Agent调用和TTS语音输出三项能力。

实车验证：数据通了，但麻烦才刚开始

仿真台架上的演示很流畅——车手问"我的转向有多激进"，Agent回答峰值转角48度、平均每秒转11度；问峰值G力，答2.2G；问整段表现，答最高时速306公里、35秒内平均186公里、58%时间全油门。

但真车部署是另一回事。团队前往巴黎的Spark Racing Technologies，把Raspberry Pi接入真实VCU。此前所有测试都基于回放数据，插上电后等待遥测数据真正流出的那一刻才确认系统链路打通。

Goodwood现场首先考验的是散热。当天恰逢全年最热的几天之一，但出乎意料的是手机本身运行正常，反而是Raspberry Pi扛不住，最终靠外接UPS电池组全天反复补电才撑过爬坡环节。第二个考验是蓝牙头盔连接——此前从未实测过。团队坐在草地上用笔记本电脑紧急调试，表面轻松，实际是"职业生涯中最紧张的时段之一"，最终靠热修复和Android调试工具在发车前解决问题。

三条工程经验

Android是端侧Agent的合适宿主。 ADK、端侧模型、离线语音API和调试工具的组合，让一个手机就能承载完整的Agent体验，无需定制硬件。

集成地狱依然存在。 各子系统单独跑通不等于拼起来能跑。车手头盔的蓝牙连接就是典型案例——问题恰恰出在最不起眼的环节，测试的重要性再怎么强调都不为过。

Gemini Nano需要打磨而非即插即用。 演讲者把它称为项目的"英雄"，但强调必须做提示工程：静态指令与动态指令如何分工、工具如何定义与调用、如何做评估测试，这些都决定了端侧模型能否在严苛场景下稳定输出。

这个项目的价值不在于赛车本身，而在于它证明了一件事：当网络不可靠、延迟要求苛刻、环境恶劣时，手机端侧Agent已经具备实际可用的能力——而需要的工具链，今天就能拿到。