หากคุณเคยสร้าง AI agent โดยการเชื่อมต่อ if/else state machine ขนาดใหญ่เข้าด้วยกัน คุณจะรู้ว่ามันเปราะบางได้เร็วแค่ไหน Strands Agents กลับเลือกแนวทางตรงกันข้าม: ให้โมเดลทำการวางแผน และคุณเพียงแค่ระบุพรอมต์และรายการเครื่องมือ เป็น SDK แบบโอเพนซอร์สจาก AWS ซึ่งเปิดตัวในเดือนพฤษภาคม 2025 ภายใต้ Apache License 2.0 และเป็นส่วนสำคัญในการขับเคลื่อน agent ที่ใช้งานจริงภายในทีม Amazon เช่น Amazon Q Developer และ AWS Glue
Strands Agents คืออะไรกันแน่
Strands Agents เป็น SDK สำหรับสร้างและรัน AI agent ด้วยโค้ดเพียงไม่กี่บรรทัด คุณให้ agent สามสิ่ง: โมเดล, system prompt และชุดเครื่องมือ โมเดลจะอ่านพรอมต์ ตัดสินใจว่าจะเรียกใช้เครื่องมือใด รันเครื่องมือ ดูผลลัพธ์ และดำเนินการต่อไปจนกว่างานจะเสร็จสิ้น วงจรนี้คือทั้งหมดของผลิตภัณฑ์
รองรับทั้ง Python และ TypeScript ชื่อนี้สื่อถึง "สองเส้นสาย" ที่ประกอบกันเป็น agent: โมเดลและเครื่องมือ AWS ได้เปิดเผยเป็นโอเพนซอร์สหลังจากใช้งานภายในองค์กร ดังนั้นการออกแบบจึงสะท้อนถึงความต้องการในการใช้งานจริง ไม่ใช่แค่ตัวอย่าง ตั้งแต่เปิดตัวรุ่นพรีวิว มียอดดาวน์โหลดบน PyPI กว่า 150,000 ครั้ง และได้ออกเวอร์ชัน 1.0 ซึ่งเพิ่มฟังก์ชันพื้นฐานสำหรับ multi-agent และรองรับโปรโตคอล Agent-to-Agent (A2A)
หากคุณเคยอ่านเกี่ยวกับ SDK ของ agent อื่นๆ รูปแบบนี้จะให้ความรู้สึกที่คุ้นเคย Strands อยู่ในหมวดหมู่เดียวกับ LangGraph และ Google ADK แต่ Strands พึ่งพาโมเดลมากขึ้นในการขับเคลื่อนการควบคุมโฟลว์ แทนที่จะให้คุณวาดกราฟด้วยตัวเอง
ปรัชญาที่ขับเคลื่อนด้วยโมเดลเทียบกับการจัดระเบียบแบบฮาร์ดโค้ด
เฟรมเวิร์ก agent ยุคแรกส่วนใหญ่ขอให้คุณกำหนดเวิร์กโฟลว์ล่วงหน้า คุณจะต้องสร้างโหนด, เอดจ์ และเงื่อนไข จากนั้นจึงกำหนดเส้นทางให้โมเดลผ่านสิ่งเหล่านี้ ซึ่งใช้งานได้ แต่ความสามารถใหม่แต่ละอย่างหมายถึงกราฟที่ต้องดูแลรักษามากขึ้น
Strands พลิกกลับความรับผิดชอบ โมเดลที่ทันสมัยสามารถวางแผน, จัดลำดับการให้เหตุผล, เรียกใช้เครื่องมือ และสะท้อนผลลัพธ์ได้อยู่แล้ว ดังนั้น แทนที่จะเข้ารหัสตรรกะเหล่านั้นด้วยตนเอง คุณเพียงแค่อธิบายเป้าหมายและมอบเครื่องมือให้ โมเดลจะหาขั้นตอนเอง
นี่คือความแตกต่างในแง่ที่ชัดเจน:
| แนวทาง | คุณกำหนด | การควบคุมโฟลว์อยู่ใน | ค่าใช้จ่ายของความสามารถใหม่ |
|---|---|---|---|
| การจัดระเบียบแบบฮาร์ดโค้ด | โหนด, เอดจ์, เงื่อนไข, การกำหนดเส้นทาง | โค้ดกราฟของคุณ | แก้ไขกราฟ, ทดสอบเส้นทางซ้ำ |
| ขับเคลื่อนด้วยโมเดล (Strands) | พรอมต์ + รายการเครื่องมือ | วงจรการให้เหตุผลของโมเดล | เพิ่มเครื่องมือ, อัปเดตพรอมต์ |
การแลกเปลี่ยนนี้เป็นเรื่องจริง Agent ที่ขับเคลื่อนด้วยโมเดลจะสร้างและปรับเปลี่ยนได้เร็วกว่า แต่คุณจะต้องยอมแลกกับความสามารถในการคาดเดาผลลัพธ์ที่ลดลง สำหรับเวิร์กโฟลว์ที่ต้องทำงานในลักษณะเดียวกันทุกครั้ง คุณยังคงสามารถเพิ่มโครงสร้างด้วยรูปแบบ multi-agent และ hooks ได้ จุดประสงค์ไม่ใช่ว่ากราฟผิด แต่คือการที่คุณจะใช้กราฟเมื่อคุณต้องการเท่านั้น แทนที่จะใช้เป็นค่าเริ่มต้น
Agent ขนาดเล็กที่สุด
โปรแกรม Strands ที่มีประโยชน์ที่สุดขนาดเล็กนั้นสั้น คุณนำเข้าคลาส Agent, กำหนดเครื่องมือด้วย decorator @tool (เป็นทางเลือก) และเรียก agent เหมือนฟังก์ชัน
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)
Decorator @tool จะเปลี่ยนฟังก์ชัน Python ธรรมดาให้เป็นสิ่งที่โมเดลสามารถเรียกใช้ได้ Docstring และ type hints ของคุณจะกลายเป็นคำอธิบายและ Schema อินพุตของเครื่องมือ ทำให้โมเดลรู้ว่าจะใช้เมื่อใดและอย่างไร ไม่มีการลงทะเบียนแยกต่างหากที่ต้องดูแล การเรียกใช้ agent(...) จะรันลูปจนกว่าโมเดลจะตัดสินใจว่างานเสร็จสิ้น
เครื่องมือและผู้ให้บริการโมเดล
เครื่องมือคือวิธีที่ agent สัมผัสโลกภายนอก เครื่องมือสามารถเป็นฟังก์ชัน Python ที่คุณเขียน เครื่องมือที่บรรจุจากชุมชน หรือแม้แต่เซิร์ฟเวอร์ Model Context Protocol (MCP) ทั้งหมดที่เปิดเผยให้ agent ใช้งาน
ในฝั่งของโมเดล Strands มีความยืดหยุ่นในการเลือกผู้ให้บริการ ผู้ให้บริการเริ่มต้นคือ Amazon Bedrock และโดยปกติ agent จะใช้โมเดล Claude Sonnet ในภูมิภาค us-west-2 (ID โมเดลเริ่มต้นที่แน่นอนมีการเปลี่ยนแปลงในแต่ละเวอร์ชัน SDK ดังนั้นควรตรวจสอบเวอร์ชันที่ติดตั้งแทนที่จะฮาร์ดโค้ด) คุณสามารถชี้ไปยังที่อื่นได้:
- โมเดล Amazon Bedrock ใดๆ ที่รองรับการใช้เครื่องมือและการสตรีม
- ตระกูล Claude ของ Anthropic ผ่าน Anthropic API
- โมเดล Llama ผ่าน Llama API
- Ollama สำหรับการพัฒนาในเครื่อง
- ผู้ให้บริการอื่นๆ เช่น OpenAI ผ่าน LiteLLM
การสลับผู้ให้บริการคือการเปลี่ยนวัตถุโมเดล ไม่ใช่การเขียนโค้ดใหม่ ลูปของ agent เครื่องมือของคุณ และพรอมต์ของคุณยังคงเหมือนเดิม ทำให้การพัฒนาโดยใช้โมเดล Ollama ในเครื่องและนำไปใช้บน Bedrock เป็นไปได้จริง
รองรับ Multi-agent และ MCP
Agent ตัวเดียวสามารถจัดการงานได้มากมาย แต่ระบบจริงมักต้องการ agent หลายตัว Strands 1.0 ได้เพิ่มพื้นฐานสำหรับแอปพลิเคชัน multi-agent รวมถึงรูปแบบ Agent-as-Tool ที่ agent หนึ่งเรียก agent อื่นในลักษณะเดียวกับการเรียกเครื่องมือใดๆ และการประสานงานแบบ Swarm สำหรับกลุ่ม agent ที่ทำงานร่วมกันเพื่อแก้ไขปัญหา นอกจากนี้ยังรองรับโปรโตคอล A2A ทำให้ Strands agent สามารถสื่อสารกับ agent ที่สร้างขึ้นบนเฟรมเวิร์กอื่นได้
MCP เป็นส่วนสำคัญ Model Context Protocol เป็นมาตรฐานเปิดสำหรับการเชื่อมต่อโมเดลเข้ากับเครื่องมือและแหล่งข้อมูล ด้วย Strands คุณสามารถเชื่อมต่อกับเซิร์ฟเวอร์ MCP ที่เผยแพร่และใช้เครื่องมือของพวกเขาได้โดยตรง ซึ่งหมายความว่าการรวมระบบที่มีอยู่หลายพันรายการสามารถใช้งานได้โดยไม่ต้องเขียนโค้ดเชื่อมต่อที่กำหนดเอง คุณจัดการการเชื่อมต่อผ่านไคลเอนต์ MCP และส่งผ่านเครื่องมือของมันไปยัง agent เหมือนรายการเครื่องมืออื่นๆ
หากคุณกำลังรันเซิร์ฟเวอร์ MCP อยู่แล้ว นี่เป็นวิธีที่ประหยัดที่สุดในการเพิ่มความสามารถใหม่ให้กับ agent ข้อเสียคือคุณต้องพึ่งพาเซิร์ฟเวอร์เหล่านั้นให้ทำงานได้ ซึ่งเป็นเหตุผลหนึ่งที่การทดสอบปลายทางพื้นฐานมีความสำคัญ
การปรับใช้ Strands agent
Strands สร้างขึ้นเพื่อให้สามารถย้ายจากแล็ปท็อปของคุณไปสู่การใช้งานจริงได้โดยไม่ต้องเปลี่ยนเฟรมเวิร์ก คุณทดสอบในเครื่อง จากนั้นปรับใช้กับเป้าหมายที่เข้ากับสแตกของคุณ:
- Amazon Bedrock AgentCore สำหรับรันไทม์ agent ที่มีการจัดการ
- AWS Lambda สำหรับ agent ที่ขับเคลื่อนด้วยเหตุการณ์และมีอายุสั้น
- AWS Fargate หรือ Amazon EKS สำหรับบริการที่ทำงานต่อเนื่องแบบคอนเทนเนอร์
- Plain Docker ทุกที่ที่คุณสามารถรันคอนเทนเนอร์ได้
เนื่องจาก agent เป็น Python หรือ TypeScript ทั่วไป การบรรจุหีบห่อจึงเป็นไปตามกฎเดียวกับแอปพลิเคชันใดๆ AWS ยังมีเอกสารเกี่ยวกับ observability hooks เพื่อให้คุณสามารถติดตามว่าโมเดลตัดสินใจอะไรและเรียกใช้เครื่องมือใดเมื่อ agent ทำงานจริง
Apidog เหมาะสมตรงไหน
Strands สร้าง agent แต่ไม่ได้สร้าง API ที่ agent ของคุณเรียกใช้ และนี่คือช่องว่างที่ควรค่าแก่การวางแผน agent ของ Strands ทุกตัวจะพึ่งพา HTTP endpoints สองประเภท: LLM provider API ที่อยู่เบื้องหลังโมเดล และ REST หรือ tool API ที่อยู่เบื้องหลังฟังก์ชัน @tool และเซิร์ฟเวอร์ MCP ของคุณ หาก endpoints เหล่านั้นทำงานผิดปกติ agent จะล้มเหลวในลักษณะที่ดูเหมือนปัญหาของโมเดลแต่ไม่ใช่
Apidog เป็นที่ที่คุณทดสอบและจำลอง API พื้นฐานเหล่านั้นก่อนที่ agent จะแตะต้องพวกมันเลย การใช้งานที่เป็นรูปธรรมบางประการ:
- จำลองโมเดลหรือ tool endpoint ขณะที่คุณวนซ้ำบนลูป เพื่อที่คุณจะได้ไม่เปลืองโทเค็นหรือชนข้อจำกัดอัตราการเรียกใช้ในทุกครั้ง บทความเกี่ยวกับการสร้าง AI agent test harness ด้วย Apidog แสดงรูปแบบนี้
- ยืนยันรูปแบบการตอบสนองของเครื่องมือ เพื่อให้เครื่องมือที่ส่งคืนเพย์โหลดที่ผิดรูปแบบถูกตรวจจับในการทดสอบ ไม่ใช่ในการผลิต ดูคู่มือเกี่ยวกับ API assertions สำหรับวิธีการตรวจสอบฟิลด์, ประเภท และรหัสสถานะ
- ตั้งค่า mock API ที่เลียนแบบการตอบสนองของบริการจริง รวมถึงกรณีข้อผิดพลาดที่ agent ของคุณต้องจัดการอย่างเหมาะสม
- จัดการ API keys ตามสภาพแวดล้อม เพื่อให้ agent สำหรับ dev, staging และ prod ของคุณรับรองความถูกต้องกับแบ็กเอนด์ที่ถูกต้องโดยไม่เปิดเผยข้อมูลรับรองในโค้ด
เพื่อความชัดเจน Apidog ไม่ใช่เฟรมเวิร์กของ agent และไม่ได้จัดระเบียบอะไร Strands ยังคงเป็นสมอง Apidog เป็นเวิร์กเบนช์สำหรับระบบท่อที่อยู่เบื้องล่าง คุณสามารถ ดาวน์โหลด Apidog และตั้งค่า mocks สำหรับ tool endpoints ของคุณได้ภายในไม่กี่นาที
ควรใช้ Strands Agents เมื่อใด
เลือกใช้ Strands เมื่อคุณต้องการทำงานได้รวดเร็วและเชื่อมั่นในโมเดลที่จะวางแผน มันเหมาะสมอย่างยิ่งหากคุณอยู่บน AWS และใช้งาน Bedrock อยู่แล้ว หากคุณต้องการเริ่มต้นด้วย agent ตัวเดียวและขยายไปสู่ multi-agent ในภายหลัง หรือหากคุณต้องการเครื่องมือ MCP โดยไม่ต้องเขียนโค้ดรวมระบบ
มันอาจไม่เหมาะสมนักเมื่อคุณต้องการโฟลว์ที่เข้มงวด ตรวจสอบได้ และคาดเดาผลลัพธ์ได้ ซึ่งทุกสาขาจะต้องถูกกำหนดไว้ล่วงหน้า คุณยังคงสามารถทำได้ด้วย hooks และโครงสร้าง multi-agent แต่เฟรมเวิร์กที่เน้นกราฟเป็นหลักอาจเป็นทางเลือกที่ตรงกว่า การยอมรับอย่างตรงไปตรงมาคือแนวทางที่ขับเคลื่อนด้วยโมเดลและแนวทางที่ขับเคลื่อนด้วยกราฟแก้ปัญหาที่แตกต่างกัน และ Strands เป็นแนวทางที่ขับเคลื่อนด้วยโมเดล
คำถามที่พบบ่อย
Strands Agents เป็นโอเพนซอร์สและใช้งานฟรีหรือไม่
ใช่ Strands Agents เป็นโอเพนซอร์สภายใต้ Apache License 2.0 โดยมีซอร์สโค้ดอยู่บน GitHub ไม่มีค่าธรรมเนียมใบอนุญาตสำหรับ SDK คุณจ่ายค่าโมเดลและทรัพยากรคลาวด์ใดๆ ที่คุณปรับใช้ เช่น การอนุมานของ Bedrock หรือการดำเนินการของ Lambda แต่ตัวเฟรมเวิร์กเองไม่มีค่าใช้จ่าย
ฉันต้องใช้ Amazon Bedrock กับ Strands หรือไม่
ไม่ Bedrock เป็นผู้ให้บริการเริ่มต้น แต่ Strands รองรับ Anthropic API, Llama API, Ollama สำหรับการรันในเครื่อง และผู้ให้บริการอื่นๆ ผ่าน LiteLLM คุณเพียงแค่เปลี่ยนวัตถุโมเดลและเก็บโค้ดส่วนที่เหลือไว้เหมือนเดิม ทำให้ง่ายต่อการสร้างต้นแบบในเครื่องและเปลี่ยนไปใช้ผู้ให้บริการที่มีการจัดการสำหรับการผลิต
อะไรคือความแตกต่างระหว่าง Strands กับเฟรมเวิร์กที่ใช้กราฟเป็นหลัก
Strands เป็นแบบ model-driven: คุณให้พรอมต์และเครื่องมือ และโมเดลจะตัดสินใจขั้นตอนต่างๆ เฟรมเวิร์กที่ใช้กราฟเป็นหลักจะขอให้คุณกำหนดการควบคุมโฟลว์เป็นโหนดและเอดจ์ Strands สร้างและปรับเปลี่ยนได้เร็วกว่า; เฟรมเวิร์กกราฟช่วยให้คุณดำเนินการได้แน่นหนาและคาดเดาได้มากกว่า หลายทีมใช้ทั้งสองวิธีสำหรับบริการที่แตกต่างกัน
ฉันจะทดสอบ API ที่ Strands agent ของฉันพึ่งพาได้อย่างไร
ทดสอบแยกจาก agent ทั้งก่อนและระหว่างการพัฒนา จำลอง LLM และ tool endpoints ยืนยันรูปแบบการตอบสนองของพวกมัน และรันการตรวจสอบเหล่านั้นใน CI เครื่องมืออย่าง Apidog จัดการการจำลองและการยืนยัน และคำแนะนำเกี่ยวกับ การทดสอบ ChatGPT API ด้วย Apidog ครอบคลุมการยืนยันตัวตน การสตรีม และการทดสอบการเรียกใช้เครื่องมือที่เชื่อมโยงโดยตรงกับแบ็กเอนด์ของ agent
สรุป
Strands Agents นำเสนอแนวคิดที่ชัดเจนในการสร้าง agent: กำหนดโมเดล, พรอมต์ และเครื่องมือ จากนั้นให้โมเดลรันลูป มันสามารถปรับขนาดได้ตั้งแต่ agent หนึ่งตัวไปจนถึงหลายตัว รองรับ MCP และ A2A และปรับใช้บนสแตก AWS ได้โดยไม่ต้องเขียนโค้ดใหม่ เฟรมเวิร์กจัดการเรื่องการให้เหตุผล งานของคุณคือการตรวจสอบให้แน่ใจว่า API ที่อยู่เบื้องล่างนั้นแข็งแกร่ง และนั่นคือจุดที่ Apidog เข้ามามีบทบาท โดยจำลองและทดสอบ endpoints ที่ agent ของคุณเรียกใช้ เพื่อให้ความล้มเหลวปรากฏในการทดสอบของคุณแทนที่จะเป็นการผลิต