從“if-else”到“多智能體協同”，Google Cloud 用一場馬拉松演示，點透了企業 Agent 落地的真正難點。

圖文 | Gemini A I 小分隊

責編 | CSDN 編輯部

出品丨AI 科技大本營（ID：rgznai100）

拉斯維加斯的早晨，Google Cloud Next 的會場，音樂制作人 JayTee Hazard 正在操作著混音臺，而他身邊的創意技術專家 Tina Tarighian 則用雙手在空中揮舞，控制著背后隨音樂實時變幻的視覺代碼。

在過去的一兩年里，類似的“AI 魔法”在無數個科技展會上演。人們敲擊幾下鍵盤，或者輸入一段自然語言，機器就能迅速吐出一段代碼、一幅畫作，甚至一個看似能自主思考的對話機器人。對于坐在臺下的數千名開發者來說，這樣的場景并不陌生。在各種黑客馬拉松和社區論壇里，只要寫幾段 Prompt，掛載兩三個外部搜索工具，拼湊幾行 Python 腳本，一個簡單的 Agent（智能體）Demo 很快就能在本地跑起來。

但當會場廣播響起，Google Cloud GCP 與 SRE 總裁Brad Calder走上臺時，話題迅速從炫酷的視覺秀切入到了冷硬的現實工程里。

，Google Cloud 花了大量時間向企業高管們解釋，為什么今天的大公司需要一套企業級的智能體平臺。而到了第二天的Developer Keynote，聚光燈終于打在了真正要徒手把這些系統建出來的開發者身上。

當一個在本地跑得通的 Agent Demo，試圖接入擁有上萬并發用戶的生產環境時，開發者面對的不再是“模型聰不聰明”的問題。他們需要處理狀態的丟失、工具調用的超時、API 密鑰的泄露、長文本帶來的 Token 爆炸，以及多個智能體在復雜任務中像無頭蒼蠅一樣相互干擾的窘境。

Google Cloud 給開發者們準備了一張巨大的架構圖。

從 Agent Development Kit (ADK) 到模型上下文協議（MCP），從 Agent Runtime 到 Agent Registry，再到負責觀測的 Agent Observability 和負責底線安全的 Agent Gateway。

這張圖里的每一個模塊，都在指向同一個現實：當應用架構開始從函數、微服務、API，慢慢演變成一組會協作、會沉淀記憶、甚至會自我修復的智能體網絡時，開發者每天面對的底層環境變了。

不再是拘泥于 AI 寫代碼有多快，而是把過去開發者需要自己東拼西湊、甚至無從下手的那一大塊 Agent 運行基礎設施，直接作為平臺的默認能力端了出來。

? 16 分鐘音頻帶開發者朋友們聽完 Google Cloud Next 大會全程！

一場關于物理世界復雜約束的壓力測試

Google Cloud 技術布道師團隊Emma Twersky和Richard Seroter站在臺上，調出了他們正在構建的模擬應用。屏幕上，拉斯維加斯的 3D 天際線被點亮，成百上千個代表跑者的光點在賽道上移動，甚至連旁邊街道上緩慢行駛的模擬車流都清晰可見。

這個工程量絕不只是在地圖上畫一條線。路線的長度必須精確到 42.195 公里（或者 26 英里 385 碼）；封鎖某些路段會對整個城市的交通網產生連鎖反應；必須考慮緊急救援路線的重新規劃；沿途需要根據補給策略精準投放醫療帳篷、補水站，甚至是 500 個移動廁所；更棘手的是，系統還要應對非確定性的變量，比如歷史數據顯示，78% 的跑者會在馬拉松的后半程掉速，這些微觀行為的聚集，會對宏觀環境產生什么影響？

把這樣一個充滿物理世界真實約束的任務交給系統，實際上是在進行一場壓力測試。它把 Agent 從單一的“文本生成器”或“聊天助手”，逼到了必須進行復雜邏輯推演、空間計算和環境仿真的角落里。

開發者Mofi Rahman走上臺，他的任務是構建這套系統里最基礎的一個部件：Planner Agent（規劃師智能體）。

如果按照傳統的開發路徑，Mofi 需要先仔細閱讀 Google Maps 的 API 文檔，處理繁瑣的 OAuth 認證，編寫請求經緯度數據的封裝函數，再把獲取到的數據喂給語言模型。但這次，他在 Agent Designer 中走了一條完全不同的路。

他打開了智能體設計器，給這個規劃師智能體輸入了一段關于馬拉松規劃的系統指令。接著，他需要讓這個 Agent 具備地理空間計算的能力。Mofi 并沒有寫任何 API 對接代碼，而是直接將智能體連接到了 Google Maps 的 MCP 服務器。

在這個新架構下，所有的 Google Cloud 服務都已經默認支持 MCP。這意味著平臺已經在底層建立好了安全的通信隧道和標準化的工具定義。Mofi 只需要在代碼里加幾行配置，Agent 就立刻擁有了直接調取拉斯維加斯地標數據的能力。

隨后，Mofi 引入了“技能（Skills）”的概念。一個技能包含 YAML 格式的元數據和 Markdown 格式的主體，元數據決定了 Agent 在什么上下文中才需要加載這項技能。他給 Planner 掛載了三個技能：一個地圖技能，讓它能選擇性地調用 Google Maps；一個GIS（地理信息系統）技能，允許 Agent 執行預置的 Python 腳本來處理 GeoJSON 數據，從而計算出一條起點和終點都合理的路線；最后是一個賽事總監技能。

這個“賽事總監技能”的來源尤其值得注意。Mofi 直接導入了一份真實世界里賽事策劃委員會用來檢查路線的文檔。借助 Gemini，這份原本供人類閱讀的歷史經驗文檔，被無縫轉化成了 Agent 可以直接執行的判斷邏輯。

幾分鐘后，Mofi 將這個配置好的 Planner 部署到了 Agent Runtime 上。在 Emma 的模擬界面里，一條規劃好的紫色路線在拉斯維加斯大道的地圖上渲染了出來。此時的 Planner，已經不再是一個單純的大語言模型，而是一個被 ADK（智能體開發套件）、地圖工具和專業領域常識武裝起來的模塊化工程單元。

把單體應用拆解為智能體團隊

在傳統的軟件開發中，開發者習慣于編寫一條從頭跑到尾的線性邏輯，通過一層層的if/else和函數調用來校驗結果。如果在單一的 Agent 里塞入所有的任務——既要畫路線，又要評估對社區的影響，還要計算長度，最后還要模擬交通，這個 Agent 的上下文很快就會崩潰，它會陷入嚴重的“幻覺”，甚至忘記自己最初的任務是什么。

Casey West和Ivan Nardini接過了演示的接力棒。他們的做法是，把這個龐大的任務拆解，構建一個由多個智能體組成的團隊。

他們在原有的 Planner 之外，又引入了兩個全新的角色：Evaluator（評估師）和Simulator（模擬器）。

Evaluator 被設計成一個獨立的子智能體。它的工作極其純粹：不參與任何路線的生成，只負責拿一把標尺，對 Planner 產出的路線進行嚴苛的打分。

它使用一個獨立的模型，擁有非常有限且聚焦的上下文，只盯著幾個關鍵指標看——路線長度是不是分毫不差的 42.195 公里？社區影響如何？是否符合最初的 Prompt 要求？每一次 Planner 試圖生成新計劃，都必須像調用外部工具一樣，把結果發給 Evaluator 進行校驗。

Simulator 則負責另一個維度的任務。它接收獲批的路線，配置環境變量，然后利用 Gemini Deep Research 學習到的現實世界人類跑步行為模式，在沙盒里生成成千上萬個獨立的跑者 Agent 會話，監控可能出現的交通擁堵，再把模擬結果反饋給 Planner。

這三個各自獨立的 Agent，又是怎么在一個系統里配合起來的？

Ivan Nardini 在屏幕上調出了Agent Registry（智能體注冊表）。在多智能體系統中，如果還是靠開發者去硬編碼寫死 A 怎么調用 B，系統就會變得極其脆弱。Agent Registry 扮演了整個智能體網絡的“DNS 解析中心”。

當 Planner 和 Simulator 被部署到 Agent Runtime 時，它們會自動在這個注冊表里登記。每個 Agent 都會對外暴露一張 Agent Card（智能體卡片），這張卡片就是一份能力清單，告訴網絡里的其他成員“我會做什么”。當 Planner 需要進行跑者模擬時，它不需要知道 Simulator 具體的 IP 地址或 API 接口，它只需要通過通用的 A2A（Agent-to-Agent）協議，在注冊表中“發現”具備模擬能力的 Agent，并自動建立對話。

這種設計將系統內部的耦合度降到了最低。開發者從一個“寫死每一行邏輯的實現者”，變成了“定義能力邊界并讓系統自行運轉的編排者”。

隨后，Casey 拋出了另一個前端開發領域的痛點。既然 Evaluator 已經給路線打出了詳細的分數，這些多維度的數據該怎么展示給用戶？如果按照以往的流程，前端工程師需要加班加點去寫各種圖表組件，對接評估數據接口，做一個定制化的 Dashboard。

但在臺上的演示中，當評估完成后，UI 界面是直接在地圖旁邊“長”出來的。

Casey 展示了背后的秘密：一項名為A2UI（Agent-to-User Interface）的開放標準。開發者只是在系統里提供了一個單樣本（One-shot）的 UI 示例，告訴 Gemini 當前應用使用的通用設計語言規范。

當 Agent 拿到評估結果后，它沒有吐出一大段干癟的文本分析，而是直接理解了數據結構，動態調用了對應的圖表和信息流組件，在地圖引擎之上，為自己精確渲染出了一個交互式的評估結果面板。

前端組件被降維成了 Agent 可以調用的“詞匯”。系統的輸出邊界，從純數據層直接延展到了交互層。

上下文與記憶：給系統裝上時間軸與地方志

當多個 Agent 能夠相互協作后，系統面臨的下一個巨大挑戰是狀態管理。

如果把 Agent 比作員工，過去我們使用大模型的方式，就像是在面對一個每次對話都會失憶的金魚。為了讓它了解當前的任務進展，開發者只能把之前發生的幾十輪對話記錄、長篇大論的背景資料，一股腦地全部塞進當前請求的 Prompt 里。這種做法不僅極其昂貴，而且隨著上下文越來越臃腫，模型提取關鍵信息的能力會呈斷崖式下降。

技術布道師Lucia Subatin和Jack Wotherspoon走上臺，打開了 Antigravity IDE。他們的任務是解決 Planner 的“失憶癥”。

Jack 敲下了不到 20 行代碼，在 ADK 中為 Planner 引入了Agent Platform Sessions（智能體平臺會話）類。這幾行代碼改變了系統的工作方式：Agent 的運行不再是彼此孤立的請求響應，平臺開始在底層維護一個時間軸，Agent 能夠隨著時間的推移保持狀態，并在當前會話中根據需要修改上下文。

緊接著，他們把 Agent 掛載到了全托管的Memory Bank（記憶庫）服務上。這個服務比單純保存聊天記錄要深得多。當一次馬拉松路線規劃完成后，記憶服務會自動分析整個過程，提取出真正有價值的經驗（比如某個路口的限流教訓），并把它們作為結構化的“長期記憶”存儲下來。

當下次遇到類似的任務時，Planner 就能從 Memory Bank 中精準召回這些經驗。在隨后的演示中，系統重新運行了一次模擬，屏幕上顯示，引入記憶機制后的 Planner 生成了一條與之前截然不同的彩色新路線，因為它回想起了之前一次失敗模擬中暴露的交通堵塞點。

除了讓 Agent 擁有時間維度的記憶，Lucia 還展示了如何把物理世界里的“地方志”裝進 Agent 的腦子里。

拉斯維加斯市有一套繁雜的地方性法規，這些文件格式各異，以非結構化的形式散落在各個系統里。Lucia 沒有手動去整理這些數據，而是向系統里的Data Engineering Agent（數據工程智能體）發送了一個 Prompt，要求它創建一條數據流水線。

這個專注于數據工程的 Agent 迅速響應，利用 Lightning Engine for Apache Spark，拉起了處理任務。它讀取每一份地方法規文檔，調用 Document AI 對文本進行語義級別的智能分塊（Chunking），然后將這些數據塊直接寫入到 AlloyDB 數據庫的表中。

在這里，Lucia 揭示了一個極大降低開發者心智負擔的細節：他們完全沒有編寫任何生成文本向量（Embeddings）的代碼。AlloyDB 內置了自動嵌入功能，只要數據存進來，數據庫就會根據指定的模型自動在后臺計算并生成向量表示。

Lucia 在控制臺里進行了一次語義搜索測試。她輸入了“在拉斯維加斯大道舉辦比賽的限制規定”。系統在向量空間中迅速檢索，返回了一條極其冷門但關鍵的法規：拉斯維加斯公共道路上不允許出現駱駝。

隨著控制臺里傳出一聲駱駝的叫聲，臺下爆發出一陣笑聲。

但這背后的工程意義十分嚴肅。Lucia 通過擴展一個官方技能，將連接 AlloyDB 的檢索工具添加給了 Planner。這就構成了一個完整的 RAG（檢索增強生成）閉環。Planner 從此不再僅僅依賴于基礎模型里那些泛泛而談的常識，它真正具備了對當前任務所處環境的具體、精準的地方性知識。

當崩潰不可避免：在代碼深處進行 AI 級聯排障

就在系統似乎已經完美運轉時，Richard Seroter 在臺上接管了控制權。他點擊了運行按鈕，試圖加載一個包含更多參數的復雜模擬。

突然，刺耳的警報聲響徹全場。屏幕上的進度條卡死，系統崩潰了。

“事情是這樣的，Richard，這不是你的錯。” Emma 在一旁打趣道，“眾所周知，當我們開始引入大語言模型時，系統往往會以意想不到的新方式崩潰。”

這并不是一個為了節目效果而設計的意外，而是多智能體系統在生產環境中極易遭遇的真實夢魘。當無數個 Agent 在后臺互相拋出請求，頻繁調用外部工具，動態更新上下文時，一旦某個環節斷裂，傳統的單步調試和日志搜索將徹底失去作用。你面對的不是一行報 NullPointerException 的代碼，而是一張混亂的調用網。

資深開發者布道師Megan O'Keefe上臺接手了這個局面。她沒有打開龐雜的系統日志去 grep 關鍵字，而是直接進入了 Agent Observability（智能體可觀測性）控制臺。

大屏幕上展示出了一張清晰的 Trace（鏈路追蹤）視圖。這就像是對 Agent 運行過程的 X 光透視。視圖顯示，Simulator 在崩潰前成功調用了多個工具，但在最后一次嘗試向模型發送推理請求時，連接突然中斷了。

面對底層的報錯，Megan 點擊了錯誤日志旁邊的一個按鈕：“啟動 Cloud Assist 調查”。

Gemini Cloud Assist是 Google Cloud 嵌在云端的一個 AI 助手智能體。在一分鐘的調查后，它不僅拉取了日志，還跨越了基礎設施層，查明了真相：Simulator 的崩潰并非邏輯 Bug，而是因為隨著模擬的深入，它積累的歷史上下文和工具調用記錄過于龐大，最終在組裝 Payload 時，超出了 Gemini API 100 萬個上下文 Token 的硬性限制。

更令人驚嘆的是排障的后半段。Megan 切回到 Antigravity IDE 中，她的開發環境通過 MCP 已經和 Cloud Assist 連通。她直接在 IDE 里問：“恢復關于 Simulator 的調查。agent.py里面哪里出錯了？”

Cloud Assist 帶著剛才的診斷結果，一頭扎進了 Megan 本地的源碼里。它很快給出了詳盡的解釋：在 ADK 中，有一個名為 Event Compaction（事件壓縮）的功能，它的作用是讓 Agent 定期調用模型對自己的工作流進行總結，從而把幾萬字的對話壓縮成幾百字的精要，騰出 Token 空間。

Cloud Assist 指出，Megan 雖然開啟了這個功能，但配置的壓縮頻率太低了，導致在面對馬拉松模擬這種高頻密集調用時，上下文還沒來得及壓縮，就已經撐爆了內存。

緊接著，Cloud Assist 在 IDE 里直接彈出了一個代碼 Diff（差異對比）視圖。它建議在agent.py的 Event Compaction 配置塊中，新增一個token_threshold參數，強制系統在達到特定閾值時立刻觸發壓縮。

Megan 審閱了這段代碼，點擊了批準。代碼被直接提交到了版本控制系統，觸發了背后的 CI/CD 流水線。幾分鐘后，修補好 Token 漏洞的 Simulator 重新部署到了 Agent Runtime。同樣的復雜模擬再次運行，這一次，系統在后臺穩穩地處理著龐大的上下文，再也沒有出現崩潰。

這段長達十幾分鐘的排障演示，徹底打破了傳統運維工程師的工作流。當 Bug 隱藏在提示詞、Token 限制和多智能體級聯調用之中時，排障的第一步不再是看代碼，而是讓平臺的診斷 Agent 去和出問題的業務 Agent 對話。診斷不僅給出了根因，甚至直接把帶修復參數的代碼推送到了開發者的面前。

越過應用層：讓 Agent 重構基礎設施

Agent 的能力邊界僅僅停留在改改agent.py的應用邏輯上嗎？

在馬拉松模擬重新跑通后，系統規模進一步擴大。隨著內部測試中跑者數量擴展到數千名，新的問題浮出水面：代表跑者的系統組件響應變得極其遲緩，跑者們在地圖上幾乎停滯不前。

如果說上一次崩潰是應用層的邏輯問題，那么這一次，是底層的物理基礎設施扛不住了。

集團產品經理Bobby Allen站到了大屏幕前。他調出 Cloud Assist 的預先調查報告。報告顯示，問題出在存儲層，當前使用的 GCS Fuse 存儲在加載跑者模型時遭遇了 I/O 瓶頸，無法滿足系統瞬間拉起海量并發容器的速度需求。

Bobby 打開了 IDE。屏幕上顯示的是當前跑者服務在 Cloud Run 上的部署清單（Manifest）。他沒有去查閱 Kubernetes 的部署文檔，也沒有去手動編寫 YAML 文件。他在提示詞框里輸入了一段話：“將此 Cloud Run 服務轉換為 GKE 上的等效服務，并在同一集群中托管一個 Gemma 4 模型。”

Cloud Assist 于是開始扮演一個全棧平臺工程師的角色。它不僅將 Cloud Run 的服務定義準確翻譯成了 Google Kubernetes Engine (GKE) 的部署清單，還自動識別了在 GKE 上運行推理服務的最佳實踐，為新增的 Gemma 4 模型配置了正確的 vLLM 參數和擴縮容策略。同時，針對之前調查出的存儲瓶頸，Cloud Assist 在生成的清單中，自動將掛載的存儲底座從 GCS Fuse 替換成了專為高性能計算設計的 Lustre 并行文件系統。

十幾分鐘后，控制臺顯示架構遷移完成。跑者服務已經穩定運行在 GKE 集群中，而同集群的 Gemma 4 推理服務器也順利拉起。在馬拉松模擬器里，地圖上的光點不僅恢復了流暢的移動，當鼠標懸停在某個跑者身上時，甚至能通過 Gemma 4 模型，看到根據當前心率和配速推演出的跑者“內心獨白”。

“我用我的聲音，告訴 AI 去部署 AI。”Bobby 看著流暢運行的新系統說道。

Agent 的角色不再僅僅是業務流里的一個節點，它開始跨越應用層，深入到基礎設施的骨架里，根據性能指標和運行環境的變化，重構底層資源。

拆除技術棧的高墻：高低代碼在同一張表里匯合

在真實的商業世界里，任何大型項目的落地都離不開跨部門的協作。除了路線規劃，還有海量的物資采購、現場娛樂安排等瑣碎的后勤工作。這些工作往往由不具備編程能力的業務團隊，通過冗長的文檔和表格來推進。

過去，這兩個群體生活在平行的技術世界里。

開發者在 IDE 里寫 Python，業務人員在辦公軟件里填表格。

Google Cloud 數據與分析開發者布道負責人Jason Davenport和產品管理高級總監 Ines Envid 走上臺，演示了平臺如何將這兩個世界縫合在一起。

Jason 登錄了 Gemini Enterprise 應用端。這個面向企業用戶的產品，內置了一個極簡的 Agent Designer（智能體設計器）。他沒有編寫任何代碼，只是在對話框里輸入了一段提示詞，要求系統創建一個精通賽事采購的專家團隊。

Gemini Enterprise 在一分鐘內自動生成了一個包含主調度智能體和多個子領域專家智能體的“供應鏈系統”。為了讓這個新團隊了解背景，Ines 并沒有去配置什么數據連接器，而是直接把那份記錄了馬拉松后勤需求的 Google Drive 文檔鏈接，作為一個變量粘貼到了智能體的上下文中。

接下來發生了整場 Keynote 中最具協作隱喻的一幕。

Jason 回到了之前高代碼開發者用 Python 寫出來的“Planner Agent（規劃師）”的對話界面。他改變了對話焦點，@ 了剛剛用無代碼方式生成的“Supply Chain Agent（供應鏈）”，要求它們共同制定一份包含后勤物資放置點的最終計劃。

很快，屏幕上輸出了一份詳盡的方案。規劃師提供的地理路線節點上，被精準地疊加了供應鏈智能體根據文檔推算出的補水站、香蕉發放點，以及最重要的——移動廁所的位置。

這兩個智能體是如何跨越代碼壁壘對話的？答案還是Agent Registry。

無論是 Mofi 在 IDE 里一行行敲出來的、掛載了復雜 MCP 工具和 Spark 數據流水線的高代碼 Agent，還是 Jason 在網頁端用一段自然語言催生出來的無代碼 Agent，在部署的那一刻，它們都會被平臺一視同仁地注冊進同一個底層的目錄樹里。

在底層的網絡拓撲中，沒有高代碼和無代碼之分，只有各自暴露的能力接口（Agent Card）。這種設計打破了組織內部的技術孤島，業務團隊隨時可以捏出一個輕量級的 Agent，并將它無縫接入到核心工程團隊構建的復雜網絡中。

獨家解讀：Google Cloud 所理解的駕馭工程

從連接外部世界的 MCP 標準，到管理系統狀態的 Sessions 和 Memory Bank；從打破單點瓶頸的 Agent Registry，到讓系統具備自查自糾能力的 Cloud Assist；再到守住底線安全的 Agent Gateway。Google Cloud 在這塊巨大的畫布上，幾乎填滿了生產級多智能體系統所需的所有基礎設施拼圖。

它沒有去過度渲染單個模型在某項跑分測試中又提升了幾個百分點，而是直面了那個最粗糙、最棘手，也最讓開發者頭疼的現實問題：當 AI 從一個聊天的玩具，變成真正介入企業運轉和物理世界模擬的復雜系統時，它到底該怎么平穩地跑下去。

以下是 CSDN 高級副總裁、奇點智能研究院院長李建忠對這場 Keynote 的深度解讀：

Google Cloud 在押注一件事：Cloud Native 的工程范式會轉變為 Agent Native 的工程范式，這個 Agent Native 工程范式的核心其實就是當下熱議的 Harness Engineering（駕馭工程）。

對 Google Cloud 而言，這包括一系列產品工具和工程方法：Agent Platform Sessions 和 Memory Bank 帶來的上下文和記憶管理；Agent Gateway，Agent Registry，A2A Orchestration 等帶來的工具與編排能力；以及 Agent Simulation 帶來的模擬，Gemini Cloud Assist 帶來的調試，Agent Observability 帶來的可觀測性等。

通過這一系列 Agent 家族產品，Google Cloud 完整實現了 Harness Engineering 需要的知道、行動、反饋三部曲。從 Google Cloud 的開發者視角來看，Harness Engineering 不再是一個概念框架，而是一套正在被產品化的工程實踐。

這場 Keynote 宣告了一個明確的信號：手寫膠水代碼、硬編碼 API 對接、在 Prompt 里強塞歷史記錄的“小作坊時代”即將過去。當系統里的計算單元從一行行靜態的指令，變成了能夠自主決策、協同工作的 Agent 時，開發者手中的工具、工作的邊界，以及思考系統架構的方式，都必須迎來一次徹底的重構。

而現在，通往這種全新工程范式的底座和腳手架，已經被搭建起來了。剩下的，就是看全世界的開發者們，能在其上建起怎樣的大廈。

* 本文參與創作 AI：Gemini 3.1 Pro + Nano Banana Pro + NotebookLM

（投稿或尋求報道：zhanghy@csdn.net）