ทีมซัพพอร์ตต้องตอบลูกค้าพร้อมกันหลักร้อยแชทต่อวัน จะให้ AI จำบทสนทนาแต่ละคนได้จริงไหม

ทีมซัพพอร์ตของบริษัทอีคอมเมิร์ซขนาดกลางแห่งหนึ่งต้องรับมือกับแชทลูกค้าพร้อมกันหลักร้อยบทสนทนาต่อวัน ในช่วงเทศกาลลดราคาตัวเลขนี้พุ่งขึ้นไปอีกหลายเท่า ทีมจึงอยากใช้ AI ช่วยตอบคำถามเบื้องต้นก่อนโอนสายให้พนักงานจริง แต่ปัญหาที่เจอตั้งแต่ต้นคือ AI ที่ต่อผ่าน Workers ธรรมดาตอบแต่ละข้อความราวกับเป็นคนละบทสนทนา ลืมทุกอย่างที่ลูกค้าพิมพ์ไปก่อนหน้าทันทีที่ Request จบลง

ปัญหานี้ไม่ใช่ข้อจำกัดของโมเดล AI แต่เป็นข้อจำกัดของสถาปัตยกรรม เพราะ Workers ธรรมดาถูกออกแบบมาให้เป็น Stateless คือแต่ละ Request จบแล้วจบเลย ไม่มีที่เก็บสถานะของบทสนทนานั้นไว้ในตัว Worker เอง ถ้าอยากให้ AI จำบริบทได้ ทีมต้องแบกภาระออกแบบระบบเก็บสถานะแยกต่างหากเอง ซึ่งซับซ้อนกว่าที่คิดเมื่อมีบทสนทนาพร้อมกันจำนวนมาก

Cloudflare Agents เกิดมาเพื่อแก้ปัญหานี้โดยตรง บทความนี้จะอธิบายว่า Agents คืออะไร ต่างจาก Workers ทั่วไปตรงไหน ทำงานยังไงเบื้องหลัง เหมาะกับงานแบบไหน และมีจุดไหนที่ทีมต้องออกแบบระวังก่อนนำไปใช้กับระบบที่มีผู้ใช้จริงจำนวนมาก

Cloudflare Agents คืออะไร ต่างจาก Workers ตรงไหน

Cloudflare Agents คือชุดเครื่องมือที่สร้างขึ้นบนพื้นฐานของ Cloudflare Workers และ Durable Objects เพื่อให้สร้าง AI Agent ที่มีสถานะของตัวเองได้ แต่ละ Agent จะได้รับ Instance เฉพาะของตัวเอง (ผูกกับ ID เช่น รหัสบทสนทนาหรือรหัสผู้ใช้) ที่เก็บสถานะไว้ต่อเนื่องข้าม Request โดยไม่หายไปเมื่อ Request หนึ่งจบลง

ความต่างสำคัญจาก Workers ทั่วไปคือ Workers เป็น Stateless เกิดขึ้นชั่วขณะ ตอบ Request แล้วจบ ในขณะที่ Agent เป็น Stateful มีวงจรชีวิตที่ยาวกว่า สามารถจำข้อมูลของบทสนทนาก่อนหน้า เก็บสถานะการทำงานที่ต้องผ่านหลายขั้นตอน และตอบสนองต่อเหตุการณ์ที่เกิดขึ้นภายหลังได้ เช่น ตั้งเวลาให้ทำงานบางอย่างในอนาคต

สิ่งที่ทำให้ Agents ต่างจากการสร้าง Chatbot Framework ทั่วไปคือมันรันอยู่บนเครือข่าย Edge เดียวกับ Workers ทำให้ Agent แต่ละตัวตอบสนองได้เร็วและกระจายอยู่ใกล้ผู้ใช้ โดยทีมไม่ต้องดูแล Server สำหรับเก็บสถานะแยกต่างหาก ซึ่งเป็นภาระที่ทีมส่วนใหญ่มักประเมินความซับซ้อนต่ำเกินไปตอนเริ่มสร้างระบบเอง

สถานะของ Agent เก็บไว้ที่ไหน และคงอยู่ได้นานแค่ไหน

เบื้องหลังการเก็บสถานะของ Agent อาศัย Durable Objects ซึ่งเป็นเทคโนโลยีที่ให้แต่ละ Instance มีที่เก็บข้อมูลเฉพาะของตัวเองที่รับประกันความสอดคล้อง (Consistency) แม้มี Request หลายตัวพยายามเข้าถึง Instance เดียวกันพร้อมกัน ต่างจากการพยายามเก็บสถานะไว้ใน KV ธรรมดาที่ออกแบบมาสำหรับการอ่านเร็วมากกว่าการอัปเดตบ่อยและซับซ้อน

สถานะของ Agent จะคงอยู่ตราบเท่าที่ทีมไม่ได้ลบทิ้งหรือตั้งเงื่อนไขให้หมดอายุ ซึ่งต่างจากความเข้าใจผิดที่หลายคนคิดว่า Agent จะ 'หลับ' แล้วลืมทุกอย่างเหมือน Session ทั่วไปที่หมดอายุตามเวลา ทีมสามารถออกแบบให้ Agent เก็บประวัติบทสนทนาไว้นานเท่าที่ต้องการ หรือให้หมดอายุตามนโยบายที่เหมาะกับลักษณะธุรกิจ เช่น เก็บไว้สามสิบวันสำหรับงานซัพพอร์ตทั่วไป

จุดที่ต้องเข้าใจคือการเก็บสถานะจำนวนมากในระยะยาวมีผลต่อทั้งต้นทุนและประสิทธิภาพ ทีมจึงควรออกแบบให้ Agent เก็บเฉพาะข้อมูลที่จำเป็นต่อการทำงานจริง เช่น สรุปบริบทสำคัญของบทสนทนา แทนที่จะเก็บข้อความดิบทั้งหมดแบบไม่มีขอบเขต ซึ่งจะทำให้สถานะบวมขึ้นเรื่อย ๆ โดยไม่จำเป็น

ความสามารถหลักที่ Agent ทำได้มากกว่า Workers ธรรมดา

• จำบริบทข้ามหลาย Request — Agent จำข้อความก่อนหน้าในบทสนทนาเดียวกันได้ โดยไม่ต้องส่งประวัติทั้งหมดแนบมากับทุก Request จากฝั่ง Client
• ตั้งเวลาให้ทำงานในอนาคต (Scheduling) — เช่น ตั้งให้ Agent ส่งข้อความติดตามผลลูกค้าอัตโนมัติหลังจากไม่มีการตอบกลับเกินระยะเวลาที่กำหนด
• เรียกใช้เครื่องมือภายนอก (Tool Calling) — Agent สามารถเรียก API อื่นระหว่างการทำงาน เช่น ตรวจสอบสถานะคำสั่งซื้อจากฐานข้อมูล ก่อนตอบกลับผู้ใช้ด้วยข้อมูลที่ถูกต้องล่าสุด
• สื่อสารแบบ Real-time ผ่าน WebSocket — เหมาะกับงานที่ต้องการอัปเดตสถานะให้ผู้ใช้เห็นทันทีที่มีการเปลี่ยนแปลง แทนที่จะให้ผู้ใช้ต้องกดรีเฟรชเอง

งานแบบไหนที่ใช้ Agents ได้ประโยชน์ชัดเจนที่สุด

จากลักษณะการทำงานที่เน้นเรื่องสถานะและการทำงานต่อเนื่องหลายขั้นตอน Agents เหมาะกับงานบางประเภทเป็นพิเศษมากกว่างานทั่วไป

ขั้นตอนคร่าว ๆ ในการสร้าง Agent ตัวแรก

1. กำหนดขอบเขตของ Agent ให้ชัดเจนก่อนเริ่มเขียนโค้ด เช่น Agent นี้รับผิดชอบเฉพาะการตอบคำถามเกี่ยวกับสถานะคำสั่งซื้อ ไม่ใช่ทำทุกอย่างในระบบซัพพอร์ตพร้อมกัน
2. ออกแบบโครงสร้างสถานะที่ Agent ต้องเก็บ เช่น ประวัติบทสนทนาแบบสรุป ข้อมูลผู้ใช้ที่จำเป็น และสถานะของขั้นตอนที่กำลังดำเนินอยู่ โดยเก็บเฉพาะที่จำเป็นจริงต่อการทำงาน
3. เชื่อมต่อ Agent กับโมเดล AI ที่ต้องการใช้ ไม่ว่าจะผ่าน Workers AI หรือ Provider ภายนอกผ่าน AI Gateway แล้วออกแบบ Prompt ให้ Agent เข้าใจบทบาทและขอบเขตของตัวเอง
4. ทดสอบพฤติกรรมของ Agent ในสถานการณ์ที่มีหลายบทสนทนาเกิดขึ้นพร้อมกัน เพื่อยืนยันว่าสถานะของแต่ละ Instance ไม่ปนกันหรือกระทบกันเอง
5. วางแผนนโยบายหมดอายุของสถานะและตรวจสอบต้นทุนการเก็บข้อมูลก่อน Deploy ขึ้นใช้งานจริงกับผู้ใช้จำนวนมาก

ออกแบบให้มีคนเข้ามาแทรกได้ ไม่ใช่ปล่อยให้ Agent ตัดสินใจทุกอย่างเอง

หนึ่งในความผิดพลาดที่พบบ่อยของทีมที่เพิ่งเริ่มสร้าง Agent คือออกแบบให้มันตัดสินใจทุกอย่างเองโดยไม่มีจุดให้มนุษย์เข้ามาตรวจสอบหรือแทรกแซง ซึ่งเสี่ยงมากสำหรับงานที่มีผลกระทบสูง เช่น การอนุมัติคืนเงินหรือการยกเลิกคำสั่งซื้อ

แนวทางที่ปลอดภัยกว่าคือออกแบบให้ Agent จัดการงานที่มีความเสี่ยงต่ำได้เองทั้งหมด เช่น ตอบคำถามทั่วไปหรือดึงข้อมูลสถานะมาแสดง แต่สำหรับงานที่มีผลกระทบสูงให้ Agent เตรียมข้อมูลและข้อเสนอแนะไว้ให้พนักงานจริงเป็นคนตัดสินใจขั้นสุดท้าย แทนที่จะให้ Agent ดำเนินการเองทั้งหมดโดยไม่มีการตรวจสอบ

การมีจุด Human-in-the-loop แบบนี้ไม่ได้ทำให้ Agent มีประโยชน์น้อยลง เพราะงานส่วนใหญ่ที่กินเวลาพนักงานจริงมักเป็นงานซ้ำ ๆ ที่ความเสี่ยงต่ำอยู่แล้ว การให้ Agent จัดการส่วนนั้นแทนก็ปลดภาระได้มากพอ โดยยังคงความปลอดภัยของงานที่สำคัญไว้กับคนที่มีอำนาจตัดสินใจจริง

ตรวจสอบและ Debug Agent ยังไงเมื่อพฤติกรรมเริ่มผิดปกติ

ความยากอย่างหนึ่งของการดูแล Agent ที่มีสถานะซับซ้อนคือการ Debug เมื่อพฤติกรรมของมันเริ่มแปลกไปจากที่คาดไว้ เพราะปัญหาอาจไม่ได้เกิดจาก Request ล่าสุด แต่เกิดจากสถานะที่สะสมมาจากหลายขั้นตอนก่อนหน้า ทำให้การไล่หาสาเหตุยากกว่าการ Debug Worker ธรรมดาที่แต่ละ Request เป็นอิสระจากกัน

แนวทางที่ช่วยได้มากคือบันทึก Log ของทุกจุดที่ Agent เปลี่ยนแปลงสถานะสำคัญ ไม่ใช่แค่ Log ตอนตอบกลับผู้ใช้เท่านั้น เช่น เมื่อ Agent ตัดสินใจเรียกใช้เครื่องมือภายนอก เมื่อสถานะการทำงานเปลี่ยนจากขั้นตอนหนึ่งไปอีกขั้นตอนหนึ่ง หรือเมื่อมีการตั้งเวลาให้ทำงานในอนาคต การมี Log ละเอียดระดับนี้ทำให้ทีมย้อนดูเส้นทางการตัดสินใจของ Agent ได้ทั้งหมดเมื่อเกิดปัญหา

อีกแนวทางที่หลายทีมใช้คือสร้างสภาพแวดล้อมทดสอบที่จำลองสถานะซับซ้อนได้ เช่น ทดสอบ Agent ที่มีประวัติบทสนทนายาวหรือมีสถานะค้างจากขั้นตอนก่อนหน้าจริง แทนที่จะทดสอบแค่บทสนทนาสั้น ๆ เริ่มต้นใหม่ทุกครั้ง เพราะพฤติกรรมผิดปกติหลายอย่างจะปรากฏชัดก็ต่อเมื่อสถานะสะสมมาถึงจุดหนึ่งเท่านั้น

ทำแบบนี้แล้วพัง เพราะออกแบบ Agent เหมือน Workers ธรรมดา

• ไม่ได้กำหนดขอบเขตความรับผิดชอบของ Agent ให้ชัดเจน — ทำให้ Agent พยายามตอบทุกเรื่องแม้ไม่มีข้อมูลเพียงพอ ซึ่งเสี่ยงต่อการให้คำตอบผิดพลาดโดยผู้ใช้ไม่รู้ตัว
• เก็บประวัติบทสนทนาแบบดิบทั้งหมดไม่มีขอบเขต — ทำให้สถานะบวมขึ้นเรื่อย ๆ กระทบทั้งต้นทุนและความเร็วในการประมวลผลของ Agent เมื่อบทสนทนายาวขึ้นเรื่อย ๆ
• ไม่มีจุดให้มนุษย์เข้ามาตรวจสอบงานที่มีผลกระทบสูง — ปล่อยให้ Agent ตัดสินใจเรื่องสำคัญเองทั้งหมด ซึ่งเสี่ยงเมื่อ Prompt หรือข้อมูลที่ได้รับมาไม่ครบถ้วน
• ไม่ได้ทดสอบสถานการณ์ที่มีหลายบทสนทนาเกิดขึ้นพร้อมกัน — บางทีมทดสอบแค่บทสนทนาเดียวแล้วคิดว่าใช้งานได้จริง แต่ไม่ได้ตรวจว่าสถานะของแต่ละ Instance แยกจากกันถูกต้องเมื่อมีผู้ใช้จำนวนมากพร้อมกัน

สรุป

Cloudflare Agents เติมความสามารถด้านสถานะและการตัดสินใจต่อเนื่องหลายขั้นตอนให้กับ Workers ที่เดิมเป็น Stateless ทำให้สร้างระบบที่ต้องจำบริบทการสนทนา ตั้งเวลาทำงาน และเรียกใช้เครื่องมือภายนอกได้โดยไม่ต้องดูแล Infrastructure เก็บสถานะแยกต่างหาก

สิ่งที่ควรทำก่อนเริ่มสร้าง Agent จริงคือกำหนดขอบเขตความรับผิดชอบให้ชัดเจน ออกแบบว่าจะเก็บสถานะอะไรบ้างอย่างมีขอบเขต และวางจุด Human-in-the-loop สำหรับงานที่มีผลกระทบสูงไว้ตั้งแต่ต้น ไม่ใช่ปล่อยให้ Agent ตัดสินใจทุกอย่างเองทันที

• Agent ต่างจาก Workers ตรงที่มีสถานะคงอยู่ข้าม Request ได้ผ่านการทำงานร่วมกับ Durable Objects
• เหมาะกับงานที่ต้องจำบริบทยาว ทำงานหลายขั้นตอนต่อเนื่อง หรือต้องตั้งเวลาทำงานในอนาคต
• ควรออกแบบให้เก็บสถานะเฉพาะข้อมูลจำเป็น และมีจุดให้มนุษย์ตรวจสอบงานที่มีผลกระทบสูง
• จุดพังที่พบบ่อยคือไม่กำหนดขอบเขตของ Agent ให้ชัดเจน และไม่ทดสอบสถานการณ์ที่มีหลายบทสนทนาพร้อมกัน

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