AI ตอบเร็วได้ แต่หัวหน้าที่ต้องอนุมัติงานอาจติดประชุมอยู่ ถ้าเราให้ Agent รอคำตอบโดยเก็บทุกอย่างไว้ในโปรแกรมที่กำลังรัน พอโปรแกรมหยุด งานที่รอคนก็อาจหายไปด้วย ปัญหานี้ไม่ได้แก้ด้วยการเปลี่ยนโมเดลให้ฉลาดขึ้นอย่างเดียว เราต้องออกแบบให้ระบบจำได้ว่ารอใคร รอเรื่องอะไร และจะเดินต่อจากตรงไหน
Melanie Warrick จากทีม Developer Relations ของ Temporal อธิบายเรื่องนี้ในวิดีโอ The Human Is an Async API บนช่อง AI Engineer ซึ่งเผยแพร่เมื่อ 4 ตุลาคม 2026 บทเรียนเหมาะกับคนที่กำลังสร้าง Agent ให้รับงานจริง โดยเฉพาะงานที่ต้องขออนุมัติหรือมีคนเปลี่ยนคำสั่งระหว่างทาง
พักออเดอร์เดียว โดยให้งานอื่นเดินต่อ
เดโมใช้บริการส่งไอศกรีมสมมติ มี Agent ดูแลลูกค้า รถและคนขับ และการจัดส่ง ในช่วง 2:03 ลูกค้าขอเปลี่ยนออเดอร์ ระบบจึงพักรายการที่เกี่ยวข้องไว้ให้คนพิจารณา ส่วนออเดอร์อื่นยังเดินต่อ เมื่อมีคำตอบ รายการที่พักไว้จึงกลับเข้าสู่กระบวนการ
สิ่งที่นำมาใช้กับงานของเราได้คือการแยกสถานะของแต่ละงาน ตัวอย่างเช่น คำขอเปลี่ยนที่อยู่จัดส่งควรมีหมายเลขงานของตัวเอง พร้อมข้อมูลเดิม ข้อมูลที่ขอเปลี่ยน และผู้ตัดสินใจ ทีมจึงรู้ว่ารายการใดต้องพัก โดยไม่ต้องหยุดคิวทั้งหมด ตัวอย่างการนำไปใช้นี้เป็นข้อเสนอทางบรรณาธิการ ไม่ใช่ระบบร้านค้าสำเร็จรูปที่ผู้บรรยายนำมาแจก
แยกสถานะงานออกจากโปรแกรมที่ประมวลผล
ช่วง 6:27 Warrick แยกหน้าที่ของ Temporal เป็น Worker ที่รันโค้ด, Workflow ที่กำหนดลำดับและสถานะของงาน และ Activity สำหรับงานอย่างการเรียกโมเดลหรือเครื่องมือภายนอก ความแตกต่างนี้ช่วยให้เราถามทีมพัฒนาได้ตรงจุดว่า ถ้า Worker หยุด สถานะของงานยังอยู่ที่ไหน
เอกสาร Temporal กับ LangGraph ระบุว่าโหนดที่เรียกเครือข่ายหรือมีผลลัพธ์ไม่แน่นอนควรทำงานเป็น Activity ส่วนโค้ดที่รันใน Workflow ต้องให้ผลสอดคล้องกันเมื่อ replay จึงต้องแยกการเรียกโมเดลออกจากตรรกะที่ใช้กู้สถานะ การบันทึกสถานะช่วยให้งานเดินต่อได้ แต่ไม่ได้รับรองว่าคำตอบของโมเดลจะถูกต้อง
ให้คำตอบจากคนกลับเข้าสู่งานเดิม
แกนของเรื่องอยู่ในช่วง 8:02: ใช้เงื่อนไขรอคู่กับ Signal แทนการสมมติว่าคนจะตอบทันที Workflow พักจนกว่าเงื่อนไขจะครบ ส่วนคำตอบจากคนถูกส่งกลับเข้าสู่ Workflow ที่กำลังรออยู่
เอกสาร Python SDK อธิบายว่า Signal เป็นข้อความแบบ asynchronous ที่ใช้เปลี่ยนสถานะหรือควบคุมงาน ส่วน workflow.wait_condition รอจนเงื่อนไขเป็นจริง และกำหนด timeout ได้ จุดที่ต้องจำคือการรับ Signal ที่ฝั่งเซิร์ฟเวอร์ยังไม่เท่ากับประมวลผลเสร็จแล้ว หน้าจออนุมัติจึงควรแสดงสถานะให้ตรงกับขั้นตอนจริง
ก่อนเขียนโค้ด ลองตกลงสี่เรื่องให้ครบ: ใครเป็นผู้อนุมัติ คำตอบผูกกับหมายเลขงานใด รอได้นานเท่าไร และหมดเวลาแล้วจะส่งต่อหรือยุติงานอย่างไร กลไกการรอไม่ได้เลือกนโยบายเหล่านี้ให้เรา
ทดสอบตอน Worker หยุด ไม่ใช่เฉพาะตอนเดโมราบรื่น
ช่วง 13:42 เป็นเดโมออเดอร์มูลค่าสูงที่ต้องรอคน จากนั้น Warrick หยุด Worker ระหว่างรอที่ 15:07 และแสดงการกู้คืนเมื่อ Worker กลับมาในช่วง 16:02 งานเดิมจึงดำเนินต่อจากสถานะที่บันทึกไว้
เดโมนี้แสดงกรณี Worker หยุด โดยบริการที่เก็บประวัติยังทำงานอยู่ จึงไม่ควรขยายความเป็นคำรับรองว่าระบบทุกส่วนจะล่มพร้อมกันได้โดยไม่มีผลกระทบ หรือไม่มีโอกาสเกิดผลข้างเคียงซ้ำจาก API ภายนอก เงื่อนไขเหล่านั้นต้องทดสอบกับระบบที่เราสร้างจริง
สำหรับงานทดลองหนึ่งประเภท ให้ทดสอบสามจังหวะ: หยุด Worker ตอนรอ ส่งคำตอบตอน Worker ยังไม่กลับมา แล้วเริ่ม Worker ใหม่ ตรวจว่างานเดิมรับคำตอบได้และเดินต่อโดยไม่ต้องสร้างคำขอใหม่ พร้อมตรวจว่าผลข้างเคียงสำคัญ เช่น การส่งคำสั่งจัดส่ง ไม่เกิดซ้ำโดยไม่ตั้งใจ นี่เป็นเกณฑ์ตรวจรับที่เสนอให้ทีมใช้ ไม่ใช่ผลทดสอบเพิ่มเติมจากคลิป
ขอคนอนุมัติเฉพาะเรื่องที่การตัดสินใจมีน้ำหนัก
ช่วง 16:47 Warrick ชวนคิดถึงต้นทุนของการตัดสินใจผิดควบคู่กับความล้าจากการแจ้งเตือน หากทุกเรื่องต้องให้คนกดผ่าน การอนุมัติอาจกลายเป็นงานที่ทำโดยไม่อ่าน แต่ถ้าปล่อยรายการที่ผิดแล้วเสียหายมากให้ Agent ทำเอง ก็เพิ่มความเสี่ยงอีกด้าน
เริ่มจาก workflow เล็กหนึ่งเรื่องที่มีจุดรอคนอยู่แล้ว เขียนสถานะ ผู้รับผิดชอบ และผลลัพธ์เมื่อหมดเวลาให้ชัด จากนั้นทดสอบการหยุดและกู้คืนก่อนขยายงาน คำถามตรวจรับที่ใช้ได้คือ “ถ้าคนตอบพรุ่งนี้ แต่ Worker หยุดวันนี้ งานเดิมจะกลับมาเดินต่ออย่างไร” คำตอบควรชี้ให้เห็นทั้งประวัติงานและสิ่งที่เกิดขึ้นจริงหลังเริ่มระบบใหม่
ที่มา: Melanie Warrick, Temporal บนช่อง AI Engineer วิดีโอเผยแพร่ 4 ตุลาคม 2026; คำอธิบายวิดีโอระบุว่าบันทึกที่ AI Engineer World's Fair 2026 ในซานฟรานซิสโก แต่ไม่ระบุวันที่บรรยายที่แน่นอน ตัวอย่างประยุกต์และเกณฑ์ตรวจรับในบทความเป็นข้อเสนอของผู้เรียบเรียง
