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