Agent ที่ยิ่งซับซ้อนยิ่งพังกลางทาง WorkflowAgent เข้ามาแก้ปัญหานี้อย่างไร

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

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

WorkflowAgent เป็นแนวคิดที่ Vercel AI SDK 7 เพิ่มเข้ามาเพื่อแก้ปัญหานี้โดยตรง บทความนี้จะอธิบายว่า WorkflowAgent ทำงานต่างจาก Agent Loop แบบเดิมอย่างไร ใช้กับ Durable Agent Workflow ตอนไหน และมีข้อจำกัดอะไรที่ต้องรู้ก่อนนำไปใช้กับงานจริง

ปัญหาของ Agent ที่ผูกทุกขั้นตอนไว้ใน Request เดียว

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

ทางแก้ที่ทีมส่วนใหญ่เคยใช้คือเขียนกลไก Retry เอง หรือแยกงานออกเป็นหลาย Endpoint แล้วให้ฝั่ง Client คอยเรียกเช็คสถานะเป็นระยะ ซึ่งใช้งานได้แต่ต้องเขียนโค้ดจัดการเองจำนวนมาก ทั้งเรื่องเก็บสถานะระหว่างทาง จัดการกรณี Retry ซ้ำ และป้องกันไม่ให้ขั้นตอนที่ทำสำเร็จแล้วถูกเรียกซ้ำโดยไม่ตั้งใจ

WorkflowAgent ต่างจาก Agent Loop แบบเดิมตรงไหน

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

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

แนวคิด Durable Execution ที่อยู่เบื้องหลัง

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

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

ใช้กับ Durable Agent Workflow แบบไหนบ้าง

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

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

ตัวอย่างสมมติ: Workflow ตรวจสอบเอกสารที่ต้องรอคนอนุมัติ

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

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

ตัวอย่างนี้แสดงให้เห็นว่าคุณค่าของ WorkflowAgent ไม่ได้อยู่ที่การทำให้ Agent ฉลาดขึ้น แต่อยู่ที่การไม่เสียงานที่ทำสำเร็จไปแล้วเมื่อต้องรอสิ่งที่ควบคุมเวลาไม่ได้ ซึ่งเป็นปัญหาที่เกิดขึ้นจริงกับ Workflow ที่มีจุดรอมนุษย์อยู่กลางทาง ไม่ใช่แค่ทฤษฎีบนกระดาษ

เทียบ Agent Loop ธรรมดา กับ WorkflowAgent

เพื่อให้เห็นความต่างชัดเจนขึ้น ตารางนี้เทียบลักษณะงานที่เหมาะกับแต่ละแบบ:

ออกแบบจุดบันทึกสถานะให้เหมาะกับงาน

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

เกี่ยวข้องกับ Tool Approval และ Observability อย่างไร

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

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

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

ทำแบบนี้แล้วพัง เพราะทีมมักพลาดจุดเหล่านี้

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

สรุป

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

การใช้งานควรพิจารณาจากลักษณะงานจริง ไม่ใช่ใช้กับทุกกรณีเพราะฟังดูล้ำสมัย งานสั้นที่จบเร็วยังใช้ Agent Loop ธรรมดาได้ดีอยู่ ส่วนงานที่มีจุดรอสิ่งภายนอกใช้เวลานานไม่แน่นอน คือกรณีที่ WorkflowAgent แสดงคุณค่าชัดเจนที่สุด

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

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