AWS Summit Bangkok 2026 ลิงก์ไปยังหัวข้อ
ปีนี้ผมมีโอกาสบรรยายที่ AWS Summit Bangkok ในหัวข้อ Building Multi-Agent Systems on AWS
ดูสไลด์ได้ที่ SlideShare: Building Scalable Multi-Agent AI Systems on AWS Cloud Platform
จุดเริ่มต้นของผมเรียบง่าย ทุกคนเป็นผู้สร้างได้แล้ว เครื่องมือ AI ช่วยให้สร้างต้นแบบ เดโม เครื่องมือภายใน การทดลอง และโปรเจกต์แปลก ๆ ในวันหยุดสุดสัปดาห์ได้ง่ายขึ้น ความเร็วที่เพิ่มขึ้นนั้นเกิดขึ้นจริง แต่การนำระบบขึ้น production ยังยากอยู่
โซลูชัน AI จำนวนมากยังไปไม่ถึง production เพราะปัญหาแรกไม่ใช่โค้ด แต่คือการเลือกว่าจะเริ่มจากตรงไหน เครื่องมือมีมากเกินไป เฟรมเวิร์กใหม่ทุกตัวดูดี IDE ทุกตัวดูฉลาด และแพลตฟอร์มเอเจนต์ทุกแห่งสัญญาว่าจะทำงานแทนเรา GitHub กำลังกลายเป็น Instagram แบบใหม่ ทุกคนแสดงภาพหน้าจอ เดโม และ commits ที่น่าประทับใจ แต่เราไม่อาจรู้ได้เสมอว่าสิ่งใดทำงานอยู่ใน production จริง
ผมจึงพาการบรรยายไปสู่คำตอบที่ใช้ได้จริงข้อหนึ่ง: สร้างบน AWS
ทางเลือกหนึ่ง: AWS ลิงก์ไปยังหัวข้อ
เครื่องมือพัฒนา AI ของ AWS เชื่อมโยงกันมากขึ้นเรื่อย ๆ
สำหรับเอเจนต์มี Strands Agents สำหรับโมเดล orchestration องค์ความรู้ guardrails และฟีเจอร์ AI แบบ managed มี Amazon Bedrock ส่วนเวิร์กโฟลว์นักพัฒนามี Kiro IDE เมื่อใช้ร่วมกัน เครื่องมือเหล่านี้ให้เส้นทางที่ชัดเจนจากแนวคิดไปสู่ระบบที่ใช้งานได้
สิ่งสำคัญไม่ใช่เพียงเครื่องมือเหล่านี้มีอยู่ แต่คือทำงานร่วมกันได้
คุณสร้างได้เร็วขึ้นเพราะองค์ประกอบต่าง ๆ เชื่อมต่อกัน เก็บข้อมูลไว้ในสภาพแวดล้อมของตนเอง จัดการการเข้าถึงด้วยมาตรการควบคุมของ AWS ที่บริษัทเข้าใจอยู่แล้ว และดูค่าใช้จ่ายได้จากระบบเรียกเก็บเงินแห่งเดียว สำหรับหลายบริษัท สิ่งนี้สำคัญกว่าการใช้เฟรมเวิร์กล่าสุดของสัปดาห์ก่อน
การพัฒนา AI มีความไม่แน่นอนมากพอแล้ว แพลตฟอร์มควรลดความไม่แน่นอน ไม่ใช่เพิ่มขึ้น
ระบบ Multi-Agent ลิงก์ไปยังหัวข้อ
คำแนะนำข้อแรกของผมคือ:
ทีมผู้เชี่ยวชาญดีกว่าผู้เชี่ยวชาญทั่วไปเพียงคนเดียว
เอเจนต์ขนาดใหญ่หนึ่งตัวที่ใช้ prompt มหาศาลอาจดูน่าสนใจในตอนแรก เพราะดูเรียบง่าย แต่เมื่อระบบเติบโตขึ้น เราจะเข้าใจได้ยากว่าทำไมมันจึงตัดสินใจเช่นนั้น ทำไมจึงใช้เครื่องมือหนึ่ง หรือทำไมจึงเพิกเฉยต่อคำสั่ง
ระบบ multi-agent ทำงานได้ดีกว่าเมื่อเอเจนต์แต่ละตัวมีบทบาทจริง:
- เป้าหมายต่างกัน
- เครื่องมือต่างกัน
- บริบทต่างกัน
- เกณฑ์ความสำเร็จต่างกัน
หลักการนี้เหมือนทีมจริง คุณไม่ต้องการคนห้าคนที่รับผิดชอบเรื่องเดียวกัน แต่ต้องการคนหนึ่งดูแลความปลอดภัย คนหนึ่งดูแลการ deploy คนหนึ่งดูแลข้อมูล คนหนึ่งตรวจสอบโค้ด และอีกคนประสานงานทั้งหมด
เอเจนต์ AI ก็เช่นเดียวกัน
ข้อควรระวังอย่างหนึ่งคือ AI มุ่งเป้าหมายอย่างมาก และอาจแยกความแตกต่างระหว่าง เป้าหมายรวม กับ เป้าหมายเฉพาะตัว ของเอเจนต์หนึ่งได้ไม่ดี
หากเป้าหมายรวมคือ “ส่งมอบฟีเจอร์อย่างปลอดภัย” แต่เอเจนต์ตัวหนึ่งมีเป้าหมายเพียง “ทำให้ tests ผ่าน” มันอาจปรับระบบไปผิดทิศทาง เช่น ลบ test ข้ามขั้นตอน validation หรือเปลี่ยนแปลงเฉพาะจุดให้น้อยที่สุดเพื่อซ่อนปัญหาจริง
ดังนั้นเอเจนต์ทุกตัวต้องมีเป้าหมายแคบ แต่ระบบยังต้องมีเป้าหมายรวมที่ชัดเจน
เครื่องมือดีกว่าการควบคุมด้วย Prompt ลิงก์ไปยังหัวข้อ
คำแนะนำข้อที่สองของผมคือ:
เครื่องมือ API, CLI และ MCP ดีกว่าคำสั่งว่า “กรุณาอย่าทำ” หรือ “ห้ามทำโดยเด็ดขาด”
เอเจนต์ต้องลงมือทำ หากให้เพียงคำสั่งข้อความ เรากำลังขอให้โมเดลจดจำกฎและทำตัวสมบูรณ์แบบ ซึ่งเปราะบาง
หากต้องการให้เอเจนต์ deploy ให้เครื่องมือสำหรับ deploy หากต้องการตรวจสอบโครงสร้างพื้นฐาน ให้คำสั่ง CLI แบบอ่านอย่างเดียว หากต้องการให้ทำงานกับระบบภายใน ให้ API ขนาดเล็กหรือ MCP server แม้แต่ CLI ที่มีคำสั่ง --help ที่ดีและไฟล์ skill สั้น ๆ ก็อาจแข็งแกร่งกว่า prompt ยาว ๆ
การปรับแต่ง prompt มีประโยชน์ แต่ไม่ใช่ control plane
รูปแบบที่ดีกว่าคือ:
- ให้เครื่องมือที่ชัดเจนแก่เอเจนต์
- จำกัดขอบเขตเครื่องมือ
- ทำให้สังเกตการทำงานของเครื่องมือได้
- ระบุการกระทำอันตรายอย่างชัดเจน
- ให้เอเจนต์อ่านวิธีใช้และเรียนรู้เวิร์กโฟลว์
วิธีนี้เชื่อถือได้กว่าการพยายามเขียนประโยคที่สมบูรณ์แบบใน system prompt แล้วหวังว่าโมเดลจะทำตามตลอดไป
บริบทเป็นสิ่งจำเป็น ลิงก์ไปยังหัวข้อ
คำแนะนำข้อที่สามของผมคือ:
หากไม่มีองค์ความรู้และประวัติ AI จะเริ่มจากศูนย์ทุกครั้ง
นี่คือช่องว่างที่ใหญ่ที่สุดอย่างหนึ่งของระบบ agentic ในปัจจุบัน
วิศวกรที่เป็นมนุษย์ไม่เริ่มจากศูนย์ทุกเช้า พวกเขาจำได้ว่าทำไมระบบจึงสร้างเช่นนี้ ชั้น authentication เปลี่ยนไปเมื่อปีที่แล้วอย่างไร RDS instance ใดเป็นของ workload ใด และ incident ใน production ครั้งใดทำให้มี guardrail ที่ดูแปลก
เอเจนต์ AI มักจำเรื่องเหล่านี้ไม่ได้ เว้นแต่เราสร้างชั้นบริบทให้
เดโมหลักของเซสชันผมคือ Slack bot ที่เชื่อมกับชั้นองค์ความรู้สำหรับเอเจนต์ AI โดยใช้บริบทจาก AWS, GitHub และ Slack
แนวคิดนี้ใช้ได้จริง:
- เบื่อไหมเมื่อ AI ต้องสแกน AWS Cloud ทั้งหมดเพียงเพื่อหา RDS instance ที่ถูกต้อง?
- คุณเป็นนักพัฒนาที่ลืมว่าเมื่อหนึ่งปีก่อนระบบ authentication ถูกสร้างอย่างไรหรือไม่?
- คุณเป็นหัวหน้าฝ่ายความปลอดภัยที่ต้องการรู้ว่า CVE ใหม่กระทบบริษัทหรือไม่?
ชั้นองค์ความรู้มีประโยชน์ตรงนี้ เพราะให้หน่วยความจำ บริบทของบริษัท และวิธีตอบคำถามโดยคำนึงถึงสภาพแวดล้อมแก่เอเจนต์
หลังพัฒนามาหนึ่งปี ตอนนี้เรามี playground สำหรับทดสอบแนวคิดนี้ มันไม่ใช่เวทมนตร์ แต่ยังคงเป็นงานวิศวกรรม อย่างไรก็ตาม มันแสดงให้เห็นถึงสิ่งที่เป็นไปได้เมื่อเอเจนต์มีบริบทแทนที่จะมีเพียง prompt
สร้างหลายระบบพร้อมกัน ลิงก์ไปยังหัวข้อ
อีกประเด็นที่ผมกล่าวถึงคือ AI เปลี่ยนวิธีที่เราสร้างระบบ
เมื่อมีโครงสร้างเพียงพอ เราสามารถสร้างหลายระบบพร้อมกันได้ ไม่สมบูรณ์แบบและยังต้องมีการตรวจสอบ แต่เร็วกว่าเดิม
หนึ่งในโปรเจกต์งานอดิเรกของผมคือ Personal Private Notetaker
เป้าหมายเรียบง่าย ผมต้องการบันทึกสิ่งที่รับปากกับคนอื่น ทำงานให้สำเร็จดีขึ้น และมอบหมายงานติดตามผลให้เอเจนต์ AI ตัวอื่น นอกจากนี้ผมยังไม่ชอบที่แม้มี Mac Pro อยู่บนโต๊ะ ก็ยังต้องส่งเสียงไปยัง data center ที่ไหนสักแห่งเพียงเพื่อรับข้อความถอดเสียงกลับมา
สำหรับผม AI แบบ local-first ไม่ได้เกี่ยวกับความเป็นส่วนตัวเท่านั้น แต่ยังเกี่ยวกับการควบคุม latency และความไว้วางใจ บางเวิร์กโฟลว์ควรอยู่ใกล้เครื่องและใกล้ตัวบุคคล
ข้อสรุปสำหรับผู้สร้างระบบ AI ลิงก์ไปยังหัวข้อ
AI ทำให้เร็วขึ้น แต่ความเร็วก็ก่อให้เกิดสิ่งรบกวน
ผู้สร้างจึงต้องมีสมาธิ การกำหนดขอบเขตสำคัญกว่าที่เคย หากวิศวกรหนึ่งคนสร้างโค้ด tokens การเปลี่ยนแปลงโครงสร้างพื้นฐาน และ pull requests จำนวนมากได้ วินัยทางวิศวกรรมยิ่งสำคัญขึ้น ไม่ใช่น้อยลง
พื้นฐานยังคงชนะ:
- การ deploy ที่ควบคุมได้
- เจ้าของงานที่ชัดเจน
- guardrails
- การติดตามค่าใช้จ่าย
- observability
- วินัยในการ release
ระบบ multi-agent ทรงพลัง แต่อาจกลายเป็นปัญหา microservices แบบใหม่ อย่าสร้างเอเจนต์จำนวนมากเพียงเพราะทำได้ สร้างเมื่อบทบาท ชุดเครื่องมือ และเป้าหมายต่างกันมากพอที่จะสมควรแยกเป็นผู้เชี่ยวชาญคนละตัว
เกี่ยวกับงาน Summit ลิงก์ไปยังหัวข้อ
AWS Summit Bangkok จัดได้ดีและมีผู้เข้าร่วมหนาแน่น ปีนี้มีคนจำนวนมาก ซึ่งเป็นสัญญาณที่ดีสำหรับชุมชนคลาวด์และ AI ในท้องถิ่น
Developer Lounge สมบูรณ์แบบ ปีนี้เรามีอุปกรณ์ใหม่ซึ่งช่วยได้มาก ทำให้ประสบการณ์ของวิทยากรราบรื่นและรันเดโมได้ง่ายขึ้น
ผมยังเห็นการใช้ gamification ทั่วงานมากขึ้น หลายบูทเป็นเกมจริง ๆ และบางเกมสร้างด้วย Kiro ผู้ร่วมงานเพิ่มฟีเจอร์ของตัวเองได้ระหว่างงาน ทำให้ประสบการณ์สนุกและได้ลงมือทำมากขึ้น
นี่น่าจะเป็นทิศทางที่ถูกต้อง เครื่องมือ AI เข้าใจได้ง่ายขึ้นเมื่อคนสร้างบางสิ่งด้วยเครื่องมือ ไม่ใช่เพียงดูสไลด์
ผมจะเพิ่มภาพจากงานภายหลังเมื่อได้รับ
สำหรับตอนนี้ ข้อความสำคัญคือ:
ผู้สร้างระบบ AI ต้องการสัญญาณรบกวนน้อยลง เครื่องมือที่ดีขึ้น บริบทที่มากขึ้น และวินัยทางวิศวกรรมที่เข้มแข็ง AWS เป็นพื้นที่ที่มั่นคงสำหรับนำองค์ประกอบเหล่านี้มาประกอบกัน