7 月 5 日下午的上海国际赛车场，注定是赛车迷们铭记多年的时刻。雨势时断时续，赛道处于半干半湿的微妙状态。Formula E 上海站第二回合正赛在安全车引导下起步，发车顺序几乎在开赛前就被打乱——原本领跑车手积分榜的捷豹车手米奇埃文斯，因赛车疑似出现 DC/DC 电控故障，甚至未能完成发车。而真正的主角，是从全场第 20 位起步的老将卢卡斯迪格拉西：据赛后多家外媒报道，他在赛道逐渐变干的尾段押注了一套干地设定，一路穿越整个车阵冲至第一，终结了自己长达四年的冠军荒。第二名让埃里克维尔纽斯同样是从队尾杀上来的。这是一场几乎所有赛前预测都失效的比赛。能量管理、攻击模式的使用时机、天气窗口、调校赌注，二十辆赛车的变量在四十多分钟里互相纠缠。如果你看过本赛季 Formula E 的国际信号转播，会注意到一类新画面：比赛过程中，转播画面时不时弹出一行行解释——比如某位车手正在为了追近差距而透支能量，或者领跑者的能量储备已经低于目标线。这些实时洞察的角落里，署着一个在赛车场上多少显得格格不入的名字：Google Cloud。一家卖云计算的公司，出现在一个满是轮胎、碳纤维和换电站的地方。而且不是以普通赞助商的身份——就在今年 1 月，Formula E 官宣与 Google Cloud 达成新的多年期合作，后者正式成为这项赛事的首席合作伙伴兼首席 AI 合作伙伴，进入了仅次于冠名合作伙伴 ABB 的最高赞助梯队，并且是其中唯一一家以 AI 为名的一家。好好的 Google Cloud，怎么跑去改造电动赛车了？
01、一场蓄谋已久的升级
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 技术栈放在极限工况下公开路测的权利。
02、转播画面背后，一整条流水线
Google Cloud 到底在 Formula E 里做了什么？最有代表性的，是已经进入直播信号的策略智能体。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% 的工作量，是数据工程、消息架构、数据库选型和规则引擎——是那些一点也不性感、但决定系统生死的东西。
03、赛车给 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 落地的真相，答案不言自明。