Google Cloud跨界电动赛车：一场技术革新与AI落地的深度探索

7月5日午后，上海国际赛车场迎来了一场让赛车迷们铭记许久的赛事。彼时，天空时而飘雨，时而放晴，赛道处于半干半湿的复杂状态。Formula E电动方程式上海站第二回合正赛在安全车的引领下正式发车，然而发车顺序在赛前就已被彻底打乱。原本在车手积分榜上领跑的捷豹车手米奇·埃文斯，因赛车疑似出现DC/DC电控故障，连发车都没能完成，只能无奈退场。而真正的焦点人物，是从全场最后一位，也就是第20位发车的老将卢卡斯·迪·格拉西。据赛后多家外媒报道，他的赛车采用了干地设定，在赛道逐渐变干的尾段，一路披荆斩棘，穿越整个车阵，最终冲到首位，终结了自己长达四年的冠军荒。同样令人惊叹的是，第二名让 - 埃里克·维尔纽也是从队尾奋起直追，实现了逆袭。

这场比赛堪称“爆冷”大戏，几乎所有赛前的预测都失去了准头。在四十多分钟的赛程里，能量管理、攻击模式的使用时机、天气窗口的把握以及调校赌注等，二十辆赛车所涉及的众多变量相互交织，让比赛充满了变数与惊喜。

倘若你观看了本赛季Formula E的国际信号转播，就会发现一些与众不同的画面。在比赛进行过程中，转播画面上会时不时地弹出一行行“解释性”文字。比如，会提示某位车手为了追近与前车的差距而过度透支能量，或者领跑者的能量储备已经低于目标线。在这些实时洞察信息的角落里，出现了一个在赛车场看似有些“格格不入”的名字：

Google Cloud。

一家专注于云计算领域的公司，为何会出现在这个满是轮胎、碳纤维和换电站的赛车场呢？而且它并非以普通的赞助商身份出现。就在今年1月，Formula E官方宣布与Google Cloud达成新的多年期合作协议，Google Cloud正式成为这项赛事的首席合作伙伴（Principal Partner）兼首席AI合作伙伴（Principal AI Partner），进入了仅次于冠名合作伙伴ABB的最高赞助梯队，并且是其中唯一以AI为名的合作伙伴。

那么，原本专注于云计算的Google Cloud，为何会投身到“改造”电动赛车的事业中呢？

一场精心筹备的“升级”之旅

Google Cloud与Formula E的正式合作起始于2025年1月，当时它担任的是官方云技术服务合作伙伴和云安全合作伙伴的角色。但实际上，在此之前双方就已经“暗中”合作了大约两年时间。在这两年里，Formula E将其庞大的数据资产整体迁移到了Google Cloud上，员工的协作工作也搬进了Google Workspace。不仅如此，双方还携手打破了三项吉尼斯世界纪录，其中包括用GENBETA赛车创下的车辆室内最快速度纪录。

在众多合作项目中，最能体现双方合作深度的当属“Mountain Recharge”项目。该项目让一辆Formula E赛车从山顶滑降，全程依靠动能回收为电池充电，最终积累出足够跑完一整圈摩纳哥赛道的电量。这个项目的关键并非在于赛车本身，而在于路线规划。工程师们运用Google AI Studio和Gemini模型，精确计算最优下山路线，仔细识别和分析每一个最佳制动区域，确保再生制动的每一脚刹车都能发挥最大效能，真正做到“刹在刀刃上”。

到了2026年1月，双方的合作进一步升级为首席合作伙伴关系。按照双方的说法，此次升级的核心是将Gemini模型系统性地嵌入Formula E的整个体系之中，涵盖赛事运营、车手表现分析以及观赛体验等多个方面。Formula E CEO杰夫·多兹用“game - changer”来形容这次合作；Google Cloud EMEA总裁塔拉·布雷迪则直言，Formula E是一个“毫秒决定成败”的激烈赛场，正好可以用来检验Google的AI在最苛刻场景下能够交出怎样的答卷。

换句话说，这并非是一笔传统意义上的体育赞助，仅仅让logo露出只是顺带的事情。Google Cloud真正看重的，是获得一个将自家AI技术栈置于极限工况下进行公开路测的宝贵机会。

转播画面背后，隐藏着一条高效的技术流水线

Google Cloud究竟在Formula E中发挥了怎样的作用呢？其中最具代表性的，便是已经进入直播信号的“策略智能体”（Strategy Agent）。

Formula E官方在去年12月发布了一篇技术博客，以工程师的视角详细阐述了这套系统的架构。深入研究发现，它几乎堪称一部“生成式AI如何真正融入生产环境”的标准教材。

第一步是数据摄取环节。

该系统需要处理两路高保真数据。一路来自官方计时系统，包含圈速、名次等事件流信息；另一路则是每辆赛车的遥测数据，如电池状态、速度、油门曲线等。摄取层采用Airflow、Cloud Scheduler和Cloud Run组合而成，实现了无服务器化、全自动操作，并且与赛历严格同步，确保数据的及时性和准确性。

第二步是消息中枢的搭建。

数据一旦进入云环境，便会立刻被转发到Pub/Sub消息队列。这样，内部应用和外部合作方都能够以极低的延迟订阅这条数据流，实现数据的快速共享和利用。

第三步是一个颇具深意的技术选型。数据经由Cloud Run服务直接写入AlloyDB，官方博客给出的解释十分坦诚。他们需要一款兼容PostgreSQL、能够承受高强度事务负载，并且延迟在亚毫秒级的引擎。虽然BigQuery在海量数据的分析查询方面表现出色，但直播场景更注重“此时此刻”的实时性。这一选择充分体现了“正确工具做正确事”的原则，也从侧面说明这套系统是按照生产系统的严格标准打造的，并非市场部门临时拼凑的演示品。

第四步，“智能体”正式登场。

Strategy Agent运行在一台专用的Compute Engine实例上，直接连接AlloyDB，持续监控比赛状态。但它并非简单地将所有数据一股脑地丢给大模型，而是先通过一套复杂的触发器和规则进行状态判断，例如“安全车是否出动？”“领跑者的能量是否低于目标线？”只有当规则层认定“这里有值得关注的故事”时，相关数据才会被打包送往下一环节。

第五步，Gemini模型发挥作用。数据包被异步发送给Gemini 2.5 Flash，由它将一堆复杂的圈速表格和能量曲线，转化为通俗易懂的一句话，比如“维尔纽正在二号赛段透支能量以缩小差距”。Formula E团队在模型选择上十分谨慎，他们追求的不是最强的推理能力，而是在推理能力与极致速度之间找到平衡，以满足直播场景的实时性需求。

在这个被命名为“Agent”的系统里，大模型仅仅负责“最后一公里”的工作。而前面90%的工作量，集中在数据工程、消息架构、数据库选型和规则引擎等方面，这些都是看似不那么“炫酷”，但却决定系统生死存亡的关键因素。

赛车为Google在AI进步上提供的“反馈”价值

Google Cloud为何要如此大力投入“改造”一项赛车运动呢？

答案就隐藏在这些技术细节之中。剥开赛车华丽的外壳，Formula E对于Google来说，是一个近乎完美的技术试验场，而它所考察的恰恰是当下AI落地过程中最具挑战性的三件事。

第一，异构数据的实时理解能力。

现代赛车运动所产生的数据形态极为复杂多样，既有结构化的计时数据，又有高频的传感器遥测数据，还包括图像、视频，甚至HTML渲染的图表等。传统做法是为每类数据单独建立一套处理管线，而Gemini这一代多模态模型则开创了一种新的范式，即“一个模型对齐所有模态”。Formula E的场景充分证明了这条路在生产环境中是切实可行的。放眼全球，物联网设备、农业传感器、金融研报等领域所产生的数据都具有类似的复杂性，这也是为什么Google内部将Driver Agent的架构直接作为电信、农业、金融等行业的参考方案进行推广。

第二，速度作为首要约束条件的重要性。

Formula E团队宁愿继续使用Gemini 2.5 Flash，也不急于采用最新的大模型，这一选择颇具深意。在真实的业务场景中，延迟并非是一个可以在产品开发后期再进行优化的指标，而是产品定义的核心要素之一。直播、客服、交易、驾驶辅助等众多高价值场景，对AI的要求都是“既足够聪明又足够快”，而非单纯追求“最聪明”。在模型厂商不断竞争推理能力的同时，“能力 - 速度 - 成本”三角中的工程取舍问题，才是企业客户每天都要面对的实际挑战。

第三，也是最违背直觉的一点：Agent的性能，很大程度上取决于模型之外的因素。

在Strategy Agent的架构图上，Gemini模型只占据一个小小的格子，而其余部分则全是消息队列、数据库、规则引擎、监控系统和人工审批流等。这与当下许多“Agent产品”的宣传话术形成了鲜明的对比。在营销语境中，Agent往往被描绘成无所不能的自主智能体；然而在Formula E的生产系统里，Agent是一套被规则严格约束、由人类导演把关、被端到端监控包裹的数据流水线，大模型仅在最需要“翻译”和“推理”的关键环节被精确调用一次。

那么，哪一种更接近AI落地的真实情况，答案不言而喻。