ADK Go 入門 06 - 多 Agent 架構設計

當系統複雜度提升,單一 Agent 難以兼顧所有職責。ADK 支援多 Agent 協作,透過樹狀結構組織各個專責 Agent,讓系統兼具清晰的分工與彈性的路由。


為什麼需要多 Agent

  • 能力邊界清晰:航班 Agent 只懂航班,住宿 Agent 只懂住宿
  • 工具隔離:每個 Agent 只持有必要的工具,降低誤用風險
  • Instruction 精簡:職責單一的 Agent,規則更好寫也更好維護
  • 平行擴充:新增功能只需加新 Agent,不影響現有邏輯

樹狀結構:ADK 的硬性限制

ADK 強制採用樹狀架構,每個 Agent 只能有一個父節點。

1
2
3
4
5
root_agent(路由決策)
├──→ flight_agent(航班查詢與訂票)
│ └──→ price_agent(比價分析,作為 tool)
├──→ hotel_agent(住宿預訂)
└──→ weather_agent(目的地天氣,作為 tool)

⚠️ 不能有多個父節點:若 flight_agenthotel_agent 都需要 weather_agent,不能讓兩者同時把它列為 SubAgent。應改為:把 weather_agent 掛在共同的父節點,或改用 agenttool 包裝。

transfer_to_agent:移交控制權

當 Agent 判斷某個請求超出自己職責,可以呼叫 transfer_to_agent 將整個對話移交給另一個 Agent。

移交後:

  • 目標 Agent 接手對話,取得完整的對話歷史
  • 目標 Agent 完成後,控制權會回到上層

這個機制由 ADK 框架自動處理,不需要手動傳遞 session。

路由 Agent 的設計原則

根 Agent(root agent)通常只做路由,不持有業務工具:

1
2
3
4
5
6
7
使用者:「幫我查一下台北到東京的航班」

root_agent 分析意圖

└──→ transfer_to_agent("flight_agent")

flight_agent 查詢航班並回應

根 Agent 的 Instruction 應該:

  1. 列出所有子 Agent 的職責描述
  2. 說明何時移交給哪個 Agent
  3. 說明無法判斷時的處理方式

Sub-Agent vs agenttool

兩種讓 Agent 呼叫另一個 Agent 的方式:

方式 機制 適合場景
SubAgents + transfer 移交整個對話 完全由子 Agent 主導後續對話
agenttool.New() 呼叫後取回結果 子 Agent 作為某個步驟的執行者

選擇原則:子 Agent 需要主導對話?用 transfer。只是取得一個結果?用 agenttool。