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

Google for Startups AI Agents Challenge 近期落幕，全球數千位開發者參賽，提交多代理系統方案。評審過程中，評選團隊發現「多代理系統」這個說法被頻繁提及，但實際檢視後發現，部分作品其實不是真正的多代理架構，只是單一模型透過連鎖式提示詞、套上不同代理名稱做出來的效果。不過排名前段的作品倒是展現出一致的工程決策模式，值得其他開發者參考。

模式一：雙向 MCP——讓工具變成基礎設施

大多數參賽作品用的是單向 MCP 架構，也就是代理呼叫工具伺服器拿資料。有一支團隊則把它做成雙向：代理本身透過 MCP 工具層存取遙測資料庫，同時把同一套推理邏輯包裝成 MCP 伺服器，讓其他代理可以直接呼叫。

這個設計的重點在於資料存取要經過中介。沒優化過的做法是把資料庫查詢結果直接倒進模型的上下文裡，在正式環境用起來很快就會把 token 預算燒光。透過 MCP 工具層，代理可以先用程式篩選資料，只回傳特定的執行計畫或堆疊追蹤，而不是整張資料表，這樣上下文的規模才能維持在可推理的範圍內。

當工具介面只回傳有限、目的明確的答案時，把它開放給外部呼叫者才安全。作者舉例，編程代理可以直接呼叫效能代理的工具，問特定工作的狀態，不用人類先開儀表板、在聊天框打字描述問題、再把答案複製回工作流程。MCP 伺服器因此變成能被其他代理拿來用的基礎設施，不只是給人看的介面。

實施要點：雙向 MCP 帶來的代價是必須做存取控制。伺服器一旦開放給非信任的呼叫者，任何摸得到伺服器的人都能直接呼叫推理層，這就要求要有完整的權限驗證機制。

模式二：非同步事件匯流排——打破線性管道的延遲

另一支團隊一開始做的是線性管道：感測器監測代理呼叫合規性代理，合規性代理呼叫住戶通知代理，最後呼叫派遣代理。這個方案在演示時運作得很順，但一遇上真實場景——捕捉步態改變引起的跌倒風險、交叉比對即時藥物交互作用資料庫、要在行動時機窗口關閉前送出通知——就整個垮掉。

解決方式是建一個基於四個獨立 `asyncio.Queue` 的非同步事件匯流排，每個代理各配一個佇列，搭配各自的工作協程。代理不再直接呼叫彼此、等對方回傳結果，而是把型別化事件發佈到命名主題，各自訂閱自己在意的主題。舉例來說，步速下降超過 15% 會發佈 `CLINICAL.ANOMALY_DETECTED` 事件，已經在監聽這個主題的合規性代理會立刻收到，交叉比對藥物交互資料庫後再發佈 `CLINICAL.COMPLIANCE_REPORT_READY` 事件，下游的通知和派遣代理就依各自訂閱的主題被喚醒。

延遲差異很關鍵：呼叫鏈的做法中，總延遲是累加的——代理一的時間加代理二再加代理三，因為每個代理都得在堆疊上等下一個。用主題匯流排的話，沒有相依關係的代理可以同時執行，彼此不會互相卡住。當代理的執行節奏差異很大時（一個每幾秒輪詢一次、一個要做半秒的網路呼叫、一個只在最後執行一次），這個優勢特別明顯。線性堆疊會讓最快的代理也被最慢的那個拖累。

模式三：統一驗證機制——防止降級

某團隊的臨床推理代理跑在 Gemini 3.1 Pro 上。實際負載一上來，Pro 開始回傳 503 錯誤。多數參賽作品的做法是針對同一模型加個重試迴圈了事。這個團隊則是改用 Gemini 3.6 Flash 做降級方案，搭配退避策略，但關鍵在於：兩個模型的回應在被接受之前，都要通過同一套驗證函式——一個引用檢查，確認答案真的引用了實際的臨床指南，而不是聽起來像那麼回事的醫學用語。

驗證邏輯沒有在主路徑和降級路徑各留一份副本（這樣容易改了一份忘了改另一份），而是只有一個 `validate_clinical_response()` 函式，強制兩條路徑都要呼叫它。不管哪個模型產生回應，都跳不過這個檢查，也不會因為某個模型剛好在請求進來時可用，就被放過驗證。

用結構上的約束比事後靠人記得更可靠：真正能防止降級偷偷降低標準的，不是靠人記得要驗證兩次，而是讓「只驗證一次」這件事在結構上根本做不到。

模式四：分層路由——昂貴呼叫前先篩選

推理成本是目前討論的焦點：開發者想要前沿模型的推理能力，卻不想每個請求都付前沿模型的價錢。有一支參賽團隊把分層成本優化這個模式用得不錯。

他們測量後發現，預算消耗大多不是花在難題上，而是簡單問題：「我的訂單在哪」、「取消我的預約」這類問題，居然跟真正模糊的請求一樣，都跑完整套模型呼叫。解法是在代理前面放三層分類器：本地正規表達式在零 token 成本下攔截導航類意圖，模糊案例則用低溫度（0.1）的便宜 Gemini 呼叫、花十個 token 做意圖分類，只有通過前兩層篩選的請求才會碰到完整的推理模型。他們測出光是第一層就處理了超過 40% 的傳入訊息，這些訊息根本沒觸發任何模型呼叫。另一支參賽隊伍在不同的管道上用了同樣的想法：用快速、便宜的模型把關分流，只有真的需要深度推理的案例才升級到更慢、更貴的模型。道理很簡單：便宜模型能做的決策，不需要動用最貴的模型。

四大模式的互補性

文章指出，用 Agent Development Kit（ADK）搭配 Agents CLI 的參賽作品最常出現這些模式，主要是因為這個框架在並行處理、降級機制、代理間工具共享上都沒有架構上的阻力。

這四個模式不需要更大的團隊或更新的模型，代表的是常被忽略的紮實工程實踐。它們彼此可以組合互補。