adk-go 評測：以 Go 寫 AI Agent 的程式碼優先框架，彈性與代價並存
An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
秒懂
- 它是什麼？
- Google 的 Agent Development Kit 提供 Go 版本，主打程式碼優先、模型中立與多 Agent 協作。本文檢視其設計取向、實際上手流程，以及選擇它之前該想清楚的取捨。
- 適合誰用？
- adk-go 適合已經用 Go 打造雲端服務、想要把 Agent 邏輯直接寫進既有程式碼庫的團隊。它不適合需要快速原型、偏好 YAML 或視覺化流程編輯器的人，那類需求在 Python 版 ADK 或其他框架上更順手。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
把 Agent 當程式寫，而不是當設定檔寫
adk-go 的核心主張是 code-first。意思是 Agent 的邏輯、工具與編排方式全部用 Go 程式碼表達，不走 JSON 或 YAML 描述路線。這對從 Python 版 ADK 過來的人會是明顯差異，Python 版允許用 YAML 定義 Agent，Go 版則把一切收進型別系統裡。好處是編譯時期就能抓出一批錯誤，重構時有編譯器撐腰，程式碼版本控制也直接套用既有流程。代價是彈性變成以 Go 的型別系統為邊界，想動態生成 Agent 結構會比直譯語言麻煩。README 強調它適合打造雲端原生應用，這說法合理，Go 的 goroutine 併發模型在處理多 Agent 同時等待 LLM 回應時，確實比 callback 地獄或執行緒管理省事。但要注意，README 沒有提供任何效能數據，所謂的 Go 優勢目前停留在語言特性層面的論述。
模組化多 Agent：組合的單位是程式碼
專案把多 Agent 系統描述為「組合多個專門 Agent 來設計可擴充應用」。這句話的實際意義在於，Agent 之間的合作不是透過外部編排服務，而是在 Go 程式裡以型別組合。你可以把一個負責讀取客戶問題的 Agent、一個負責查資料庫的 Agent、一個負責生成報告的 Agent 各自寫成獨立模組，再用框架提供的機制把它們接起來。這種做法讓每個 Agent 可以獨立測試，這是程式碼優先路線的直接紅利。但 README 對 Agent 之間如何傳遞狀態、如何處理部分失敗、有無重試或逾時內建機制，完全沒有著墨。對一個要上生產的系統來說，這些問題比「能不能把 Agent 組合起來」更關鍵。文件首頁提到的 A2A 協定出現在 topics 清單，但 README 內文沒解釋它與多 Agent 編排的關係，這塊需要靠原始碼或進階文件補足。
安裝與第一個 Agent：指令簡單，但版本訊號混亂
安裝只有一條指令：go get google.golang.org/adk/v2。套件路徑帶有 v2 前綴，代表模組主版本宣告為 2。實際撰寫 Agent 的程式碼範例在 README 中沒有出現，文件指引讀者去看 adk.dev/llms.txt 或 adk.dev/llms-full.txt，這兩個檔案是給 AI 編碼代理讀的機器可讀文件。這種做法在 2026 年不算罕見，但它透露一個訊息：這個專案預設你的開發流程裡有 AI 輔助工具。對傳統 Go 開發者來說，跳去讀一個 llms-full.txt 再叫 AI 生成程式碼，與直接看範例目錄是兩種不同的上手路徑。範例程式碼放在 GitHub 的 examples 資料夾，但 README 沒有提供任何片段。版本訊號值得警惕，同一時間點存在 v1.6.1 與 v2.3.0 兩個近期版本，release 日期只差一週。這代表專案同時維護兩條主版本線，或者正在進行重大遷移。對採用者而言，鎖定哪個主版本需要先確認，否則 go get 可能拉到你不想用的 API 世代。
工具生態與模型中立：口號與現實的差距
README 列出三個賣點：預建工具、自訂函式、整合既有工具。同時宣稱模型中立且部署中立。模型中立的意思是 Agent 不綁死 Gemini，但 README 也承認它對 Gemini 做了最佳化。這兩個陳述並存時，務實的讀法應該是：Gemini 路徑最順，其他模型要走相容層。文件沒有列出支援哪些模型供應商，也沒有說明自訂模型需要實作什麼介面。工具整合方面，MCP 出現在 topics 清單，代表專案可能支援 Model Context Protocol，但 README 內文完全沒提。對一個想接公司內部既有工具的團隊，MCP 支援與否是決定性因素，這塊資訊的缺席是文件品質的明顯缺口。以 Apache-2.0 授權釋出代表你可以改原始碼補足這些洞，但前提是你願意維護一個 fork，這是採用開源框架的隱形成本。
部署論述：容器化容易，但生產細節留白
專案強調可以容器化部署，並點名 Google Cloud Run 作為雲端環境的例子。這與 Go 的靜態編譯特性契合，單一 binary 丟進容器確實比直譯語言打包省事。但 README 對部署的敘述僅止於此，沒有提到如何處理 API 金鑰、如何設定模型端點、有沒有提供健康檢查端點、log 格式為何。對 Cloud Run 使用者來說，這些是部署一個服務的基本需求，文件卻沒有給出方向。以這個專案釋出的頻率來看，v1.6.1 在 2026 年 9 月 7 日、v2.3.0 在 8 月 31 日，更新速度很快，這對部署穩定性的影響是雙面的。頻繁釋出代表 bug 修得快，但也代表 API 可能持續變動。生產環境鎖定版本是基本動作，而這個專案因為雙版本並行，鎖定時要額外確認你追蹤的是哪一條線。
授權細節與維護成本：Apache-2.0 之外的例外
整體授權是 Apache-2.0，商用友善。但 README 特別標註一個例外：internal/httprr 目錄使用獨立授權檔。這個目錄名稱暗示它是 HTTP request recorder 或 replay 工具，可能用於測試。問題在於 internal 路徑在 Go 裡代表無法被外部套件匯入，所以一般使用者不會直接碰到它。但如果你的團隊會 fork 整個倉庫或複製內部工具程式碼，就必須檢查該目錄的授權條款是否與 Apache-2.0 相容。維護成本方面，這個專案的文件策略值得注意，它把主要文件放在 adk-docs 倉庫，並產生 llms.txt 給 AI 代理讀。這代表文件更新與程式碼釋出是兩條獨立管線，文件落後程式碼的風險存在。採用者要準備的是：升級套件時，不能只看 README，要對照 pkg.go.dev 上的 API 文件與 examples 目錄的實際程式碼。
與其他 ADK 語言版本的關係：同品牌，不同工具
README 列出 Python、Java、Kotlin、TypeScript 與 Web 版本的 ADK 連結。這代表 Google 把 ADK 當成跨語言品牌經營，但各語言版本的成熟度與 API 設計不會相同。Python 版通常是最先有新功能的地方，Go 版則強調效能與雲端原生整合。實際選擇時，重點不是「ADK 好不好」，而是「ADK 的 Go 版是否成熟到符合你的需求」。如果團隊同時有 Python 與 Go 兩種程式碼庫，跨語言共用 Agent 定義會是難題，因為 code-first 路線把邏輯綁死在個別語言裡。如果你需要的是跨語言一致的 Agent 描述格式，那 YAML 或 JSON 為主的框架會比這個專案更合適。但如果你確定要走 Go 路線，這個框架提供了一個有 Google 背書的起點，只是文件深度還跟不上框架的野心。
編輯結論
adk-go 適合已經用 Go 打造雲端服務、想要把 Agent 邏輯直接寫進既有程式碼庫的團隊。它不適合需要快速原型、偏好 YAML 或視覺化流程編輯器的人，那類需求在 Python 版 ADK 或其他框架上更順手。採用前應先確認兩件事：一是你的模型供應商是否在支援清單內，文件宣稱模型中立，但實際整合清單需要查閱官方文件確認；二是多 Agent 的溝通模式是否符合你的場景，若只是單一 Agent 呼叫工具，這個框架的抽象層可能多餘。Apache-2.0 授權對商業使用友善，但內部目錄 internal/httprr 有獨立授權檔，發布前要檢查是否碰觸到該目錄的程式碼。版本節奏很快，v1.6.1 與 v2.3.0 在 2026 年 8 月底同時存在，升級前必須先確認你鎖定的主版本。
社群筆記