นักพัฒนา Microsoft Teams กำลังได้รับคำเตือนว่าการเรียกส่วนขยาย (extension) ทุกอย่างว่าเป็น “bot” กำลังทำให้เกิดความล้มเหลวในระดับการใช้งานจริง (production-grade failures) ในปี 2026 ข้อจำกัดของแพลตฟอร์มเอง—คือต้องตอบกลับข้อความภายใน 10 ถึง 15 วินาที—จะเปลี่ยน bot ที่ออกแบบสถาปัตยกรรมมาไม่ดีให้กลายเป็นพายุแห่งการ timeout ที่บีบให้ทีมต่างๆ ต้องออกแบบ pipeline ใหม่

ทำไมการแยกแยะความแตกต่างจึงสำคัญ

Teams มีส่วนขยายสามประเภท ซึ่งแต่ละประเภทถูกสร้างขึ้นมาเพื่อรูปแบบการโต้ตอบที่แตกต่างกัน การใช้ปนกันจะทำให้ต้องใช้ runtime, SDK และโมเดลการขยายระบบ (scaling model) ที่ไม่ถูกต้อง

Teams apps, bots และ agents คืออะไร

  • Teams apps – แท็บ (tabs) บนหน้าจอ, หน้าเว็บแบบ static หรือส่วนประกอบ UI ง่ายๆ ภายใน Teams client โดยพื้นฐานแล้วคือเว็บแอป: ไม่มีสถานะ (stateless), แสดงผลเมื่อมีการเรียกใช้ (rendered on demand) และโฮสต์เหมือนกับบริการ HTTP อื่นๆ โดยไม่จำเป็นต้องมีลำดับการสนทนา
  • Bots – สร้างด้วย Bot Framework SDK โดย bot จะทำตามบทสนทนาที่กำหนดไว้ (scripted dialogs) ตรรกะของมันคือโครงสร้าง if/else แบบ deterministic ที่ตัดสินใจว่าจะตอบกลับอย่างไรโดยอิงจากกิจกรรมที่ส่งเข้ามาเท่านั้น เนื่องจากเส้นทางการตัดสินใจถูกกำหนดไว้ล่วงหน้า การตอบกลับจึงสามารถทำได้ภายในกรอบเวลา timeout อันสั้นของแพลตฟอร์ม
  • Agents – เอนทิตีที่ขับเคลื่อนด้วยเป้าหมาย (goal-driven) ซึ่งจะได้รับวัตถุประสงค์ระดับสูง ชุดเครื่องมือ และ LLM (large language model) โดยการใช้ Agents SDK หรือ Semantic Kernel ตัว LLM จะเป็นผู้เลือกเองว่าจะเรียกใช้เครื่องมือใด ในลำดับไหน และเมื่อใดที่ต้องขอคำชี้แจงจากผู้ใช้ ลำดับการทำงานจะเป็นแบบไดนามิก ซึ่งมักต้องมีการเรียกใช้งานภายนอกหลายครั้งและต้องใช้การใช้เหตุผล (reasoning) อย่างหนัก

ความแตกต่างนั้นชัดเจนมาก: bot คือแบบ deterministic; ส่วน agent คือแบบ probabilistic และทำหน้าที่จัดการการเรียกใช้เครื่องมือ (orchestrates tool calls) ในขณะทำงาน (at runtime)

กับดัก timeout

เมื่อนักพัฒนาใส่กระบวนการคิดที่ซับซ้อน (heavy reasoning)—เช่น LLM prompts, การค้นหาฐานข้อมูล หรือการเรียก external API—ลงไปใน message handler ของ bot โดยตรง Teams จะมองว่าคำขอนั้นค้างเกินกรอบเวลา 10-15 วินาที แพลตฟอร์มจะยกเลิกการตอบกลับและพยายามส่งใหม่ (retry) ซึ่งอาจส่งผลกระทบต่อเนื่องเป็นงานที่ซ้ำซ้อนและการถูกจำกัดการใช้งาน (throttling) อาการที่ปรากฏจะดูเหมือนข้อผิดพลาด “bot not responding” ที่เกิดขึ้นเป็นพักๆ แต่สาเหตุที่แท้จริงมาจากสถาปัตยกรรม

การสร้าง async pipeline ที่พร้อมใช้งานจริง

  1. Webhook entry point – HTTP endpoint ของ bot จะรับ Teams activity และตอบรับการได้รับข้อมูลทันที
  2. Queue the event – ตัว handler จะส่ง payload ไปยัง queue ที่มีความทนทาน (durable queue) เช่น Azure Service Bus
  3. Background worker – Azure Durable Function, Service Bus trigger หรือ worker ที่ทำงานต่อเนื่อง (long-running worker) จะดึงข้อความไปประมวลผลการคิดของ LLM หรือการจัดการเครื่องมือ (tool orchestration) แล้วจึงส่งคำตอบสุดท้ายกลับไปยัง Teams ผ่าน proactive messaging API ของ Bot Framework

เนื่องจาก webhook เริ่มต้นจะตอบกลับทันที Teams จึงไม่พบปัญหา timeout และงานที่หนักจะดำเนินต่อไปตามจังหวะของมันเอง โดยมี queue ช่วยรองรับการใช้งานที่พุ่งสูงขึ้น (spikes) และ worker จะขยายขนาดอัตโนมัติ (auto-scale) ตามความยาวของคิวงานที่ค้างอยู่

คู่มือการตัดสินใจอย่างรวดเร็ว (การทดสอบด้วยไวท์บอร์ด)

  • คุณสามารถวาดแผนผังการตัดสินใจ (decision tree) ทั้งหมดได้ก่อนที่จะเริ่มเขียนโค้ดหรือไม่? ใช่ → สร้าง bot เพราะ flow แบบ deterministic นั้นเหมาะสมกับโมเดลของ Bot Framework และอยู่ในกรอบเวลาการตอบกลับ
  • ปัญหาถูกกำหนดด้วยเป้าหมายระดับสูงและรายการเครื่องมือที่อาจเป็นไปได้ใช่หรือไม่? ใช่ → สร้าง agent ให้ LLM วางแผนและเรียกใช้เครื่องมือ โดยย้ายการวางแผนไปไว้ที่ background worker

สิ่งที่ควรติดตามต่อไป

คำแนะนำนี้เป็นตอนแรกของซีรีส์สำหรับนักพัฒนา .NET 9 ที่กำลังสร้างโซลูชัน Teams อัจฉริยะบน Azure

หากคุณเริ่มเห็นข้อผิดพลาด “Bot timed out” ใน Teams logs วิธีแก้ไขนั้นง่ายมาก: แยก webhook ออกจากงานที่ต้องใช้ทรัพยากรสูง (heavy lift), เปลี่ยนไปใช้ queue-driven worker และเลือกประเภทส่วนขยายที่ถูกต้องตั้งแต่เริ่มต้น แพลตฟอร์มมีขีดจำกัดเรื่อง timeout แต่สถาปัตยกรรมของคุณสามารถหลีกเลี่ยงมันได้

สรุป: การระบุประเภทส่วนขยายของ Teams ผิดว่าเป็น bot จะเป็นการบังคับให้ใช้การออกแบบแบบ synchronous ซึ่ง Teams ไม่สามารถรองรับได้ จงแยกคำขอ (request) ออกจากกระบวนการคิด (reasoning), เลือก SDK ที่เหมาะสม แล้วโซลูชัน Teams ของคุณจะยังคงตอบสนองได้รวดเร็ว แม้ว่า "สมอง" ที่อยู่เบื้องหลังจะเป็น agent ที่ขับเคลื่อนด้วย LLM ก็ตาม