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

Google for Startups AI Agents Challenge 近期評選出數千件全球開發者提交的作品，評審團在三個競賽軌道中發現了一個有趣的現象：許多參賽隊伍聲稱採用多代理系統架構，但深入檢視後發現，其中許多實際上只是單一模型按照一連串提示詞執行，卻被貼上「代理」的標籤。

在眾多參賽作品中，真正在各軌道脫穎而出的作品卻展現出幾個共通的工程決策模式。Google Cloud AI 技術解決方案團隊的 Sergio Villani 基於實際程式碼提交分析出四個值得參考的設計模式，這些都來自真實的參賽隊伍實踐。

模式一：雙向 MCP 通訊——工具化自身推理

大多數參賽作品採用單向的 MCP 使用方式：代理呼叫工具伺服器以取得資料。但有一支隊伍把這做法擴展成雙向架構——他們的代理不僅透過自身的 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 抓出導航意圖，含糊案例透過十個 token、溫度 0.1 的廉價 Gemini 呼叫做意圖分類，只有通過這兩層檢查的請求才會碰到完整推理模型。根據他們的測量，光是第一層就處理了超過 40% 的傳入訊息，之後才會發生真正的模型呼叫。另一支參賽隊伍在不同管線上用了同樣的想法：快速廉價的模型負責把關和分級傳入案例，只把需要深度推理的案例升級給更慢、更貴的模型。不需要在廉價模型就能做出的決策上，浪費最貴的模型。

實踐與組合應用

本輪挑戰中，採用 Agent Development Kit (ADK) 並透過 Agents CLI 驅動的作品最常展現這些模式，主要是因為這個框架在並行、後備或把工具傳給另一個代理這幾件事上不會製造障礙。

這四個模式其實都不需要更大的團隊或更新的模型。它們代表的是常被忽視的健全工程實踐。而且它們組合起來效果不錯，彼此相輔相成。特別是有一支表現突出的隊伍同時結合了模式一和模式三：根代理並行展開專家代理，然後把整個推理層對外暴露為其他代理可以直接呼叫的 MCP 伺服器。