7月5日的上海国际赛车场，注定成为赛车迷们难以忘怀的一天。

雨势时断时续，赛道表面呈现出半干半湿的复杂状态。在Formula E电动方程式上海站第二回合正赛中，安全车引领着车队起步，但发车顺序在比赛开始前就已被彻底打乱。原本在车手积分榜上领跑的捷豹车手米奇·埃文斯，因赛车疑似出现DC/DC电控故障，连发车都未能完成。而真正的焦点人物，是从全场最后一位、第20位发车的老将卢卡斯·迪·格拉西。据赛后多家外媒报道，他的赛车采用了干地设定，在赛道逐渐变干的尾段，他一路超车，最终冲到第一，结束了自己长达四年的冠军荒。紧随其后的让-埃里克·维尔纽同样是从队尾奋起直追，取得了第二名的好成绩。

这场比赛几乎颠覆了所有赛前预测。能量管理、攻击模式的使用时机、天气变化窗口、车辆调校策略，二十辆赛车的各种变量在四十多分钟的比赛时间里相互交织，演绎出一场精彩绝伦的较量。

如果你观看了本赛季Formula E的国际信号转播，可能会注意到一些新画面：在比赛进行中，转播画面上会不时弹出一些“解释性”文字，比如某位车手正在为了缩小差距而透支能量，或者领跑者的能量储备已经低于安全线。这些实时洞察的角落里，出现了一个在赛车场上略显“异类”的名字：

Google Cloud。

一家以云计算为主业的公司，竟然出现在了满是轮胎、碳纤维和换电站的赛车场。而且，它并非以普通赞助商的身份出现。就在今年1月，Formula E官方宣布与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落地的真相，答案不言自明。