部署多代理系統：先確認真的需要拆

課程概述

任務複雜，不代表第一步就要拆成多個 Agent。多一個 Agent，也會多一段延遲、模型費用、狀態交接和失敗路徑。真正適合拆分的情況，通常是工作有清楚的專業邊界、需要不同工具權限、能夠平行處理，或必須把某段故障隔離。這堂課會先判斷該不該拆，再用 ADK 的工作流程與子 Agent 組合任務，最後對上現在稱為 Agent Runtime 的受管部署環境。

你將學到

• 判斷單一 Agent、固定工作流程與多代理系統的適用時機
• 使用 ADK 的 Sequential、Parallel、Loop 與子 Agent 委派
• 為每次交接定義輸入、輸出、完成條件與責任人
• 分開 Session State、共享 Artifact 與每個 Agent 的私有權限
• 在 Agent Runtime 追蹤跨 Agent 延遲、工具呼叫與失敗路徑

核心概念

為什麼需要多個 Agent？

單一 Agent 如果同時看到太多互相相似的 Tool、規則與資料，路由和權限會變得難以測試。把研究、分析、寫作或核准拆開，可以讓每個單元只拿需要的工具和上下文，也比較容易單獨評估。不過，如果任務只是固定三步驟，一段普通程式或 ADK Workflow Agent 往往比讓 LLM 動態分派更穩定。多代理不是能力升級按鈕，而是一種成本更高的架構選擇。

常見的編排模式

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

ADK 中的委派機制

ADK 可用 sub_agents 建立父子關係，讓模型依名稱與能力描述轉移控制；也能用 Workflow Agent（ADK 文件也稱 template workflows）寫死 Sequential、Parallel 或 Loop，或把另一個 Agent 包成 Tool。ADK 文件寫明，從 ADK 2.0 起（Python 與 Go），template workflows 已被更有彈性的 graph-based workflows 與 dynamic workflows 取代，新專案可以一併評估。能確定的路徑盡量用程式化流程，只有真的需要語意判斷時才交給模型路由。能力描述若重疊，協調 Agent 就容易選錯；高風險工具也不應因為轉交而繼承過大的權限。

Agent Engine 已改名 Agent Runtime

官方版本說明已將 Agent Engine 改名為 Agent Runtime。它是 Gemini Enterprise Agent Platform（簡稱 Agent Platform，原 Vertex AI）的受管執行環境，完整整合 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，也要事先定義合併規則，否則完成順序一變，結果可能就不一樣。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  START["先把任務、成功條件<br/>工具與風險列出來"] --> FIXED{"步驟與順序<br/>可以事先確定嗎？"}
  FIXED -->|"可以"| WORKFLOW["先用程式<br/>或 ADK Workflow<br/>Sequential／<br/>Parallel／Loop"]
  FIXED -->|"不完全確定"| BOUNDARY{"是否有清楚的專業、權限<br/>或故障隔離邊界？"}
  BOUNDARY -->|"沒有"| SINGLE["維持單一 Agent<br/>縮小 Tool<br/>與 Instruction"]
  BOUNDARY -->|"有"| CONTRACT["替每個 Agent 定義能力<br/>輸入、輸出與完成條件"]
  CONTRACT --> PARALLEL{"子任務彼此獨立<br/>而且合併規則明確嗎？"}
  PARALLEL -->|"是"| PAR["平行執行<br/>由 Aggregator<br/>驗收合併"]
  PARALLEL -->|"否"| DELEGATE["循序或動態委派<br/>每次交接都<br/>驗證工件"]
  WORKFLOW --> TEST["測正常、超時、重試<br/>循環、部分失敗與取消"]
  SINGLE --> TEST
  PAR --> TEST
  DELEGATE --> TEST
  TEST --> SHIP["比較成本與成功率後<br/>再決定是否部署"]

實作重點

• 先做單一 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 Gemini Enterprise Agent Platform（原名 Deploy Multi-Agent Systems with Agent Development Kit (ADK) and Agent Engine）— Google Skills

課程頁目前列出六個 Lab：ADK 入門、替 Agent 加上工具、用 sub_agents 組多代理系統、部署到 Agent Runtime、把 ADK Agent 加進 Gemini Enterprise（原 Google Agentspace），以及用 Agent Platform 的評估服務評估 Agent。教材若仍寫 Agent Engine，現在對應的是 Agent Runtime。操作時除了觀察主 Agent 如何分派，也請把其中一個子 Agent 故意弄成逾時或回傳錯誤格式，確認責任歸屬、重試上限與最後的降級回應都看得懂。

延伸學習

• Agent Development Kit 開發實戰 — 先掌握單一 Agent 的基礎
• Agent Platform（原 Vertex AI）模型評估 — Agent 部署後的監控與評估
• Generative Playbooks 建構代理 — 另一種 Agent 建構方式