Google AI Agents Challenge 四大工程模式解析

Google for Startups AI Agents Challenge 日前完成評選，全球開發者提交了數千個代理系統參賽。有意思的是，排名最高的團隊靠的不是最強大的模型或最高階的算力，而是四項核心的軟體工程模式。這些模式呈現的是如何透過結構化設計提升系統效能。

雙向 MCP：工具層串起內外連結

大多數參賽者採用單向的 MCP（Model Context Protocol）架構——代理呼叫工具伺服器取得資料。但獲獎團隊把這個概念延伸成雙向運作。他們的代理內部透過 MCP 工具層讀取遙測資料庫，同時把相同的推理邏輯對外開放成 MCP 伺服器，讓其他代理可以直接向它提問，不需要另外設計給人類用的聊天介面。

這個設計的關鍵在於中介資料庫存取。代理如果直接對生產資料庫下 SQL 查詢、把整批資料丟進模型上下文，token 預算很快就會用完。透過 MCP 工具層，代理可以用程式碼檢查、過濾資料，只取回特定工作的執行計畫或堆疊追蹤，而不是整張表，上下文才能維持在可處理的大小。

這個做法也讓對外開放變得安全。只回傳有限、用途明確答案的工具，可以放心交給不受信任的呼叫者；但原始 SQL 連線絕對不行。一旦代理自己的推理已經藏在工具介面後面，對外開放 MCP 伺服器其實就只是在同一組工具前面多架一層伺服器而已。以這個案例來說，在終端機或 IDE 裡運作的編程代理可以直接呼叫效能代理，針對特定工作提問，方式跟呼叫其他工具完全一樣。人類不用開儀表板、在聊天框打字描述問題、再把答案複製回自己的工作流程。聊天介面是終點，MCP 伺服器則可以變成基礎設施，讓其他代理接著往上蓋。

不過有個容易被忽略的細節：一旦開放服務給你無法掌控的呼叫者，這個伺服器就需要真正的存取控制。任何能連到它的人，現在都可以直接呼叫推理層。

非同步事件匯流排：並行反應提升速度

某支團隊最初設計的是線性管線：感測器監控代理呼叫合規性代理，合規性代理呼叫居民傳訊代理，再呼叫派遣代理。這在示範中運作良好，但實際使用時就出問題——系統得同時捕捉步態變化中的跌倒風險、跟即時藥物交互作用資料庫交叉比對、還要在行動時間窗口關閉前把訊息送到正確的人手上。

解法是建構非同步事件匯流排，由四個獨立的 asyncio.Queue 組成，每個代理各配一個，各自有自己的工作協程從佇列裡取資料。這裡不讓代理 A 呼叫代理 B 再等回應，而是讓代理發佈型別化事件到命名主題，各自訂閱自己關心的主題。步態速度下降超過 15% 就會發佈 CLINICAL.ANOMALY_DETECTED 事件。合規性代理早就守在這個主題上，事件一觸發就馬上拿到，去跟藥物交互作用資料庫交叉比對，完成後立刻發佈自己的 CLINICAL.COMPLIANCE_REPORT_READY 事件，不用輪詢間隔，也不用等上游明確交接。傳訊和派遣代理運作方式一樣，各自被訂閱的主題喚醒。

這就是呼叫鏈跟事件匯流排的實質差異：呼叫鏈裡，總延遲是累加的——代理一的耗時加上代理二的再加上代理三的，因為每一個都撐著堆疊等下一個回應。在以主題為基礎的匯流排上，兩個彼此輸出不相依的代理可以同時運作，因為誰都不會卡住誰。當代理各自的節奏差很多時，這個設計最有價值：一個每幾秒就輪詢一次，一個要花半秒做網路呼叫，一個只在最後觸發一次。把這些全部串成單一呼叫堆疊，最快的代理照樣會被最慢的那個拖住。

統一驗證機制：備用模型也要過關

某個臨床推理代理跑在 Gemini 3.1 Pro 上。實際負載一上來，Pro 開始回 503 錯誤。大多數參賽者會對同一個模型加重試迴圈就繼續跑。但這支團隊的做法是備援到 Gemini 3.6 Flash，搭配退避機制，並讓來自任一模型的回應通過完全相同的驗證函數才能被接受：一項引文檢查，確認答案真的指向真實的臨床指南，而不是聽起來像醫學用語就算過關。

關鍵不在於備援機制本身，而在於驗證邏輯放在哪裡。它不是在主要路徑寫一份、備用路徑再寫一份——這樣容易改了一份卻忘了另一份。這裡只存在單一的 validate_clinical_response() 函數，Pro 路徑和 Flash 路徑都被迫在任何結果離開代理前呼叫它。回應一碰到這個函數，不管是哪個模型產生的，都沒有捷徑可走，也不能因為剛好是當時能用的模型就跳過檢查。這才是真正防止備用方案悄悄拉低標準的方法——不是靠記得把同樣標準套用兩次，而是讓結構上根本不可能只套用一次。

分層路由：廉價篩選節省成本

推論成本是 AI 領域吵最多的限制。有一支團隊實測哪些請求真正在吃推論預算，結果發現不是難題，反而是簡單題：「我的訂單在哪」、「取消我的約診」這類問題，走的卻跟真正模糊的請求一樣，完整跑一次模型呼叫。他們的解法是在代理前面架三層分類器：本地正則表達式先攔截，零 token 成本就能捕捉導航意圖；遇到模糊案例則交給便宜的 Gemini 呼叫，耗費十個 token、溫度設 0.1，只用來分類意圖；只有通過這兩層的請求才會進到完整推理模型。光是第一層就在真正的模型呼叫發生前，處理掉超過 40% 的進站訊息。另一個參賽團隊把同樣的概念套用到不同管線：快速便宜的模型負責把關、分類進來的案例，只有真的需要深度推理的才往上送給更慢、更貴的模型。不要拿最貴的模型去做便宜模型就能決定的事。

模式的協同與實踐價值

使用 Agent Development Kit（ADK）並透過 Agents CLI 開發的作品最常出現這些模式，主要因為這個框架在並行處理、備援機制、或把工具交接給另一個代理時，不會擋路。

這四項模式都不需要更大的團隊或更新的模型撐腰。它們代表的是常被忽略的扎實工程做法，而且彼此可以組合互補。有一支特別突出的團隊就結合了模式一和模式三：根代理並行展開多個專家代理，再把整個推理層開放成 MCP 伺服器，讓其他代理可以直接呼叫。