Agent ส่งคำขอสร้างใบงาน ระบบปลายทางสร้างสำเร็จแล้ว แต่คำตอบหายระหว่างทางก่อนที่ Agent จะบันทึกผล เมื่อเริ่มงานใหม่ ผู้ช่วยเห็นว่าขั้นนี้ยังไม่เสร็จจึงสร้างใบงานอีกครั้ง แต่ละระบบดูเหมือนทำงานสมเหตุสมผลในมุมของตัวเอง ทว่าธุรกิจกลับได้รายการซ้ำ
การทำงานต่ออย่างเชื่อถือได้ต้องมากกว่าบันทึกบทสนทนา ต้องมีสถานะงานที่อยู่รอดเมื่อระบบหยุด รหัสที่แทนคำสั่งธุรกิจเดิม และวิธีคลี่คลายกรณีไม่รู้ผล สิ่งสำคัญคือระบบภายนอกยืนยันอะไรแล้ว ไม่ใช่เพียงประโยคสุดท้ายที่ Agent เขียน
แยกตัวงานออกจากความพยายามทำงานแต่ละรอบ
กำหนดรหัสงานธุรกิจให้คงเดิมแม้ตัวทำงานเริ่มใหม่ หนึ่งงานอาจมีหลายคำสั่ง และหนึ่งคำสั่งอาจลองหลายครั้ง ต้องแยกรหัสเหล่านี้ออกจากกัน การเริ่มลองอีกครั้งไม่ควรกลายเป็นการประกาศว่ามีคำขอธุรกิจใหม่
ในตัวอย่างสมมติของงานบริการ ขั้นตอนอาจเป็นเตรียมใบงาน รออนุมัติ สร้างใบงานในระบบหลังบ้าน และแจ้งผู้ขอ เก็บรุ่นข้อมูลเข้า รายละเอียดที่อนุมัติ รหัสคำสั่ง รหัสรายการปลายทาง และสถานะของแต่ละขั้น พร้อมจุดอ้างอิงหลักฐาน แทนการฝากไว้ในสรุปบทสนทนาอย่างเดียว
ตั้งสถานะให้ตรงกับสิ่งที่รู้จริง เช่น รอทำ รออนุมัติ กำลังทำ ยืนยันผลแล้ว ยังไม่ทราบผล ล้มเหลว และยกเลิก แต่ละสถานะมีวิธีกู้ต่างกัน หากระบบใบงานหมดเวลารอ การเขียนว่าล้มเหลวอาจทำให้เข้าใจผิด เพราะรายการอาจถูกสร้างแล้ว
หน้าจอต้องสื่อความต่างนี้ด้วย บอกเจ้าหน้าที่ว่าคำขอส่งออกไปแล้วและกำลังตรวจผล แทนการชวนให้กดลองใหม่ทันที มิฉะนั้นคนอาจสร้างรายการซ้ำแบบเดียวกับที่ระบบพยายามป้องกัน
เข้าใจว่า Checkpoint ยืนยันอะไรได้บ้าง
Checkpoint เก็บสถานะ Workflow เพื่อกลับมาทำต่อ LangGraph อธิบายการเก็บสถานะ ประวัติ และการทำงานต่อบนฐาน Checkpoint แต่ฐานข้อมูลที่ใช้และระดับความทนทานของการเขียนยังต้องเหมาะกับแอป เอกสาร Persistence ของ LangGraph
Temporal ใช้ประวัติเหตุการณ์ที่บันทึกไว้กับการ Replay เพื่อให้งานดำเนินต่อ และมีข้อกำหนดเรื่องความสม่ำเสมอของโค้ดเมื่อ Replay วิธีนี้เป็นฐานสำหรับประสานงานยาวได้ แต่ไม่ได้ทำให้บริการภายนอกที่แยกกันกลายเป็นธุรกรรมเดียวที่สำเร็จหรือล้มพร้อมกันทั้งหมด การทำงานของ Workflow ใน Temporal
ช่องว่างสำคัญเกิดเมื่อคำสั่งภายนอกสำเร็จก่อนบันทึกผลอย่างถาวร Checkpoint ที่บอกว่ากำลังจะสร้างใบงานไม่สามารถบอกได้ว่าปลายทางสร้างไปแล้วหรือยัง แอปต้องอาศัยข้อตกลงของคำสั่ง รหัสอ้างอิงภายนอก หรือขั้นตรวจเทียบผลเพื่อหาคำตอบ
Temporal แนะนำให้ Activity ทำซ้ำได้โดยไม่เพิ่มผลทางธุรกิจ เพราะระบบอาจลองใหม่เมื่อไม่ได้รับรายงานจบ แม้ผลภายนอกเกิดขึ้นแล้ว เหตุผลเดียวกันนี้ควรนำไปพิจารณาไม่ว่าจะใช้ฐาน Workflow ใด Idempotency ของ Temporal Activity
ให้การลองใหม่อ้างถึงคำสั่งเดิม
Idempotency key ใช้บอกบริการที่รองรับว่าเป็นความพยายามทำคำสั่งเดียวกัน เมื่อกลับมาลองคำสั่งที่ได้รับอนุญาตเดิม ให้ใช้ Key ที่เหมาะสมเดิมและเก็บความสัมพันธ์กับข้อมูลคำสั่งไว้ หากสร้าง Key ใหม่ทุกครั้ง ก็ไม่ช่วยระบุว่าเป็นการลองซ้ำ
อย่าสมมติว่า API ทุกแห่งรับประกันเหมือนกัน ต้องตรวจว่าคำสั่งใดรองรับ เก็บประวัติไว้นานเท่าไร เมื่อพารามิเตอร์เปลี่ยนจะเกิดอะไร และส่งผลล้มเหลวเดิมกลับมาอย่างไร ตัวอย่างเช่น เอกสาร Stripe แยกพฤติกรรม API v1 กับ v2 และอธิบายอายุข้อมูลกับการเทียบพารามิเตอร์ของ v1 นี่เป็นข้อตกลงเฉพาะของบริการ ไม่ใช่กฎร่วมของทุกระบบ Idempotent requests ของ Stripe
หาก API ไม่รองรับ ให้ดูว่ารับรหัสอ้างอิงธุรกิจที่ไม่ซ้ำและค้นหาหรือบังคับความไม่ซ้ำได้หรือไม่ ถ้าไม่มี การตั้งธงในระบบเราเพียงว่าส่งแล้วไม่สามารถปิดช่องว่างระหว่างคำสั่งปลายทางกับการบันทึกในเครื่องเราได้ ต้องมีขั้นตรวจเทียบหรือพักรายการที่ไม่ทราบผลให้คนตรวจ ไม่ควรรับประกันว่าทำครั้งเดียวแน่นอน
หากหลาย Worker ทำงานพร้อมกัน ต้องมีการประสานสถานะแบบคงทนเพื่อไม่ให้สองรอบถือสิทธิ์ทำคำสั่งเดียวกันอิสระ ควบคู่กับการป้องกันซ้ำหรือข้อบังคับรายการไม่ซ้ำที่ปลายทางเมื่อทำได้ การล็อกอย่างเดียวอาจหมดอายุทั้งที่คำขอปลายทางยังทำงานอยู่
แยกสาเหตุก่อนตัดสินใจทำซ้ำ
| สิ่งที่พบ | ขั้นต่อไปที่เหมาะ | สิ่งที่ควรหลีกเลี่ยง |
|---|---|---|
| ช่องบังคับไม่ผ่านการตรวจ | แก้ข้อมูลและขออนุมัติใหม่หากสาระเปลี่ยน | ส่งข้อมูลผิดเดิมซ้ำไม่สิ้นสุด |
| ปลายทางปฏิเสธสิทธิ์ชัดเจน | แก้สิทธิ์ตามกระบวนการหรือหยุดงาน | สลับไปใช้บัญชีสิทธิ์สูงกว่าเอง |
| ถูกจำกัดอัตราเรียกชั่วคราว | ลองใหม่ตามขอบเขตและเวลาที่กำหนด | ยิงซ้ำทันทีจนเพิ่มภาระปลายทาง |
| คำตอบหายหลังส่งคำขอ | ค้นด้วยรหัสคำสั่งหรือรหัสธุรกิจ | สร้างคำสั่งธุรกิจใหม่โดยไม่ตรวจ |
| ลูกค้าแก้คำขอที่อนุมัติแล้ว | เตรียมและตรวจข้อมูลรุ่นใหม่ | ใช้การอนุมัติของข้อมูลรุ่นก่อน |
| พบรายการที่ยืนยันผลแล้ว | ทำต่อจากผลที่บันทึกไว้ | สั่งภายนอกซ้ำเพื่อสร้างบริบทกลับมา |
กำหนดจำนวนครั้งและเวลาสิ้นสุดของการลองอัตโนมัติ โดยเพิ่มช่วงรอเมื่อเหมาะสม นโยบายต้องสอดคล้องกับคำตอบผู้ให้บริการและความเร่งด่วน งานที่ลองไปเรื่อย ๆ อาจกินกำลังระบบ ขณะที่พนักงานเข้าใจว่ามีคนอื่นจัดการให้แล้ว
การยกเลิกต้องมีความหมายชัดด้วย การหยุดงานในระบบเราไม่ได้ยกเลิกคำสั่งที่ปลายทางรับไปแล้วเสมอ ต้องแสดงว่าส่วนใดหยุดแล้ว ส่วนใดยังไม่ทราบผล และย้อนกลับได้ด้วยวิธีใด บางงานต้องทำรายการชดเชยทางธุรกิจแทนการย้อนข้อมูลทางเทคนิค
ให้คนมีทางกู้งานที่ไม่สร้างปัญหาซ้ำ
หน้าจอกู้งานควรมีคำขอเดิม รุ่นปัจจุบัน ขั้นที่จบแล้ว รหัสปลายทาง และข้อผิดพลาดล่าสุดที่มีความหมาย ให้ผู้มีสิทธิ์ตรวจเทียบผล แก้คำขอ หรือยกเลิกงานที่เหลือได้ หลีกเลี่ยงปุ่มเริ่มทุกอย่างใหม่เมื่อมีเพียงขั้นเดียวที่ต้องตรวจ
เก็บประวัติการกระทำแบบเพิ่มรายการหรือวิธีที่ตรวจย้อนหลังได้ตามกฎข้อมูลของผลิตภัณฑ์ ระบุว่าใครตัดสินใจด้วยมือและใช้หลักฐานใด แยกการยืนยันว่าใบงานเดิมมีอยู่แล้วออกจากการสร้างใบงานใหม่ให้ชัด
ทดสอบช่วงที่อาจหยุดในสภาพแวดล้อมที่ไม่ใช่งานจริง จงใจหยุด Worker ก่อนส่ง หลังปลายทางรับ และก่อนบันทึกผล ส่งเหตุการณ์เดิมสองครั้ง ให้ Worker สองตัวแย่งงาน และกลับมาทำต่อหลังการอนุมัติล้าสมัย กรณีเหล่านี้พบข้อผิดพลาดที่การสาธิตงานสำเร็จตลอดทางไม่เห็น
ตรวจสถานะธุรกิจหลังจบด้วยวิธีอิสระ ดูใบงานซ้ำ การแจ้งที่ขาด การแก้ข้อมูลผิด และงานที่ค้างโดยไม่มีคนรับผิดชอบ จากนั้นดูว่าหน้าจอให้ข้อมูลเจ้าหน้าที่พอจะกู้ได้หรือไม่ ความเชื่อถือได้รวมถึงคนที่ดูแลงาน ไม่ใช่เฉพาะตัว Worker
หากกำลังเลือกฐานระบบ อ่านต่อเรื่อง n8n, LangGraph และโค้ดเฉพาะ และนำกรณีกู้เหล่านี้เข้า Evals ที่ตรวจผลทางธุรกิจ เพื่อใช้เป็นส่วนหนึ่งของเกณฑ์เปิดใช้งาน
Talvyn Labs ช่วยพัฒนา Agent ที่มีสถานะงานคงทน การอนุมัติชัดเจน วิธีลองใหม่ตามข้อตกลงปลายทาง และหน้าจอให้ทีมดูแล นำ Workflow ที่ค้างหรือทำรายการซ้ำมาเริ่มวิเคราะห์ช่วงที่อาจผิดพลาด แล้วเชื่อมระบบให้บอกได้ว่าเกิดอะไรขึ้นและทำต่อจากผลที่ยืนยันแล้ว
แก้ Workflow ที่ค้างและทำรายการซ้ำให้พร้อมใช้งานจริง
ให้ Talvyn Labs ออกแบบสถานะงาน การอนุมัติ การตรวจเทียบผล และวิธีกู้ พร้อมพัฒนา Agent กับหน้าจอที่ทีมรู้ว่าจะทำอะไรต่อ
พัฒนา Agent ที่ทำงานต่อได้