Google ADK เป็นเฟรมเวิร์กโอเพนซอร์สสำหรับสร้าง ประเมิน และปรับใช้ AI เอเจนต์ ใช้จริงภายในผลิตภัณฑ์ของ Google เช่น Agentspace หากคุณเคยใช้สแต็กเอเจนต์อย่าง OpenAI Agents SDK มาก่อน ADK จะอยู่ในกลุ่มเดียวกัน แต่ผสานกับ Gemini และ Vertex AI ได้แน่นกว่า บทความนี้สรุปวิธีคิด โครงสร้างหลัก วิธีเริ่มเขียนเอเจนต์ และจุดที่ Apidog ช่วยทดสอบ API ที่เอเจนต์เรียกใช้ได้
Google ADK คืออะไร
ADK ย่อมาจาก Agent Development Kit เป็นชุดเครื่องมือโอเพนซอร์สที่ Google เปิดตัวในงาน Google Cloud Next เดือนเมษายน 2025 สำหรับวงจรชีวิตของเอเจนต์แบบครบขั้นตอน:
- กำหนดพฤติกรรมของเอเจนต์
- เพิ่มเครื่องมือให้เอเจนต์เรียกใช้
- ประกอบเอเจนต์หลายตัวเป็นระบบเดียว
- ประเมินผลลัพธ์และเส้นทางการทำงาน
- ปรับใช้บนรันไทม์จริง
ADK เริ่มจาก Python เป็นหลัก และ Google ได้เพิ่ม Java เข้ามาแล้ว โดยมี Go และ TypeScript ตามมา เฟรมเวิร์กนี้เป็นชุดเดียวกับที่ Google ใช้ภายในสำหรับเอเจนต์ใน Agentspace และ Customer Engagement Suite จึงออกแบบมาสำหรับงาน production ไม่ใช่แค่ตัวอย่างทดลอง
ADK เป็นแบบ model-agnostic แต่เหมาะกับระบบของ Google เป็นพิเศษ โดยทำงานได้ดีกับ Gemini และโมเดลที่อยู่ใน Vertex AI Model Garden นอกจากนี้ยังเชื่อมกับ LiteLLM เพื่อใช้โมเดลจากผู้ให้บริการอื่น เช่น Anthropic, Meta และ Mistral ได้ด้วย
ADK อยู่ตรงไหนในระบบ Gemini และ Vertex AI
ให้มอง ADK เป็นหนึ่งเลเยอร์ในสแต็กเอเจนต์:
- โมเดล: Gemini หรือโมเดลอื่นผ่าน Vertex AI Model Garden / LiteLLM ทำหน้าที่ reasoning
- เฟรมเวิร์ก: ADK คือเลเยอร์โค้ดสำหรับกำหนดเอเจนต์ เครื่องมือ และเวิร์กโฟลว์
- รันไทม์: Vertex AI Agent Engine ใช้โฮสต์เอเจนต์แบบ managed และ scalable หรือจะปรับใช้บน Cloud Run / container runtime อื่นก็ได้
สรุปคือ Gemini ให้ความสามารถด้านโมเดล, ADK ให้โครงสร้างการพัฒนา, และ Vertex AI Agent Engine ให้รันไทม์สำหรับ production คุณสามารถใช้ครบทั้งสามส่วน หรือใช้ ADK ในเครื่องแล้ว deploy ไปยังแพลตฟอร์มอื่นก็ได้
แนวคิดหลักของ ADK
ส่วนที่คุณจะใช้บ่อยมีไม่กี่อย่าง: Agent, Tool, Multi-agent workflow, Runner, Evaluation และ Deployment
1. Agent
เอเจนต์คือหน่วยหลักที่ขับเคลื่อนด้วย LLM ใน Python คุณอิมพอร์ต Agent จาก google.adk.agents แล้วกำหนด:
-
name: ชื่อเอเจนต์ -
model: โมเดลที่ใช้ -
instruction: system instruction / behavior -
tools: ฟังก์ชันที่เอเจนต์เรียกใช้ได้
ตัวอย่างเอเจนต์สำหรับดูอัตราแลกเปลี่ยน:
from google.adk.agents import Agent
def get_exchange_rate(base: str, target: str) -> dict:
"""Return the exchange rate between two currencies."""
# ในงานจริง ให้เรียก FX API ของคุณตรงนี้
return {
"base": base,
"target": target,
"rate": 1.08,
}
currency_agent = Agent(
name="currency_exchange_agent",
model="gemini-2.0-flash",
instruction="You help users convert between currencies. Stick to the facts.",
tools=[get_exchange_rate],
)
โค้ดนี้สร้างเอเจนต์หนึ่งตัวที่รู้ว่าต้องตอบเรื่องการแปลงสกุลเงิน และมีเครื่องมือ get_exchange_rate() ให้เรียกเมื่อจำเป็น
2. Tool
Tool คือสิ่งที่ทำให้เอเจนต์ทำงานนอกเหนือจากการสร้างข้อความ เช่น เรียก REST API, ค้นข้อมูล, อ่านฐานข้อมูล หรือรันโค้ด
ใน ADK ฟังก์ชัน Python ธรรมดาสามารถเป็น tool ได้ โดยโมเดลจะใช้ข้อมูลเหล่านี้เพื่อเลือกว่าจะเรียกใช้เมื่อใด:
- ชื่อฟังก์ชัน
- type hints
- docstring
- return shape
ตัวอย่าง tool ที่เรียก API จริง:
import requests
def search_hotels(city: str, check_in: str, check_out: str) -> dict:
"""Search hotel options for a city and date range."""
response = requests.get(
"https://api.example.com/hotels",
params={
"city": city,
"check_in": check_in,
"check_out": check_out,
},
timeout=10,
)
response.raise_for_status()
return response.json()
ข้อควรทำ:
- เขียน docstring ให้ชัดว่า tool ทำอะไร
- กำหนด input/output ให้สม่ำเสมอ
- handle error จาก API ภายนอก
- test tool แยกจาก agent ก่อนนำไปใช้จริง
ADK ยังมีเครื่องมือในตัว เช่น google_search และ code execution รวมถึงรองรับ Model Context Protocol หรือ MCP สำหรับเชื่อมต่อ tool server ภายนอก คุณยังสามารถ wrap ไลบรารีอย่าง LangChain, LlamaIndex หรือใช้เอเจนต์อื่นเป็น tool ได้
3. ระบบเอเจนต์หลายตัว
เอเจนต์ตัวเดียวเหมาะกับงานง่าย แต่ถ้างานซับซ้อน คุณสามารถแยกความรับผิดชอบเป็นหลายเอเจนต์ เช่น:
- เอเจนต์ค้นเที่ยวบิน
- เอเจนต์ค้นโรงแรม
- เอเจนต์สรุปแผนเดินทาง
- เอเจนต์ตรวจสอบงบประมาณ
ADK มี workflow agents สำหรับควบคุม flow แบบกำหนดได้:
-
SequentialAgent: รันซับเอเจนต์ตามลำดับ -
ParallelAgent: รันหลายซับเอเจนต์พร้อมกัน -
LoopAgent: ทำซ้ำจนกว่าจะเข้าเงื่อนไข
รูปแบบนี้เหมาะกับงานที่ต้องแบ่งขั้นตอนชัดเจน เช่น research pipeline, customer support routing หรือ travel planning
4. Runner
ในการใช้งานจริง คุณไม่ได้เรียกเอเจนต์โดยตรงตลอดเวลา แต่ใช้ Runner เป็นเอนจินประมวลผลของ ADK
Runner ดูแลเรื่อง:
- session
- event flow
- state update
- model call
- tool invocation
- orchestration ระหว่างเอเจนต์
ช่วงพัฒนา คุณสามารถใช้ CLI เพื่อลองเอเจนต์ได้ทันที:
adk run
คำสั่งนี้เปิด interactive terminal session
หรือใช้:
adk web
คำสั่งนี้เปิด UI บน browser เพื่อคุยกับเอเจนต์และดูแต่ละ step ระหว่าง execution เหมาะมากสำหรับ debug ว่าเอเจนต์เลือก tool ถูกหรือไม่ และ input/output ของ tool เป็นอย่างไร
5. การประเมินผลและการปรับใช้
ADK มีเครื่องมือสำหรับ evaluation เพื่อให้คุณตรวจสอบได้ว่าเอเจนต์ทำงานตาม expected path และ expected response หรือไม่ ไม่ใช่ดูแค่คำตอบสุดท้าย
ควรประเมินเมื่อคุณเปลี่ยน:
- prompt / instruction
- tool
- model
- workflow
- routing logic
สำหรับ deployment มีสองแนวทางหลัก:
- ใช้ Vertex AI Agent Engine ถ้าต้องการ managed runtime ที่ scale ได้
- containerize แล้ว deploy ไปยัง Cloud Run หรือ container platform อื่น ถ้าต้องการ portability มากกว่า
ตัวอย่าง: สร้างระบบเอเจนต์วางแผนทริป
ตัวอย่างนี้มี coordinator หนึ่งตัว และ sub-agent สองตัวสำหรับค้นเที่ยวบินและโรงแรม
from google.adk.agents import Agent
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search flight options for a route and date."""
# เรียก flights API จริงของคุณตรงนี้
return {
"origin": origin,
"destination": destination,
"date": date,
"options": [],
}
def search_hotels(city: str, check_in: str, check_out: str) -> dict:
"""Search hotel options near the destination."""
# เรียก hotels API จริงของคุณตรงนี้
return {
"city": city,
"check_in": check_in,
"check_out": check_out,
"options": [],
}
flights = Agent(
name="flight_agent",
model="gemini-2.0-flash",
instruction="Find flight options for the user's route and dates.",
tools=[search_flights],
)
hotels = Agent(
name="hotel_agent",
model="gemini-2.0-flash",
instruction="Find hotel options near the destination.",
tools=[search_hotels],
)
trip_planner = Agent(
name="trip_planner",
model="gemini-2.0-flash",
instruction="Plan a trip. Delegate flight and hotel lookups to your sub-agents.",
sub_agents=[flights, hotels],
)
flow โดยทั่วไปคือ:
- ผู้ใช้ถามให้วางแผนทริป
-
trip_plannerวิเคราะห์คำขอ - ส่งงานค้นเที่ยวบินให้
flight_agent - ส่งงานค้นโรงแรมให้
hotel_agent - รวมผลลัพธ์และตอบผู้ใช้
ตอน debug ให้เริ่มจาก adk web เพื่อดูว่า coordinator ส่งงานไปยัง sub-agent ถูกต้องหรือไม่ และ tool ได้ input ตามที่คาดไว้หรือเปล่า
ADK vs OpenAI Agents SDK
ทั้ง Google ADK และ OpenAI Agents SDK เป็นเฟรมเวิร์กสำหรับสร้างเอเจนต์แบบ code-first มีแนวคิดเรื่อง tools, handoffs / delegation และ tracing คล้ายกัน จุดต่างหลักคือ ecosystem ที่แต่ละตัวเน้น
| Google ADK | OpenAI Agents SDK | |
|---|---|---|
| Default model | Gemini ผ่าน Vertex AI | OpenAI models |
| โมเดลอื่น | Vertex AI Model Garden, LiteLLM | LiteLLM และอื่น ๆ |
| ภาษา | Python, Java, Go, TypeScript | Python, JavaScript/TypeScript |
| Multi-agent | Sub-agents + Sequential, Parallel, Loop workflow agents | Agents-as-tools และ handoffs |
| Managed runtime | Vertex AI Agent Engine | Bring your own |
| Tool protocol | MCP, built-in tools, function tools | MCP, function tools |
ถ้าทีมของคุณอยู่บน Google Cloud อยู่แล้ว ADK + Vertex AI เป็นตัวเลือกที่เข้ากันดี ถ้าสต็กหลักเป็น OpenAI อยู่แล้ว OpenAI Agents SDK อาจเหมาะกว่า ทั้งสองรองรับ MCP จึงสามารถแชร์ tool server บางส่วนร่วมกันได้
ควรใช้ ADK เมื่อใด
เลือกใช้ ADK เมื่อ:
- คุณสร้างระบบบน Google Cloud และต้องการใช้ Gemini กับ Vertex AI Agent Engine
- คุณต้องการ orchestration ของหลายเอเจนต์แบบชัดเจน
- งานต้องใช้ workflow แบบ sequential, parallel หรือ loop
- คุณต้องการ evaluation ในเฟรมเวิร์ก ไม่ใช่เพิ่มทีหลัง
- คุณต้องการสลับโมเดลผ่าน Vertex AI Model Garden หรือ LiteLLM
อาจยังไม่จำเป็นต้องใช้ ADK ถ้า:
- use case เป็น prompt เดียว + function call ง่าย ๆ
- ไม่มี workflow หลายขั้นตอน
- ไม่ต้องการ multi-agent
- ทีมอยู่กับ ecosystem อื่นแบบชัดเจน
เฟรมเวิร์กเอเจนต์ช่วยเพิ่มโครงสร้าง แต่โครงสร้างก็มีต้นทุน ถ้างานเล็กมาก การเรียก LLM API ตรง ๆ อาจง่ายกว่า
Apidog ช่วยตรงไหน: ทดสอบและจำลอง API ที่เอเจนต์เรียกใช้
ADK จัดการ logic ของเอเจนต์ แต่ไม่ได้แทนที่การทดสอบ API ภายนอกที่ tool ของคุณเรียกใช้ และนี่คือจุดที่ควรแยกมาทดสอบตั้งแต่ต้น
ในระบบเอเจนต์จริง tool มักจะเรียกสิ่งเหล่านี้:
- LLM endpoint
- payment API
- internal microservice
- search service
- CRM / ticketing API
- third-party data provider
ถ้า API เหล่านี้ส่ง response ผิดรูปแบบ เอเจนต์จะ reason ต่อจากข้อมูลผิด และ debug ยาก เพราะปัญหาอาจดูเหมือน prompt ไม่ดี ทั้งที่จริงคือ contract ของ API เปลี่ยน
Apidog ไม่ใช่เฟรมเวิร์กเอเจนต์และไม่ได้แทนที่ ADK แต่ทำงานในเลเยอร์ API ที่ tool ของเอเจนต์พึ่งพา
วิธีใช้ Apidog ระหว่างพัฒนา ADK
1. Mock endpoint ที่ tool เรียกใช้
ตั้งค่า mock API สำหรับ endpoint ที่ยังไม่พร้อม หรือ endpoint ที่ไม่อยากเรียกจริงระหว่างพัฒนา เช่น LLM, payment หรือ third-party API
ข้อดี:
- พัฒนาเอเจนต์ได้โดยไม่ต้องรอ backend
- ลดค่า token หรือค่า API call
- ทดสอบ error case ได้ง่าย
- ควบคุม response ได้คงที่
ตัวอย่าง tool ที่ชี้ไปยัง mock endpoint:
import os
import requests
def get_customer_profile(customer_id: str) -> dict:
"""Fetch a customer profile by customer ID."""
base_url = os.environ["CUSTOMER_API_BASE_URL"]
response = requests.get(
f"{base_url}/customers/{customer_id}",
timeout=10,
)
response.raise_for_status()
return response.json()
ระหว่าง development ให้ CUSTOMER_API_BASE_URL ชี้ไปยัง mock server ใน Apidog ส่วน staging / production ค่อยเปลี่ยนเป็น endpoint จริง
2. ตรวจ response schema ก่อนให้เอเจนต์ใช้
ใช้ การยืนยัน API เพื่อตรวจว่า response มี field ที่เอเจนต์ต้องใช้ เช่น:
{
"customer_id": "cus_123",
"name": "Jane Doe",
"tier": "gold",
"open_tickets": 2
}
ถ้า tool คาดหวัง tier แต่ API เปลี่ยนเป็น plan เอเจนต์อาจตอบผิดทันที การทดสอบ contract จะจับปัญหานี้ก่อนเข้าสู่ agent transcript
3. แยก environment keys
เก็บ key และ base URL แยกตาม environment:
- dev
- staging
- production
การทำแบบนี้ช่วยให้ tool function เดิมทำงานได้ทุก stage โดยเปลี่ยนแค่ environment config ไม่ต้องแก้โค้ด
4. ทดสอบ tool แยกจาก agent
ก่อนนำ tool เข้า tools=[...] ให้ทดสอบ API call ตรง ๆ ก่อน:
def test_get_customer_profile():
result = get_customer_profile("cus_123")
assert "customer_id" in result
assert "tier" in result
assert isinstance(result["open_tickets"], int)
แนวคิดคืออย่า debug พร้อมกันทั้ง agent, prompt, model และ API ให้แยก API contract ออกมาก่อน
ถ้าต้องการแนวทางเฉพาะสำหรับเอเจนต์ ดูวิธี ทดสอบการเรียกใช้เครื่องมือของ AI เอเจนต์ ก่อนเกิดปัญหาใน production หรือ ดาวน์โหลด Apidog แล้วเริ่ม mock endpoint แรกได้ภายในไม่กี่นาที
คำถามที่พบบ่อย
Google ADK ฟรีและโอเพนซอร์สหรือไม่
ใช่ ADK เป็นโอเพนซอร์สใน repository บน GitHub ภายใต้ Apache license คุณสามารถรันในเครื่องได้โดยไม่มีค่าใช้จ่าย แต่ยังต้องจ่ายค่าโมเดลที่เรียกใช้ และค่า managed runtime หาก deploy ไปยังบริการอย่าง Vertex AI Agent Engine
ADK ทำงานกับ Gemini เท่านั้นหรือไม่
ไม่ ADK ได้รับการปรับให้เหมาะกับ Gemini และ Vertex AI แต่ยังเป็น model-agnostic ผ่าน Vertex AI Model Garden และ LiteLLM คุณสามารถใช้โมเดลจาก Anthropic, Meta, Mistral และผู้ให้บริการอื่นได้ Gemini เป็นค่าเริ่มต้นที่เข้ากันดีที่สุด แต่ไม่ใช่ข้อบังคับ
ADK รองรับภาษาอะไรบ้าง
Python เป็นภาษาแรกและยังมีความสมบูรณ์ที่สุด Google ได้เพิ่ม Java แล้ว และมี Go กับ TypeScript ตามมา หากต้องการ feature coverage ที่กว้างที่สุดตอนนี้ Python ยังเป็นตัวเลือกที่ปลอดภัยที่สุด
ควร debug เอเจนต์ ADK อย่างไร
เริ่มจาก adk web เพื่อดู execution step, tool call, input และ output ของแต่ละ tool จากนั้นแยกทดสอบ tool function ด้วย unit test หรือ API test อย่าแก้ prompt ก่อนถ้ายังไม่มั่นใจว่า API response ถูกต้อง
ฉันจะทดสอบ API ที่เอเจนต์ ADK พึ่งพาได้อย่างไร
ทดสอบ API แยกจากเอเจนต์ก่อน จำลอง endpoint ที่ยังไม่พร้อมหรือไม่อยากเรียกจริง แล้วตรวจ response schema ให้ตรงกับสิ่งที่ tool คาดหวัง Apidog รองรับทั้ง mock และ assertion คู่มือ ทดสอบ ChatGPT API ใช้ pattern เดียวกันกับ LLM endpoint ที่ tool ของคุณอาจเรียกใช้
สรุป
Google ADK เป็นเฟรมเวิร์กที่เหมาะสำหรับสร้างเอเจนต์และระบบหลายเอเจนต์ โดยเฉพาะถ้าคุณใช้ Gemini, Vertex AI หรือ Google Cloud อยู่แล้ว วิธีเริ่มที่ practical คือสร้างเอเจนต์หนึ่งตัว เพิ่ม tool ไม่กี่ตัว รันด้วย adk web เพื่อดูพฤติกรรม แล้วค่อยขยายเป็น sub-agents หรือ deploy ไปยัง managed runtime
เมื่อเอเจนต์ของคุณเริ่มพึ่งพา API ภายนอกมากขึ้น ให้ทดสอบ API เหล่านั้นเป็น contract แยกต่างหาก จำลอง response, ตรวจ schema และแยก environment ให้ชัดเจน นั่นคือเลเยอร์ที่ Apidog ช่วยจัดการ และมักเป็นจุดเริ่มต้นของพฤติกรรมเอเจนต์ที่ดูเหมือนไม่แน่นอน




Top comments (0)