ถ้า AI สองตัวรับเรื่องคืนเงินของลูกค้ารายเดียวกันพร้อมกัน ใครจะรู้ว่าคำขอนี้อนุมัติไปแล้ว และใครมีสิทธิ์สั่งจ่ายจริง?
Cloudflare Durable Objects ช่วยเป็นจุดกลางที่เก็บสถานะและรับคำขอเปลี่ยนสถานะจากหลาย AI agents ได้ เมื่อนำมาใช้กับงานธุรกิจ เราสามารถเขียนกติกาให้ทุก agent ต้องผ่านการตรวจสิทธิ์และเงื่อนไขของเรื่องเดียวกันก่อนดำเนินการ ส่วนการอ่าน สรุป และเสนอสิ่งที่ควรทำยังเป็นหน้าที่ของ LLM
คำถามเรื่องคืนเงินทำให้ผมสนใจเทคโนโลยีนี้ในฐานะส่วนที่ประสานงานธุรกิจ หรือ business layer ของระบบ AI บทความนี้เป็นแนวทางออกแบบที่ผมเห็นว่าน่าลอง ยังไม่ได้เป็นการรายงานผลจากระบบที่นำไปใช้งานจริง
Durable Objects ช่วยประสานอะไรให้หลาย agent
Durable Object แต่ละตัวมีตัวระบุเฉพาะสำหรับส่งคำขอไปหา และมี durable storage ของตัวเอง ข้อมูลที่บันทึกไว้จึงใช้ทำงานต่อได้เมื่อ instance เริ่มใหม่ ส่วนข้อมูลที่เก็บในหน่วยความจำอย่างเดียวอาจหายไปเมื่อ object หยุดทำงาน
Storage ของแต่ละ object เป็นแบบ strongly consistent และรองรับ transaction ภายใน object นั้น แนวทางที่ผมมองไว้คือเลือกขอบเขตตามเรื่องธุรกิจ เช่น คำขอคืนเงินหนึ่งรายการ เพื่อให้ทุก agent อ้างอิงสถานะของเรื่องเดียวกัน ไม่จำเป็นต้องรวมงานทั้งองค์กรไว้ใน object เดียว
แหล่งอ้างอิง: Durable Objects: compute, storage และการประสานงาน
คำขอคืนเงินหนึ่งเรื่อง มีหลาย agent ช่วยกันได้
ลองนึกถึงคำขอคืนเงินหนึ่งรายการ มี agent สรุปเรื่องจากลูกค้า อีกตัวตรวจเงื่อนไข และอีกตัวเตรียมคำตอบ ทั้งสามอาจทำงานเสร็จคนละเวลา แต่ต้องอ้างอิงคำขอเดียวกันว่าอยู่ขั้นไหน ใครอนุมัติแล้ว และยังทำอะไรได้บ้าง
เมื่อ agent ต้องการเปลี่ยนสถานะ ก็ส่งคำขอมาที่ Durable Object ของเรื่องนี้ เช่น จาก “รอตรวจสอบ” เป็น “รออนุมัติ” โดยระบบตรวจสิทธิ์และเงื่อนไขก่อนรับการเปลี่ยนแปลง แล้วเก็บผลไว้ใน durable storage
การที่ agent เสนอให้คืนเงินไม่ได้ทำให้คำขอนั้นได้รับอนุมัติ การอนุมัติยังต้องผ่านกติกาที่เขียนไว้ และผ่านคนเมื่อเงื่อนไขกำหนด ภาพประกอบจึงแยกจุดอนุมัติออกจากระบบภายนอกที่ทำรายการจริง
ผมว่าเรื่องนี้มีประโยชน์กับธุรกิจ เพราะเราสามารถตอบได้ว่าข้อเสนอของ agent ถูกยอมรับเมื่อไร ด้วยเหตุผลอะไร และใครเป็นผู้อนุมัติ แต่บันทึกเหล่านี้ต้องออกแบบให้เก็บจริง ไม่ได้เกิดขึ้นครบเองเพียงเพราะใช้ Durable Objects
Single-thread และ transaction ยังมีขอบเขต
แม้แต่ละ object จะทำงานแบบ single-thread แต่ระหว่างรอเรียกบริการภายนอก งานอื่นอาจเข้ามาทำต่อได้ จึงยังต้องออกแบบการตรวจสถานะและการเปลี่ยนสถานะให้ถูกต้อง ไม่ควรถือว่าทุกคำขอแบบ async จะเรียงทำจนจบทีละคำขอ
โดยเฉพาะการสั่งจ่ายเงิน การบันทึกใน object กับการจ่ายผ่านระบบภายนอกไม่ได้อยู่ใน transaction เดียวกัน ถ้าส่งคำขอแล้วเครือข่ายขาด เราอาจยังไม่รู้ว่าจ่ายสำเร็จหรือไม่
ต้องมีรหัสคำขอที่ใช้ตรวจการส่งซ้ำ เช่น idempotency key ตามที่ผู้ให้บริการรองรับ และมีกระบวนการตรวจสอบยอดกับสถานะจริง การลองส่งใหม่โดยยังไม่รู้ผลของครั้งก่อนอาจทำให้เกิดรายการซ้ำได้ Durable Objects จึงไม่ได้รับประกันว่าการจ่ายเงินภายนอกจะเกิดขึ้นครั้งเดียวเอง
แหล่งอ้างอิง: Durable Objects: compute, storage และการประสานงาน · SQLite-backed Durable Object Storage
Agents SDK, Workflows และ Alarms ใช้กับงานคนละส่วน
Cloudflare Agents SDK ใช้ Durable Objects เป็นฐานสำหรับตัว agent อยู่แล้ว ช่วยให้ agent มีตัวตนและสถานะที่เก็บไว้ได้ แนวทางประสานคำขอธุรกิจในบทความนี้เป็นการเลือกขอบเขตและกติกาเพิ่มเติมให้เหมาะกับงาน
งานรออนุมัติหรือทำหลายขั้นตอนนาน ๆ อาจใช้ Workflows เพื่อเก็บความคืบหน้าและลองขั้นตอนที่ล้มเหลวใหม่ เช่น เมื่อได้รับผลอนุมัติแล้วจึงเดินขั้นตอนถัดไป การเก็บความคืบหน้าของ workflow ยังไม่ได้ทำให้ธุรกรรมกับระบบภายนอกอยู่ในขอบเขตเดียวกัน
ถ้าต้องปลุก object กลับมาตรวจคำขอที่ครบกำหนด ก็มี Alarms ให้ใช้ การเรียก alarm เป็นแบบ at-least-once คืออาจถูกเรียกซ้ำได้ งานที่ทำเมื่อถูกปลุกจึงต้องรองรับการเรียกซ้ำโดยไม่สร้างผลซ้ำ
แหล่งอ้างอิง: Cloudflare Agents SDK: Agent class internals · Using Agents with Workflows · Durable Objects Alarms
เริ่มจากเรื่องที่สถานะชัด และทำซ้ำแล้วมีผลกระทบ
ถ้าจะลองแนวทางนี้ ผมจะเริ่มจากหนึ่งงานที่อธิบายสถานะได้ชัด รู้ว่าใครมีสิทธิ์เปลี่ยนสถานะ และรู้ว่าตรงไหนต้องรอคนอนุมัติ เช่น คำขอลูกค้าหรือการอนุมัติใบสั่งซื้อ แล้วทดสอบทั้งกรณีที่คำขอเข้าพร้อมกัน ส่งซ้ำ และระบบภายนอกตอบกลับไม่ครบ
สิ่งที่ต้องตรวจให้ได้คือเมื่อเกิดปัญหา ทีมยังตามเรื่องต่อได้หรือไม่ รู้หรือไม่ว่าระบบรับการเปลี่ยนสถานะครั้งไหนไปแล้ว และสามารถตรวจผลกับระบบภายนอกได้อย่างไร ข้อมูลเหล่านี้ช่วยให้ตัดสินใจได้ว่าการทดลองพร้อมขยายไปใช้จริงหรือยัง
ถ้าเลือกได้หนึ่งเรื่องในองค์กรคุณ งานไหนมีหลายคนหรือหลาย agent เกี่ยวข้อง และมักสับสนว่า “ตอนนี้ใครทำอะไรไปแล้ว”?
คำถามเกี่ยวกับ Durable Objects ในงานธุรกิจ
Durable Objects ทำหน้าที่คิดแทน LLM หรือไม่?
ในแนวทางนี้ Durable Objects เป็นจุดเก็บสถานะและตรวจคำขอเปลี่ยนสถานะตามกติกาที่เขียนไว้ ส่วน LLM อ่าน สรุป และเสนอการดำเนินการ ข้อเสนอที่ได้ยังต้องผ่านเงื่อนไขและสิทธิ์อนุมัติของระบบธุรกิจ
ใช้ Durable Objects แล้วป้องกันการคืนเงินซ้ำได้ทันทีหรือไม่?
ไม่ได้โดยอัตโนมัติ Transaction ภายใน object ไม่ครอบคลุมระบบจ่ายเงินภายนอก ต้องออกแบบการตรวจสถานะ รองรับคำขอซ้ำด้วย idempotency key ตามที่ผู้ให้บริการรองรับ และตรวจสอบผลเมื่อไม่แน่ใจว่าการจ่ายสำเร็จหรือไม่
