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

Google AI Agents Challenge 揭示四大工程模式

Google for Startups AI Agents Challenge 日前結束，全球數千名開發者提交的應用程式，經評審團在三個賽道中逐一評分。「多代理系統」（Multi-agent Systems）是最多人標榜的類型，但仔細檢查會發現，有些作品其實只是單一模型透過帶代理名稱的提示鏈條在跑，稱不上真正的多代理架構。不過，各賽道中勝出的作品，在軟體工程的決策與作法上有高度一致的共通點。以下整理四個直接來自程式碼提交的關鍵工程實踐。

雙向 MCP：工具即服務

大部分提交案把 MCP（Model Context Protocol）用在單一方向，也就是代理呼叫工具伺服器取資料。得獎團隊則把這個架構做成雙向。這個團隊的代理透過內部的 MCP 工具層讀取遙測資料庫，同時也把同樣的推理能力包裝成 MCP 伺服器，讓其他代理直接呼叫。這樣不用另外做聊天介面給人用，其他代理可以直接發問。

內部介面怎麼設計很重要。如果代理直接對遙測資料庫下 SQL 查詢，把整批資料行塞進模型上下文，很快就會把令牌預算用光。透過 MCP 工具層，代理可以用程式先檢查、篩選資料，只拉回執行計畫或特定的堆疊追蹤，而不是整張表，上下文才不會爆掉。這種透過工具居中存取資料庫的方式，讓對外開放變得可行，也顧到安全性。因為對外暴露的工具只回傳範圍固定、目的明確的答案，比起直接開放原始 SQL 連線，對不受控的呼叫者安全得多。一旦代理的推理已經包在工具介面後面，只要在同一組工具前面架一個 MCP 伺服器就能對外服務。這代表編碼代理可以直接呼叫效能代理，就像呼叫其他工具一樣，中間不需要人插手。要注意的是，一旦要服務不受控的呼叫者，伺服器就必須有嚴格的存取控制。

事件驅動並行：打破線性瓶頸

早期版本大多用線性管線，例如感測器代理呼叫合規代理，再呼叫訊息代理，最後呼叫分派代理。這種架構在展示時沒問題，但真實場景下延遲太高就會出狀況。舉例來說，偵測步態變化以預警跌倒風險時，系統得即時去比對藥物交互作用資料庫並發訊息，線性等待會錯過該行動的時機。

解法是建立一個基於四個獨立 asyncio.Queue 的非同步事件匯流排，每個代理有自己的工作協程從隊列拉任務。代理不再互相呼叫、等對方回傳，而是把類型化事件發布到指定主題，並訂閱自己有興趣的主題。當步態速度下降超過 15%，就會發布 CLINICAL.ANOMALY_DETECTED 事件。合規代理原本就訂閱這個主題，事件一觸發就立刻接手、去比對資料庫，完成後馬上發布 CLINICAL.COMPLIANCE_REPORT_READY 事件，不需要輪詢，也不用上游手動交接。訊息代理和分派代理也是同樣邏輯，由訂閱的主題喚醒，而不是被直接呼叫。

在呼叫鏈裡，總延遲是一路累加的，因為每個代理都要等下一個代理回傳。而在以主題為基礎的匯流排裡，彼此輸出不相依的代理可以並行跑，因為互不阻塞。這種架構特別適合代理跑在不同節奏上的情境，像是每隔幾秒輪詢一次的、需要半秒網路呼叫的、或只在最後觸發一次的任務。如果把所有東西串進單一呼叫堆疊，最快的代理還是會被最慢的那個拖累。

統一驗證：後備模型不降標

在臨床推理代理的實作中，主力模型 Gemini 3.1 Pro 在高負載時開始回傳 503 錯誤。多數團隊的作法是對同一個模型加重試迴圈，但得獎團隊改用 Gemini 3.6 Flash 當後備，並搭配退避策略。重點是，不管回應來自哪個模型，都得通過同一個驗證函數才會被接受。這個驗證函數會做引用檢查，確認答案真的引用了實際的臨床指南，而不是聽起來像那麼回事的醫學用語。

驗證邏輯沒有為主要路徑和後備路徑各寫一份，而是只有一個 validate_clinical_response() 函數。Pro 和 Flash 兩條路徑的結果，在離開代理前都得強制通過這個函數。這樣一來，不管哪個模型產生答案，都沒有捷徑可走，也不會因為那個模型當下剛好可用，就把沒通過檢查的答案送出去。這種結構性設計，防止後備機制在背後偷偷降低品質標準，避免「只測試一個產品，卻送出兩個不一樣的產品」這種風險。

分層路由：低成本過濾

推理成本是 AI 開發的一大限制。團隊發現真正吃掉推論預算的不是難題，而是簡單查詢，像是「我的訂單在哪裡」或「取消預約」，這些跟真正模糊的請求一樣，都跑了一整套完整的模型呼叫。解法是在代理前面加三層分類器：第一層是本地正則表達式檢查，零令牌成本就能抓到導航類意圖；第二層是低成本的 Gemini 呼叫（溫度 0.1），只做意圖分類；只有通過這兩層的請求才會進到全功能推理模型。實測第一層就處理掉超過 40% 的進入訊息，在真正的模型呼叫發生之前就攔下來了。另一個實作則用快速、便宜的模型當閘道，只把需要深度推理的案例升級到較慢、較貴的模型。

這些模式最常出現在用 Agent Development Kit（ADK）、透過 Agents CLI 驅動的提交案中，因為這個框架不會擋住並行、後備處理或工具共享。這些做法不需要更大的團隊或更新的模型，比較像是常被忽略的基礎工程功夫，而且彼此組合起來效果不錯。舉例來說，有團隊把並行分派多個專家代理，跟把整個推理層包成 MCP 伺服器對外開放這兩種做法結合在同一個作品中。