概述

在上一篇文張中，我們透過 Google Agent 白皮書確立了一個核心共識：AI 應用的未來屬於能夠感知、思考、採取行動的智能代理（Agent）。而一個強大的代理由三個部分組成：聰明的「大腦」（LLM）、連接世界萬物的「手腳」（工具），以及指揮這一切的「神經系統」（編排層）。

但從一個絕妙的代理構想，到一個能在生產環境中穩定運作、為企業創造的應用，中間隔著一條名為「工程實現」的鴻溝。這個複雜的「神經系統」涉及狀態管理、工具調用、錯誤處理、記憶儲存需要可靠的建造嗎？這就是代理框架存在的意義。它是一個強健的架構，為我們的 Agent 注入結構與生命力。

今天，我們將深入探討 Agent 框架的核心價值，在市場兩大核心的解決方案上進行比較：Google 傾力打造的 Agent Development Kit (ADK)，與開源社群的自主靈活的 LangGraph。

更重要的是，我們將透過比較，探討一個根本性的問題：當 No-Code / Low-Code 工具讓建構 Agent 整合變得前所未有的簡單時，為什麼我們還需要選擇編寫程式碼（Code-First）？

LLM Agent 框架的定位

在動手比較之前，我們必須清楚：Agent 框架究竟解決了什麼問題？為何我們不能簡單的直接用 OpenAI 提供的 SDK 或 API 來建構 Agent？

from openai import OpenAI
client = OpenAI()

resp = client.responses.create(
    model="gpt-4.1",
    input="用一句話解釋：為何我們不能簡單的直接用 OpenAI 提供的 SDK 或 API 來建構 Agent？"
)
print(resp.output_text)

一個簡單的 For Loop 或許可以支撐一個少數應用場景，但當我們將 LLM 應用推到生產級別時，就不能繼續抱持著驗證、試錯、學習的心態來看待，不然會立刻在以下幾個方面暴露出脆弱性。

狀態管理 (State Management)

https://medium.com/@lorevanoudenhove/how-to-build-ai-agents-with-langgraph-a-step-by-step-guide-5d84d9c7e832

Agent 的執行是多步驟的。在漫長的任務鏈中，如何可靠地追蹤對話歷史、中間工具的輸出、失敗的次數？這就是記憶（Memory） 的範疇：

• 短期記憶：維持單次對話的上下文，避免讓使用者重複資訊。實務上常見做法包括「視窗截斷（windowing）」、「動態摘要（summarization）」與「關鍵槽位（slot）抽取」，在有限上下文中只保留與當前任務最相關的訊息。
• 長期記憶：跨會話記住使用者偏好與歷史行為，通常藉由向量資料庫與檢索式生成（RAG）落地。要考慮寫入策略（什麼時候寫入、新舊權重）、資料老化（decay/TTL）與個資治理（避免把敏感資訊永久留存）。
• 執行狀態：除了對話本身，還需要管理每個步驟的結構化狀態（例如：任務階段、工具呼叫輸入/輸出、重試計數、是否可回溯），並確保冪等（idempotent）與可恢復（resumable），避免中斷後只能「從頭再來」。

隨著計算的進行而維持和更新的上下文或記憶。它確保圖中的每個步驟都能存取來自先前步驟的相關信息，從而允許基於整個過程中累積的數據進行動態決策。

流程控制（Flow Control）

真實的業務流程不是直線。如果工具呼叫失敗怎麼辦？需要使用者確認才能執行下一步呢？

• 一個成熟的 Agent 通常採用規劃—執行—評審（planner–executor–critic）的迭代循環，能分解任務、動態調整計畫，並在遇到異常時執行回退或替代路徑。
• 要具備分支（branching）與守護條件（guard conditions），例如：若關鍵欄位缺失則轉為詢問使用者澄清或停止回答。
• 在多工具或多 Agent 協作場景，還需處理併發與資源配額、跨步驟的資料依賴圖（DAG）、以及部分完成（partial completion）的可接受策略。

可觀測性（Observability）

當 Agent 行為不如預期時，如何快速除錯？

• 需要步驟級的追蹤（trace）與事件化日誌：包含每次提示詞版本、模型回應、工具 I/O、延遲與成本度量（token/金額）。
• 支援重播（replay）與時間旅行除錯：用同一批輸入在沙盒重跑，以定位回歸問題。
• 對產品環境，通常不直接暴露完整的內部推理內容，而是提供決策依據的可視化摘要與工具調用紀錄，以兼顧可解釋性與安全/隱私。

安全性與可靠性（Security & Reliability）

如何確保一個能操作資料庫、發送郵件甚至下單的 Agent 不會「失控」？

• Human In The Loop（HITL）機制是必需：在高風險動作（如金流、刪除資料、對外寄信）前插入審批節點，並提供可審視的變更摘要。
• 最小權限原則：以憑證或白名單限制可呼叫的工具與其參數範圍，並在越權時硬性阻擋。
• 輸出驗證與政策護欄：用結構化綱要（如 JSON Schema）驗證模型輸出；在對外動作前做安全掃描、資料脫敏與合規檢查。

Agent 框架的核心價值，就是將包含但不限於上述的工程問題進行抽象和標準化，提供一個健壯的股價或引擎，讓開發者可以專注於業務本身，而非重複造輪子。

由下圖中的 Google ADK 功能組成圖中，我們可以看出一個現代化的 Agent 框架，遠遠不只是包裝一個 LLM 而已。它實際上是一個模組化的 SDK，設計目的是為了讓開發者能在複雜、真實世界的應用場景中，構建可部署、可維運、可擴展的多 Agent 系統。

兩種 Agent 哲學 No-Code/Low-Code vs. Code-First

在深入探討 Agent 開發框架時，我們必須先理解兩種截然不同的構建哲學。這兩種哲學分野，恰好可以透過比較 n8n 與 Google ADK/LangGraph 來清晰地呈現。

No-Code/Low-Code Agent 平台 (以 n8n 為代表)

• 核心理念： 以視覺化介面與預設模組，快速實現「你想要什麼」，而非執著於「具體怎麼做」。
• 開發體驗： 開發者透過圖形化介面（UI）拖拉節點、填寫參數，或是用少量腳本（JavaScript/Python）來描述 Agent 的工作流程。你像是個指揮官，告訴平台：「從 A 點觸發，取得資料，交給 AI 處理，然後將結果送到 C 點。」
• 優勢：
  • 開發迅速：對於標準化的流程，幾分鐘內就能搭建並部署一個可用的 Agent 原型。
  • 門檻較低：非傳統開發背景的技術人員（如營運、分析師）也能參與構建與維護。
  • 整合便利：平台通常內建大量的應用程式連接器（Connector），簡化了串接不同服務的複雜性。

Code-First Agent 框架 (以 Google ADK 與 LangGraph 為代表)

• 核心理念： 「明確優於隱晦 (Explicit is better than implicit)」。透過程式碼精準、清晰地定義 Agent 的每一個行為步驟與邏輯。
• 開發體驗： 開發者使用 Python 等程式語言來構建 Agent 的核心邏輯。
  • 在 Google ADK 中，開發者能以貼近傳統軟體開發的模式，用程式碼定義 Agent 的邏輯、工具與協作方式，並針對 Google Cloud 生態系進行優化。
  • 在 LangGraph 中，開發者則是構建一個「狀態圖 (State Graph)」，其中每個節點 (Node) 是一個具體動作（如呼叫工具），每條邊 (Edge) 則代表一個轉換條件，就像上圖所示。
• 為什麼需要 Code-First？
  • 極致的掌控力與靈活性：No-Code/Low-Code 平台通常有其預設的運行邏輯。但若您的業務需要一個非標準、高度客製化的流程（例如：需要多輪內部「辯論」才做決策的 Agent，或在不同條件下觸發完全不同工具鏈的 Agent），Code-First 框架能讓您定義任意複雜、非線性的確定性流程。
  • 透明度與可除錯性：在 No-Code/Low-Code 平台中，底層的 Agent 循環有時像個「黑盒子」，出現非預期行為時，診斷較為困難。而在 Code-First 框架下，整個邏輯圖或程式碼都由您親手編寫，每一步的狀態轉換都清晰可見，除錯變得更加直觀。
  • 可移植性與避免廠商鎖定：用程式碼定義的 Agent 邏輯，可以被打包成容器，部署在任何雲端平台或本地伺服器上，避免被單一平台綁定。
  • 整合的無限性：只要一個功能能被 Python 呼叫，它就能成為您 Agent 的一個工具。無論是公司內部的舊有系統，或是一個冷門的開源函式庫，整合都沒有限制。

深度比較：Google ADK vs. LangGraph

在我們深入比較之前，關鍵的認知是：這兩者都是 Code-First 框架，旨在賦予開發者用程式碼定義 Agent 行為的能力。它們的差異在於抽象化的層級與設計哲學。

因為我個人接觸到的第一個 Agent 框架就是 Google ADK，當時他的開箱即用的便利性讓我印象深刻，我也透過它的視角認識到其他框架以及各種概念，接下來在更進接的應用場景中，需要進階控制以及一定細膩度的地方，我跟大家一樣自然而然的就找到 LangGraph ，也不斷在這條路上學習著

何時選擇 Google ADK：「高效建構」與「生產級穩定性」

Google ADK 則更像是為那些希望快速建構可擴展、可維護的 Agent 團隊的「產品工程師」所設計。在以下場景中，ADK 將會大放異彩：

• 構建階層式 Agent 團隊：你的目標不是單一的 Agent，而是一個由總監 (Coordinator) 和多個專家 (Sub-agents) 組成的協作團隊。ADK 原生為這種階層式架構設計，能讓你更專注於定義每個 Agent 的角色與職責。
• 深度整合 Google Cloud：你的應用場景與 Google Cloud 生態緊密相連，需要無縫串接 Gemini 模型、Vertex AI Search、BigQuery 或其他 GCP 服務。ADK 在這方面提供了「原廠支援」的最佳體驗。
• 偏好傳統軟體開發體驗：相比於操作底層的狀態圖，你更喜歡一種更高層次、更抽象化的開發模式。你希望專注於實現商業邏輯，而將狀態管理、會話控制等繁瑣事務交給框架處理。
• 追求快速部署與維運：你希望利用框架內建的評估工具和一鍵式部署管道，快速將 Agent 推向生產環境，並享受 Serverless 帶來的低維運負擔。

當你的目標是在 Google Cloud 生態中，高效地建立一個結構清晰、易於擴展且能立即投入生產的 Agent 系統時，ADK 提供了更精簡、功能更全面的解決方案。

何時選擇 LangGraph：「極致的控制權」與「完全的透明度」

LangGraph 是為那些希望精準掌控 Agent 一舉一動的「架構師」所準備的。當你遇到以下情況時，它會是你的最佳選擇：

• 流程極度複雜且非標：你的業務邏輯不是簡單的「輸入->處理->輸出」，而是包含了複雜的循環 (Cycles)、條件分支 (Branching)，甚至需要根據情境動態決定下一步。你需要的是一個能讓你「繪製」出這張複雜藍圖的工具。
• 「可審核性」至關重要：在金融、醫療或法律等領域，Agent 的每一個決策都必須有跡可循。LangGraph 的圖形結構讓整個思考鏈 (Chain of Thought) 完全透明，除錯與審核變得直觀且可靠。
• 深度整合 LangChain 生態：如果你的團隊已經大量投資於 LangChain 的生態系，LangGraph 讓你能夠無縫地將既有的工具 (Tools)、模型 (LLMs) 和記憶模組 (Memory) 融入到更穩健、有狀態的 Agent 流程中。

當你需要的是從零開始、鉅細靡遺地打造一個高度客製化、流程完全透明的 Agent 系統時，LangGraph 提供了實現這個目標所需的底層控制權。

結論

我的 LLM Agent 開發之旅，始於 Google ADK。當時，它「開箱即用」的便利性與高度整合的開發體驗，為我打開了 Agent 開發的大門。ADK 就像優秀的嚮導，讓我快速建立起對 LLM 應用核心概念的理解，我從他的完整度中反向推敲出在這領域會遇到的挑戰。

然而，隨著應用場景的深入，當我需要應對更複雜、非線性的流程，並要求對 Agent 的每一個決策步驟進行精準、可審計的控制時，我跟許多開發者一樣，自然而然地走向了 LangGraph。

這也是為何我選擇特地推薦這兩套框架，分享給所有想開始踏上 LLM 應用開發的挑戰者們。

References:

• https://medium.com/@jjaladi/langgraph-vs-adk-a-developers-guide-to-choosing-the-right-ai-agent-framework-b59f756bcd98
• https://google.github.io/adk-docs/
• https://www.langchain.com/langgraph