部署多代理系統：先確認真的需要拆
課程概述
任務複雜，不代表第一步就要拆成多個 Agent。多一個 Agent，也會多一段延遲、模型費用、狀態交接和失敗路徑。真正適合拆分的情況，通常是工作有清楚的專業邊界、需要不同工具權限、能夠平行處理，或必須把某段故障隔離。這堂課會先判斷該不該拆，再用 ADK 的工作流程與子 Agent 組合任務，最後對上現在稱為 Agent Runtime 的受管部署環境。
Sequential 適合有明確前後關係的工作，Parallel 適合彼此獨立的分析，動態委派則由協調 Agent 選擇下一棒。Runtime 能處理部署、擴縮與受管 Session，但重試、循環上限、交接驗證和人工核准仍要寫進應用流程。
你將學到
- 判斷單一 Agent、固定工作流程與多代理系統的適用時機
- 使用 ADK 的 Sequential、Parallel、Loop 與子 Agent 委派
- 為每次交接定義輸入、輸出、完成條件與責任人
- 分開 Session State、共享 Artifact 與每個 Agent 的私有權限
- 在 Agent Runtime 追蹤跨 Agent 延遲、工具呼叫與失敗路徑
核心概念
為什麼需要多個 Agent？
單一 Agent 如果同時看到太多互相相似的 Tool、規則與資料，路由和權限會變得難以測試。把研究、分析、寫作或核准拆開，可以讓每個單元只拿需要的工具和上下文，也比較容易單獨評估。不過，如果任務只是固定三步驟，一段普通程式或 ADK Workflow Agent 往往比讓 LLM 動態分派更穩定。多代理不是能力升級按鈕，而是一種成本更高的架構選擇。
三種編排模式
| 模式 | 運作方式 | 適用情況 |
|---|---|---|
| Sequential（循序） | 按固定順序執行，每一步接收上一個可驗收輸出 | 研究 → 撰寫 → 審核等明確流水線 |
| Parallel（平行） | 各分支獨立執行，再由明確規則或 Aggregator 合併 | 多來源查核、彼此不相依的分析 |
| Loop（迴圈） | 重複一組步驟，直到通過條件或到達上限 | 產出 → 檢查 → 修正，但必須有停止條件 |
| 動態委派／階層式 | 協調 Agent 依能力描述選子 Agent，必要時再轉交 | 路徑無法事先寫死、專業與權限邊界明確 |
Agent 之間要交接可驗收的工件，而不只是自由文字。能力描述幫 Supervisor 選擇負責人；目標、輸入、輸出格式與完成條件則讓下一棒知道能否安全接手。
ADK 中的委派機制
ADK 可用 sub_agents 建立父子關係，讓模型依名稱與能力描述轉移控制；也能用 Workflow Agent 寫死 Sequential、Parallel 或 Loop，或把另一個 Agent 包成 Tool。能確定的路徑盡量用程式化流程，只有真的需要語意判斷時才交給模型路由。能力描述若重疊，協調 Agent 就容易選錯；高風險工具也不應因為轉交而繼承過大的權限。
Agent Engine 已改名 Agent Runtime
官方版本說明已將 Agent Engine 改名為 Agent Runtime。它是 Gemini Enterprise Agent Platform 的受管執行環境，完整整合 ADK，也能透過範本支援其他框架。Runtime 可以提供：
- 受管部署、擴縮與自訂 Container
- Agent Platform Sessions，以及視需求另外設定的 Memory Bank
- Cloud Logging、Trace、Monitoring 等可觀測性整合
- 透過 Agent Identity、Registry 與 Gateway 接入治理能力
它不會自動替應用決定交接契約、重試語意或 A/B 成功條件。Cloud Run 與 GKE 也仍是合法部署選項；應依長任務、網路、Container、自訂基礎設施和團隊維運能力選擇，而不是看到「全代管」就一律使用。
Agent 間的狀態共享
同一個 ADK Session 裡的 Agent 可以透過 State 交換小型、結構化資料，但不該把所有 Prompt、私有記憶和大型輸出全塞在一起。研究報告、附件或中間資料集適合存成 Artifact，再透過 ID、版本與摘要交接。平行分支若會寫同一個 Key，也要事先定義合併規則，否則完成順序一變，結果可能就不一樣。
共享的是有版本、能驗收的工件，不是整包私有記憶、過度權限或故障。每個執行單元應能獨立逾時、重試、替換與撤銷；跨服務 Agent 則可評估 A2A，而不是假設大家共用同一份記憶體。
流程圖暫時無法顯示，請重新整理頁面後再試。
實作重點
- 先做單一 Agent／固定 Workflow 基準，再證明多 Agent 的成功率或延遲值得增加的複雜度
description要寫出能力邊界與不能做的事，並準備容易混淆的路由測試- 所有交接使用結構化 Schema，驗證完成條件後下一棒才能接手
- 平行分支避免寫同一個 State Key；大型成果改用 Artifact 與版本 ID
- 新版可用 Agents CLI 部署到 Agent Runtime、Cloud Run 或 GKE；依賴與 Container 都要固定版本
- Trace 應追蹤 Agent、Tool、輸入輸出摘要、延遲與錯誤，不記錄 Secrets 或宣稱看見完整思考
Lab 導讀
Lab 連結：Deploy Multi-Agent Systems with ADK and Agent Engine — Google Cloud Skills Boost
這個 Lab 會做出資料查詢、分析與報告生成三個子 Agent。教材若仍寫 Agent Engine，現在對應的是 Agent Runtime。操作時除了觀察主 Agent 如何分派，也請把其中一個子 Agent 故意弄成逾時或回傳錯誤格式，確認責任歸屬、重試上限與最後的降級回應都看得懂。
延伸學習
- Agent Development Kit 開發實戰 — 先掌握單一 Agent 的基礎
- Vertex AI MLOps 模型評估 — Agent 部署後的監控與評估
- Generative Playbooks 建構代理 — 另一種 Agent 建構方式
相關文章
您可能也會對這些文章感興趣
部署多代理系統：先確認真的需要拆
用 ADK 設計循序、平行與動態委派流程，建立可驗收的交接契約、狀態邊界與故障隔離，再部署到 Agent Runtime
Agent Development Kit：從工具呼叫到可部署 Agent
用 ADK 把模型、工具、Session 與 Runner 組成可測試的 Agent，並補齊權限、錯誤處理、評估與部署前檢查
AI Agent 安全：別只叫模型「不要洩密」
從 Prompt Injection、工具越權與資料外洩，到 Model Armor、IAM、VPC Service Controls 和人工核准的分層防禦
