google/adk-python 2.0：以程式碼為核心的 Agent 框架，Graph 工作流與 Task API 是重點
An open-source, code-first Python toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
秒懂
- 它是什麼？
- Google 的 ADK Python 套件在 2.0 版引入圖形化工作流與 Task API，強調以程式碼定義 Agent 行為。本文解析其架構、安裝方式、限制，並與其他框架的差異。
- 適合誰用？
- 採用者應是熟悉 Python 且需要精確控制 Agent 流程的團隊，特別是已使用 Gemini 或 Google Cloud 生態者。若你偏好 YAML 或視覺化編輯器，或需要與 LangGraph 的既有生態整合，則此框架可能不是首選。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
ADK 2.0 解決的問題：從單一 Agent 到可編排的系統
ADK 2.0 解決的問題是單一 Agent 無法應付的複雜流程。它用 Workflow 這個圖形執行引擎，讓開發者定義節點之間的邊，例如產生水果名稱後，再交給另一個 Agent 說明健康益處。這不是新的概念，但 ADK 把它放進官方 API 的第一層，而非事後外掛。目標使用者是那些需要把 Agent 流程當作程式碼來版本控制、測試和部署的 Python 工程師。相較於純提示詞驅動的框架，ADK 強調明確的資料流與狀態管理。
Workflow 與 Task API：兩種不同的編排機制
ADK 2.0 提供兩種互補的編排方式。Workflow 是圖形化的，你定義邊，例如 edges=[("START", generate_fruit_agent, generate_benefit_agent)]，這表示從起點開始，依序執行兩個 Agent。它支援路由、fan-out/fan-in、迴圈、重試、狀態管理、動態節點和巢狀工作流。另一種是 Task API，它讓 Agent 之間進行結構化的委派，支援多輪任務模式、單輪受控輸出、混合委派模式，以及把任務 Agent 當作工作流節點。兩者的差異在於：Workflow 適合確定性的執行順序，Task API 適合需要來回溝通的場景。文件顯示 Task API 還包含 human-in-the-loop，這意味著你可以讓使用者確認某個工具呼叫後才繼續。這種設計把控制權交給開發者，而不是讓模型自行決定流程。
安裝與執行：pip 套件與 CLI 工具
安裝方式直接，pip install google-adk 即可，但官方建議搭配 constraints 檔案來保護傳遞相依性。你需要先下載對應 Python 版本的 constraints 檔案，例如 Python 3.10 就執行 curl -o constraints-3.10.txt https://raw.githubusercontent.com/google/adk-python/main/constraints-3.10.txt，然後用 pip install google-adk -c constraints-3.10.txt 安裝。這表示專案對相依性管理相當謹慎，但對初學者來說多了一步。執行時有兩種方式：互動式 CLI 用 adk run path/to/my_agent，Web UI 用 adk web path/to/agents_dir，後者支援多 Agent 目錄或直接指向單一 Agent 資料夾。開發 UI 內建於套件，可測試、評估和除錯。值得注意的是，套件要求 Python 3.10 以上，但沒有提到上限，而 constraints 檔案涵蓋 3.10 到 3.14，這暗示你必須注意版本相容性。
2.0 的破壞性變更：Session 架構與向後相容性的代價
README 明確標示 2.0 有 breaking changes，涉及 agent API、event model 和 session schema。最關鍵的資訊是：ADK 2.0 產生的 session 可以被 ADK 1.28 以上的版本讀取，因為額外欄位會被忽略，但與更舊的 1.x 不相容。這代表如果你有長期儲存的 session 資料，升級前必須檢查版本。對開發者而言，這意味著 2.0 不是單純的 feature release，而是需要修改現有程式碼的重大升級。文件沒有詳細列出每個 API 變更，但你可以預期 event 處理邏輯和 session 儲存方式需要調整。這種做法在快速演進的框架中常見，但對生產環境的穩定性是一個風險。如果你依賴舊版 session 資料做分析或稽核，升級前最好先備份並測試讀取相容性。
工具生態與部署選項：MCP、OpenAPI 與 Google Cloud 綁定
ADK 宣稱支援多種工具來源，包括預建工具、自訂函式、OpenAPI 規格和 MCP 工具。這對需要整合外部 API 的應用是關鍵。文件強調與 Google 生態系的緊密整合，這既是優點也是限制。部署方面，ADK 可以容器化並部署到 Cloud Run，或透過 Vertex AI Agent Engine 擴展。這表示如果你已經在 Google Cloud 上運行服務，整合會很順暢。但如果你偏好 AWS 或自建 Kubernetes，文件沒有提供官方指引，你必須自己處理容器映像與環境變數。另外，工具確認流程（HITL）是內建功能，可保護工具執行，這對需要人為審核的金融或醫療應用有價值。整體而言，工具生態是完整的，但「tight integration with the Google ecosystem」這句話暗示了預設路徑是 Google 服務。
與其他框架的差異：程式碼優先 vs 設定檔驅動
ADK 的定位是 code-first，這與 LangGraph 類似，兩者都用圖形來定義流程。但差異在於 ADK 提供 Agent Config 功能，讓你可以用非程式碼方式建立 Agent。這是一個有趣的折衷：你可以在 Python 中寫死邏輯，也可以切換到設定檔。LangGraph 則依賴 LangChain 生態，而 ADK 是獨立實作，且與 Gemini 最佳化。另一個對比是微軟的 Semantic Kernel，它強調規劃器與記憶體抽象，但 ADK 的 Workflow 更接近傳統的 DAG 排程器。如果你需要與 LangChain 的工具鏈整合，ADK 的 MCP 支援是標準做法，但沒有提供 LangChain 的專屬 adapter。對已經投資 LangGraph 的團隊，遷移成本會很高，因為 event model 和 session 管理完全不同。
維護與升級成本：釋出節奏與版本分裂的風險
README 提到釋出節奏大約是雙週一次，這在開源專案中算是頻繁。從版本記錄看到 v1.39.1 和 v2.8.0 同時並存，這暗示專案可能同時維護 1.x 和 2.x 兩條線。對採用者來說，頻繁釋出意味著 bug 修正很快，但也代表你需要持續追蹤更新。官方建議使用 constraints 檔案，這本身就是對依賴爆炸的防禦措施。升級成本主要來自 2.0 的 breaking changes，你必須重寫部分程式碼。另外，開發版本可以從 GitHub main 分支安裝，但文件警告可能包含實驗性功能，這對想提前試用新功能的人有吸引力，但不適合生產。授權是 Apache-2.0，這對商業使用友善，沒有 copyleft 限制，你可以自由修改和整合。整體而言，維護成本取決於你多頻繁更新，但雙週節奏需要自動化依賴更新流程。
編輯結論
採用者應是熟悉 Python 且需要精確控制 Agent 流程的團隊，特別是已使用 Gemini 或 Google Cloud 生態者。若你偏好 YAML 或視覺化編輯器，或需要與 LangGraph 的既有生態整合，則此框架可能不是首選。先驗證你的 Python 版本是否在 3.10 至 3.14 之間，並確認既有 Session 資料能相容於 2.0 的 schema 變更。若你從 1.x 升級，務必測試所有 agent 與 event 處理程式碼，因為 breaking changes 會影響 session 讀取。最後，檢查你需要的 MCP 或 OpenAPI 工具是否在官方文件中有完整範例，因為 README 並未提供詳細整合步驟。
社群筆記