Thanawat Wongchai

Posted on Jun 26 • Originally published at apidog.com

Strands Agents คืออะไร? SDK โอเพนซอร์สสำหรับเอเจนต์ที่ขับเคลื่อนด้วยโมเดลจาก AWS

หากคุณเคยสร้าง AI agent ด้วยการต่อ if/else หรือ state machine ขนาดใหญ่ คุณจะรู้ว่ามันเปราะบางเร็วแค่ไหน Strands Agents ใช้แนวทางตรงข้าม: ให้โมเดลวางแผนเอง และให้คุณกำหนดเพียง system prompt กับรายการเครื่องมือ เป็น SDK โอเพนซอร์สจาก AWS เปิดตัวในเดือนพฤษภาคม 2025 ภายใต้ Apache License 2.0 และถูกใช้เป็นส่วนหนึ่งของ agent ที่ใช้งานจริงภายในทีม Amazon เช่น Amazon Q Developer และ AWS Glue

ลองใช้ Apidog วันนี้

Strands Agents คืออะไร

Strands Agents คือ SDK สำหรับสร้างและรัน AI agent โดยใช้โครงสร้างหลัก 3 ส่วน:

Model: โมเดลที่ใช้ reasoning และตัดสินใจ
System prompt: คำสั่งหลักที่กำหนดบทบาทและขอบเขตของ agent
Tools: ฟังก์ชันหรือบริการที่ agent เรียกใช้เพื่อทำงานจริง

ลูปการทำงานคือ: โมเดลอ่านคำสั่ง → ตัดสินใจว่าจะใช้เครื่องมือใด → เรียกเครื่องมือ → อ่านผลลัพธ์ → ทำต่อจนกว่างานจะเสร็จ

SDK รองรับทั้ง Python และ TypeScript ชื่อ “Strands” สื่อถึงสองเส้นหลักของ agent: โมเดล และ เครื่องมือ AWS เปิดโอเพนซอร์สหลังจากใช้งานภายในองค์กรแล้ว จึงสะท้อนโจทย์การใช้งานจริงมากกว่าตัวอย่างเดโมทั่วไป

ตั้งแต่รุ่นพรีวิว Strands มียอดดาวน์โหลดบน PyPI มากกว่า 150,000 ครั้ง และเวอร์ชัน 1.0 เพิ่มพื้นฐานสำหรับ multi-agent รวมถึงรองรับโปรโตคอล Agent-to-Agent หรือ A2A

ถ้าคุณเคยใช้เฟรมเวิร์กอย่าง LangGraph หรือ Google ADK แนวคิดจะคุ้นเคย แต่ Strands เน้นให้โมเดลควบคุม flow มากกว่าให้คุณวาด graph เองทุกขั้น

แนวคิดหลัก: model-driven แทน hard-coded orchestration

เฟรมเวิร์ก agent หลายตัวให้คุณกำหนด workflow ล่วงหน้า เช่น node, edge, condition และ routing วิธีนี้ควบคุมได้ดี แต่ทุกความสามารถใหม่มักหมายถึง graph ที่ซับซ้อนขึ้น

Strands ย้ายภาระการวางแผนไปให้โมเดล คุณกำหนดเป้าหมายและเครื่องมือ จากนั้นโมเดลเลือกขั้นตอนเอง

แนวทาง	คุณต้องกำหนด	Flow ถูกควบคุมโดย	เมื่อเพิ่มความสามารถใหม่
Hard-coded orchestration	Node, edge, condition, routing	โค้ด graph	แก้ graph และทดสอบ path ใหม่
Model-driven ด้วย Strands	Prompt + tools	Reasoning loop ของโมเดล	เพิ่ม tool และปรับ prompt

ข้อแลกเปลี่ยนคือ model-driven สร้างเร็วและปรับง่ายกว่า แต่ผลลัพธ์อาจคาดเดายากกว่า graph ที่ล็อกทุกสาขาไว้ล่วงหน้า หาก workflow ต้องทำเหมือนเดิมทุกครั้ง คุณยังใช้ hooks หรือ multi-agent pattern เพื่อเพิ่มโครงสร้างได้

สร้าง Strands agent ตัวแรก

ตัวอย่างที่เล็กที่สุดคือ agent ที่มี tool หนึ่งตัว:

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Count the words in a block of text."""
    return len(text.split())

agent = Agent(
    system_prompt="You are a concise writing assistant.",
    tools=[word_count],
)

response = agent("How many words are in this sentence?")
print(response)

จุดที่ควรสังเกต:

@tool แปลงฟังก์ชัน Python ปกติให้โมเดลเรียกใช้ได้
Docstring กลายเป็นคำอธิบาย tool
Type hints กลายเป็น input schema
agent(...) จะรัน reasoning loop จนกว่าโมเดลจะเห็นว่างานเสร็จ

ในโปรเจกต์จริง ให้เขียน tool ให้เล็ก ชัดเจน และคืนค่าที่มีโครงสร้าง เช่น dict หรือ object ที่ schema คงที่ เพื่อให้ทดสอบง่าย

ตัวอย่าง tool ที่เรียก HTTP API:

from strands import tool
import requests

@tool
def get_user_profile(user_id: str) -> dict:
    """Fetch a user profile by user ID."""
    response = requests.get(
        f"https://api.example.com/users/{user_id}",
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

แนวทางที่ควรทำ:

ตั้ง timeout ทุกครั้ง
handle error จาก API ให้ชัดเจน
คืน response ที่ predictable
แยก config เช่น base URL และ API key ออกจากโค้ด

เลือก model provider

Strands ใช้ Amazon Bedrock เป็น provider เริ่มต้น และโดยทั่วไป agent จะใช้ Claude Sonnet ใน region us-west-2 แต่ ID ของโมเดลเริ่มต้นอาจเปลี่ยนตามเวอร์ชัน SDK ดังนั้นควรตรวจสอบจากเวอร์ชันที่ติดตั้ง ไม่ควร hard-code โดยไม่ตรวจสอบ

Provider ที่ใช้งานได้รวมถึง:

Amazon Bedrock model ที่รองรับ tool use และ streaming
Anthropic Claude ผ่าน Anthropic API
Llama ผ่าน Llama API
Ollama สำหรับ local development
Provider อื่น เช่น OpenAI ผ่าน LiteLLM

แนวคิดสำคัญคือการเปลี่ยน provider ควรเป็นการเปลี่ยน model object ไม่ใช่เขียน agent ใหม่ทั้งหมด ดังนั้นคุณสามารถ prototype ด้วย Ollama ในเครื่อง แล้ว deploy ด้วย Bedrock ได้โดยยังใช้ prompt และ tools ชุดเดิม

ใช้ tools และ MCP ให้คุ้ม

Tool คือช่องทางที่ agent ใช้ติดต่อโลกภายนอก อาจเป็น:

ฟังก์ชัน Python ที่คุณเขียนเอง
เครื่องมือจาก community
HTTP API ที่ห่อด้วยฟังก์ชัน
MCP server ที่ expose tools หลายตัว

MCP หรือ Model Context Protocol เป็นมาตรฐานเปิดสำหรับเชื่อมโมเดลกับเครื่องมือและแหล่งข้อมูล เมื่อใช้กับ Strands คุณสามารถเชื่อมต่อ MCP server แล้วส่ง tools เหล่านั้นให้ agent ได้โดยตรง

แนวทางใช้งานที่ practical:

เริ่มจาก tool ที่เขียนเองก่อน หาก logic ยังเล็ก
ใช้ MCP เมื่อคุณมีระบบภายนอกหลายตัวหรือมี MCP server อยู่แล้ว
ทดสอบ MCP server แยกจาก agent เสมอ
กำหนด fallback behavior เมื่อ tool หรือ MCP server ล่ม

ถ้า MCP server มีปัญหา agent อาจดูเหมือน “โมเดลตอบผิด” ทั้งที่จริงแล้ว dependency ด้าน API ล้มเหลว ดังนั้นควรแยกทดสอบ transport, auth, response schema และ error case ให้ครบ

Multi-agent และ A2A

Agent ตัวเดียวเพียงพอสำหรับหลาย use case แต่ระบบจริงอาจต้องแบ่งงานเป็นหลาย agent เช่น:

agent หนึ่งวิเคราะห์ requirement
agent หนึ่งเรียก API
agent หนึ่งสรุปผลลัพธ์
agent หนึ่งตรวจสอบความถูกต้อง

Strands 1.0 เพิ่มพื้นฐานสำหรับ multi-agent เช่น:

Agent-as-Tool: ให้ agent หนึ่งถูกเรียกเหมือน tool โดย agent อื่น
Swarm coordination: ให้หลาย agent ร่วมกันแก้ปัญหา
A2A protocol: ให้ Strands agent สื่อสารกับ agent จากเฟรมเวิร์กอื่นได้

ใช้ multi-agent เมื่อบทบาทแยกกันชัดเจน อย่าแยกเพียงเพราะอยากให้ architecture ดูซับซ้อนขึ้น เพราะทุก agent ที่เพิ่มเข้ามาคือ surface area เพิ่มขึ้นสำหรับ latency, cost และ debugging

Deploy Strands agent

Strands ถูกออกแบบให้ย้ายจาก local development ไป production ได้โดยไม่ต้องเปลี่ยนเฟรมเวิร์ก เป้าหมาย deployment ที่พบบ่อยคือ:

Amazon Bedrock AgentCore สำหรับ managed agent runtime
AWS Lambda สำหรับ event-driven agent อายุสั้น
AWS Fargate หรือ Amazon EKS สำหรับ service แบบ container ที่รันต่อเนื่อง
Docker runtime ทั่วไปใน environment ที่คุณควบคุมเอง

Checklist ก่อน deploy:

แยก environment variables เช่น API keys, model ID, region
ตั้ง timeout และ retry ให้ tool ที่เรียก network
log tool calls และผลลัพธ์ที่สำคัญ
ปิด logging สำหรับข้อมูลลับ
ทดสอบ error cases เช่น API 401, 429, 500 และ timeout
เพิ่ม observability hooks เพื่อติดตามว่าโมเดลเรียก tool ใดและตัดสินใจอย่างไร

เพราะ Strands agent เป็น Python หรือ TypeScript application ปกติ การ package จึงใช้แนวทางเดียวกับ backend service ทั่วไป

Apidog เหมาะกับส่วนไหนของ Strands workflow

Strands ช่วยสร้าง agent แต่ไม่ได้สร้างหรือ validate API ที่ agent เรียกใช้ ในระบบจริง agent มักพึ่งพา HTTP endpoints อย่างน้อยสองกลุ่ม:

LLM provider API ที่อยู่เบื้องหลัง model
REST/tool API หรือ MCP endpoint ที่อยู่เบื้องหลัง tools

ถ้า endpoint เหล่านี้ผิด schema, timeout, auth fail หรือคืน error ที่ไม่ได้คาดไว้ agent อาจล้มเหลวในรูปแบบที่ดูเหมือนปัญหาของโมเดล ทั้งที่จริงเป็นปัญหา API

Apidog ใช้ทดสอบและจำลอง API เหล่านี้ก่อนให้ agent เรียกจริง ตัวอย่าง workflow ที่ใช้ได้ทันที:

Mock model หรือ tool endpoint ระหว่างพัฒนา เพื่อไม่ต้องเสีย token หรือชน rate limit ทุกครั้ง ดูตัวอย่างแนวทางในบทความ AI agent test harness ด้วย Apidog
ตรวจ response schema ของ tools เช่น field, type, status code และ error payload ด้วย API assertions
ตั้งค่า mock API เพื่อจำลอง success case และ failure case ที่ agent ต้อง handle
จัดการ API keys ตาม environment เช่น dev, staging และ production โดยไม่ hard-code credential ใน agent
รัน regression test ใน CI เพื่อให้รู้ทันทีเมื่อ backend contract เปลี่ยนและอาจทำให้ agent พัง

Apidog ไม่ใช่ agent framework และไม่ได้ orchestrate reasoning loop ให้ Strands ยังคงเป็นสมองของ agent ส่วน Apidog เป็น workbench สำหรับทดสอบ API, mock dependency และตรวจ contract ของ service ที่ agent เรียกใช้ คุณสามารถ ดาวน์โหลด Apidog แล้วเริ่ม mock tool endpoints ได้ภายในไม่กี่นาที

ตัวอย่าง workflow สำหรับทีม dev

หากต้องการเริ่มใช้ Strands แบบเป็นระบบ ให้ใช้ขั้นตอนนี้:

นิยาม use case ให้เล็ก
- เช่น “สรุปข้อมูล user จาก API แล้วตอบเป็น bullet”
- หลีกเลี่ยงงานกว้างเกินไปใน agent ตัวแรก
เขียน tools เป็นฟังก์ชันเล็ก
- หนึ่ง tool ต่อหนึ่งความสามารถ
- ใช้ type hints และ docstring ชัดเจน
mock API ก่อนเรียกของจริง
- สร้าง mock response สำหรับ success, not found, unauthorized, rate limit
- ตรวจว่า agent handle ทุกกรณีได้
เขียน system prompt
- ระบุบทบาท
- ระบุข้อจำกัด
- ระบุวิธีใช้ tool หากจำเป็น
- ระบุรูปแบบ output
ทดสอบแบบ end-to-end
- ทดสอบ prompt + tool + API
- เก็บ log ของ tool calls เพื่อ debug
เพิ่ม observability ก่อน production
- trace การเรียก tool
- record latency
- monitor error rate
- ตรวจ cost จาก model provider

ควรใช้ Strands Agents เมื่อใด

เลือกใช้ Strands เมื่อ:

คุณต้องการสร้าง agent ได้เร็ว
คุณเชื่อให้โมเดลวางแผนขั้นตอนเองได้
คุณใช้งาน AWS หรือ Bedrock อยู่แล้ว
คุณต้องการเริ่มจาก agent ตัวเดียวแล้วค่อยขยายเป็น multi-agent
คุณต้องการใช้ MCP tools โดยไม่เขียน integration เองทั้งหมด

อาจไม่เหมาะเมื่อ:

workflow ต้อง deterministic มาก
ทุก branch ต้องถูกกำหนดล่วงหน้า
compliance ต้องตรวจ flow แบบ static ได้ละเอียด
คุณต้องการ graph-based orchestration เป็นแกนหลัก

สรุปคือ Strands เหมาะกับงาน model-driven ส่วน graph-based framework เหมาะกับงานที่ต้องควบคุม path อย่างเข้มงวด หลายทีมสามารถใช้ทั้งสองแนวทางใน service คนละประเภทได้

คำถามที่พบบ่อย

Strands Agents เป็นโอเพนซอร์สและใช้ฟรีหรือไม่

ใช่ Strands Agents เป็นโอเพนซอร์สภายใต้ Apache License 2.0 และมีซอร์สโค้ดบน GitHub ไม่มีค่า license สำหรับ SDK แต่คุณยังต้องจ่ายค่า model provider และ cloud resource ที่ใช้ เช่น Bedrock inference หรือ Lambda execution

ต้องใช้ Amazon Bedrock กับ Strands หรือไม่

ไม่จำเป็น Bedrock เป็น provider เริ่มต้น แต่ Strands รองรับ Anthropic API, Llama API, Ollama สำหรับ local development และ provider อื่นผ่าน LiteLLM คุณเปลี่ยน model object ได้โดยไม่ต้องเขียน agent ใหม่ทั้งหมด

Strands ต่างจาก framework แบบ graph-first อย่างไร

Strands เป็น model-driven: คุณให้ prompt และ tools แล้วให้โมเดลตัดสินใจขั้นตอนเอง ส่วน graph-first framework ให้คุณกำหนด flow เป็น node และ edge ล่วงหน้า Strands ปรับเร็วกว่า แต่ graph-first ควบคุมได้ละเอียดและคาดเดาได้มากกว่า

จะทดสอบ API ที่ Strands agent พึ่งพาได้อย่างไร

ให้ทดสอบแยกจาก agent ตั้งแต่ต้น Mock LLM และ tool endpoints, validate response schema และรัน test เหล่านี้ใน CI เครื่องมืออย่าง Apidog ช่วยจัดการ mock และ assertion ได้ รวมถึงบทความ การทดสอบ ChatGPT API ด้วย Apidog ที่ครอบคลุม authentication, streaming และ tool-call testing

สรุป

Strands Agents เสนอวิธีสร้าง agent ที่เรียบง่าย: กำหนด model, prompt และ tools แล้วให้โมเดลรัน reasoning loop เอง มันเริ่มจาก agent ตัวเดียวได้ ขยายเป็น multi-agent ได้ รองรับ MCP และ A2A และ deploy บน AWS stack ได้โดยไม่ต้องเปลี่ยน architecture หลัก

งานของคุณคือทำให้ tools และ API ที่ agent เรียกใช้มี contract ชัดเจน ทดสอบได้ และล้มเหลวแบบคาดเดาได้ ตรงนี้คือจุดที่ Apidog ช่วยได้: mock, test และ validate endpoints ก่อนที่ปัญหาจะไปโผล่ใน production

DEV Community