好好的GoogleCloud，怎么跑去"改造"电动赛车了

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 落地的真相，答案不言自明。