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