แนวทางปฏิบัติที่ดีที่สุดสำหรับการประสานงานเอเจนต์ AI: การจัดการความล้มเหลว การอนุมัติ และการลองใหม่

คู่มือนี้อธิบายวิธีการทำงานของการประสานงานเอเจนต์ AI เปรียบเทียบสถาปัตยกรรมแบบรวมศูนย์ แบบกระจายศูนย์ และแบบลำดับชั้น พร้อมทั้งครอบคลุมแนวทางปฏิบัติที่ดีที่สุด 7 ข้อสำหรับการจัดการความล้มเหลว การอนุมัติ และการลองใหม่ในการใช้งานจริง

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

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

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

ออร์เคสเตรชันเอเจนต์ AI คืออะไร

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

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

ออร์เคสเตรชันเอเจนต์ AI ทำงานอย่างไร: เจาะลึกภายในเอนจินการดำเนินการ

มาดูกันว่าจะเกิดอะไรขึ้นหลังจากคุณมอบหมายงานให้ออร์เคสเตรเตอร์

ลองพิจารณาตัวอย่างจากเวิร์กช็อป Computer ของ Perplexity: การสร้างแดชบอร์ดข้อมูลเชิงลึกของบัญชีลูกค้าโดยใช้ข้อมูลจาก Salesforce, Snowflake, อีเมล, ปฏิทิน และข่าวล่าสุด

  1. ทำความเข้าใจเป้าหมายและวางแผนงาน ออร์เคสเตรเตอร์เริ่มต้นจากผลลัพธ์ที่ต้องการ แล้วแยกย่อยออกเป็นงานต่างๆ พร้อมการพึ่งพากันที่ชัดเจน ในตัวอย่างแดชบอร์ดของเรา ขั้นตอนนี้คือการรวบรวมข้อมูลจากแหล่งต่างๆ และเปลี่ยนให้เป็นผลงานที่เสร็จสมบูรณ์ ตัววางแผนจะกำหนดว่าขั้นตอนใดต้องพึ่งพาขั้นตอนอื่น และขั้นตอนใดทำงานได้อย่างอิสระ
  2. ส่งต่องานไปยังเอเจนต์ที่เหมาะสม ออร์เคสเตรเตอร์จะระบุงานที่มีเงื่อนไขการพึ่งพาครบถ้วนแล้ว และมอบหมายงานให้เอเจนต์หรือโมเดลเฉพาะทาง งานที่ต้องพึ่งพางานอื่นจะรอจนกว่างานที่เป็นเงื่อนไขเบื้องต้นจะเสร็จ Perplexity Computer ใช้โมเดลระดับแนวหน้าหลายตัว โดยส่งต่อส่วนต่างๆ ของเวิร์กโฟลว์ไปยังระบบที่เหมาะกับงานเหล่านั้น ซึ่งยังช่วยให้งานที่เป็นอิสระต่อกันทำงานแบบคู่ขนานได้ด้วย
  3. เรียกใช้เครื่องมือภายในสภาพแวดล้อมที่มีการควบคุม เอเจนต์โต้ตอบกับสภาพแวดล้อมผ่านเครื่องมือ เช่น การค้นหาเว็บ, API, แอปพลิเคชันที่เชื่อมต่อ, การดำเนินการกับไฟล์ หรือการรันโค้ด เลเยอร์การดำเนินการจะรันการดำเนินการเหล่านี้และส่งผลลัพธ์กลับไปยังเอเจนต์
  4. ส่งผลลัพธ์และบริบทระหว่างเอเจนต์ เมื่อเอเจนต์ทำงานเสร็จ เอเจนต์ถัดไปในลำดับต้องได้รับผลลัพธ์ที่เกี่ยวข้องเพื่อทำงานต่อ บันทึกการส่งต่องานอาจประกอบด้วย ID งาน การอ้างอิงผลลัพธ์ เวอร์ชันสคีมา และเมทาดาทาของแหล่งที่มา ออร์เคสเตรเตอร์จะประสานการส่งต่องานเหล่านี้ พร้อมรักษาบริบทที่จำเป็นสำหรับขั้นตอนถัดไป ที่สำคัญคือ เอเจนต์ไม่จำเป็นต้องเก็บประวัติทั้งหมดของงานที่เอเจนต์อื่นทำไว้ในหน้าต่างบริบทของตนเอง
  5. บันทึกสถานะการดำเนินการแยกจากบริบทของเอเจนต์ เมื่อเอเจนต์เริ่มงาน ทำงานเสร็จ หรือทำงานล้มเหลว เอนจินการดำเนินการจะอัปเดตบันทึกเวิร์กโฟลว์แบบถาวรด้วยสถานะของงาน ความพยายามในการดำเนินการ การอ้างอิงผลลัพธ์ และงานที่เหลืออยู่ บันทึกนี้ช่วยให้ออร์เคสเตรเตอร์ติดตามความคืบหน้าและทำงานต่อหลังการหยุดชะงักได้ โดยไม่ต้องพึ่ง LLM ในการสร้างเวิร์กโฟลว์ขึ้นใหม่จากประวัติการสนทนา
  6. ตรวจสอบผลลัพธ์และตัดสินใจขั้นตอนถัดไป เมื่องานส่งผลลัพธ์กลับมา เลเยอร์ออร์เคสเตรชันจะตรวจสอบว่าผลลัพธ์เป็นไปตามข้อกำหนดที่คาดไว้หรือไม่ และเงื่อนไขการพึ่งพาของงานถัดไปครบถ้วนหรือไม่ หากพบปัญหา เวิร์กโฟลว์อาจย้อนกลับไปยังขั้นตอนก่อนหน้าเพื่อแก้ไข หรือถูกหยุดชั่วคราว มิฉะนั้นก็จะดำเนินต่อไปจนเสร็จสมบูรณ์

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

ควรใช้ออร์เคสเตรชันเอเจนต์ AI เมื่อใด

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

ดังนั้น ออร์เคสเตรชันจึงมีประโยชน์ในสามสถานการณ์:

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

นอกเหนือจากนี้ ออร์เคสเตรชันก็เป็นเพียงกระแสที่มีต้นทุนสูง เอเจนต์ที่มากขึ้นยังหมายถึงการประสานงานที่มากขึ้นและอาจมีต้นทุนโทเค็นที่สูงขึ้นด้วย

“ผมมักเริ่มจากตัวเลือกที่ง่ายที่สุดแล้วค่อยต่อยอดจากตรงนั้น ถ้าเรารู้ขั้นตอนและขั้นตอนเหล่านั้นทำซ้ำได้ นั่นน่าจะเป็นเวิร์กโฟลว์ ผมจะเห็นเหตุผลที่ต้องใช้เอเจนต์หลายตัวก็ต่อเมื่อเอเจนต์เหล่านั้นมีความรับผิดชอบ สิทธิ์ หรือผู้ใช้ที่แตกต่างกันเท่านั้น” Josh Spilker หัวหน้าฝ่ายการตลาดบนเครื่องมือค้นหาของ AirOps กล่าว

ถึงอย่างนั้น ก็ควรชั่งน้ำหนักประโยชน์เทียบกับการเรียกโมเดลเพิ่มเติม การส่งต่องาน ความหน่วง และจุดที่อาจเกิดความล้มเหลว

สถาปัตยกรรมออร์เคสเตรชันเอเจนต์ AI และข้อดีข้อเสีย

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

ออร์เคสเตรชันแบบรวมศูนย์

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

ข้อดีข้อเสีย: การประสานงานแบบรวมศูนย์ช่วยให้ติดตามการดำเนินการและใช้กฎร่วมกัน ณ จุดควบคุมเดียวได้ง่ายขึ้น อย่างไรก็ตาม ออร์เคสเตรเตอร์อาจกลายเป็นคอขวด และความล้มเหลวของออร์เคสเตรเตอร์อาจทำให้เวิร์กโฟลว์ทั้งหมดหยุดชะงัก เว้นแต่ระบบจะรองรับการกู้คืน

ออร์เคสเตรชันแบบกระจายศูนย์

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

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

ออร์เคสเตรชันแบบลำดับชั้น

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

ลองนึกถึงเวิร์กโฟลว์ระดับองค์กรที่เกี่ยวข้องกับทีมขาย การเงิน และกฎหมาย ออร์เคสเตรเตอร์ระดับบนสุดอาจมอบหมายแต่ละสายงานให้ผู้ประสานงานเฉพาะด้าน จากนั้นผู้ประสานงานเหล่านั้นจะจัดการเอเจนต์ผู้เชี่ยวชาญของตนเองและรายงานผลลัพธ์ที่รวบรวมแล้ว

โครงสร้างนี้มีประโยชน์เมื่อเวิร์กโฟลว์มีขอบเขตกว้างเกินกว่าที่ออร์เคสเตรเตอร์ตัวเดียวจะจัดการได้อย่างมีประสิทธิภาพ

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

การเปรียบเทียบสถาปัตยกรรมเหล่านี้:

เกณฑ์

แบบรวมศูนย์

แบบกระจายศูนย์

แบบลำดับชั้น

ผู้รับผิดชอบการดำเนินการ

ออร์เคสเตรเตอร์ตัวเดียวควบคุมการมอบหมายงาน

เอเจนต์ประสานงานผ่านเอเจนต์ด้วยกันหรือสถานะที่ใช้ร่วมกัน

ความรับผิดชอบกระจายไปตามระดับต่างๆ ของออร์เคสเตรชัน

ความสอดคล้องของสถานะ

ประสานงานได้ง่ายกว่าผ่านจุดควบคุมเดียว

ต้องมีการซิงโครไนซ์และการจัดการข้อขัดแย้งอย่างชัดเจน

ต้องมีการประสานงานทั้งภายในและระหว่างสาขา

การแยกความล้มเหลว

ตัวควบคุมส่วนกลางอาจกลายเป็นจุดพึ่งพาที่สำคัญยิ่ง

เอเจนต์แต่ละตัวอาจล้มเหลวได้อย่างอิสระ แต่โครงสร้างพื้นฐานที่ใช้ร่วมกันยังคงมีความสำคัญยิ่ง

ความล้มเหลวอาจถูกจำกัดไว้ภายในสาขาได้ หากออกแบบมาให้รองรับการกู้คืน

การบังคับใช้นโยบาย

สามารถบังคับใช้การควบคุมทั่วไปได้จากส่วนกลาง

ต้องบังคับใช้นโยบายอย่างสม่ำเสมอกับผู้เข้าร่วมทุกราย

สามารถใช้การควบคุมได้ทั้งในระดับทั่วทั้งระบบและระดับโดเมน

ความซับซ้อนในการดำเนินงาน

โดยทั่วไปต่ำกว่า

การประสานงานมีความซับซ้อนสูงกว่า

ซับซ้อนกว่าเนื่องจากมีชั้นออร์เคสเตรชันหลายชั้น

การดำเนินการแบบลำดับขั้น แบบขนาน และแบบส่งต่องาน

ยังมีอีกความแตกต่างหนึ่งที่ควรทำความเข้าใจ สถาปัตยกรรมเป็นตัวกำหนดว่าใครเป็นผู้ประสานงานเอเจนต์ ส่วนรูปแบบการดำเนินการเป็นตัวกำหนดว่างานของเอเจนต์จะดำเนินไปอย่างไร

รูปแบบการดำเนินการสามรูปแบบมีดังนี้:

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

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

ความล้มเหลวที่พบบ่อยในการออร์เคสเตรชันเอเจนต์ AI

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

  • การส่งต่องานระหว่างเอเจนต์ที่ข้อมูลตกหล่น ออร์เคสเตรเตอร์ส่งแผนฉบับสรุปให้เอเจนต์เฉพาะทาง แต่บทสรุปนั้นกลับตกหล่นข้อจำกัด การพึ่งพา หรือรายละเอียดการนำไปใช้
  • การรวมผลลัพธ์ (fan-in) ก่อนเวลาอันควร เอเจนต์ในขั้นถัดไปเริ่มรวบรวมผลลัพธ์ก่อนที่งานในขั้นก่อนหน้าทั้งหมดจะเสร็จสิ้น
  • การอัปเดตสถานะที่ใช้ร่วมกันแบบไม่กำหนดแน่นอน (non-deterministic) เอเจนต์ที่ทำงานแบบขนานเขียนข้อมูลลงในคีย์สถานะเดียวกันโดยไม่มีหลักการผสานข้อมูล (merge semantics) ที่กำหนดไว้อย่างชัดเจน ขึ้นอยู่กับว่าเฟรมเวิร์กจัดการการอัปเดตอย่างไร ปัญหานี้อาจส่งผลให้ข้อมูลที่เขียนสูญหาย ข้อมูลซ้ำซ้อน เอาต์พุตที่ขึ้นอยู่กับลำดับ หรือการเปลี่ยนแปลงที่ขัดแย้งกัน
  • ความไม่สอดคล้องระหว่างเช็กพอยต์กับผลข้างเคียง งานหนึ่งดำเนินการภายนอก แต่การดำเนินการที่สำเร็จนั้นไม่ได้ถูกบันทึกไว้อย่างถาวรก่อนที่เวิร์กเกอร์จะล้มเหลว เมื่อกู้คืนระบบ ออร์เคสเตรเตอร์จะเห็นว่างานยังไม่เสร็จและเรียกใช้งานนั้นซ้ำ
  • สภาวะแข่งขัน (race) เมื่อดำเนินการต่อหลังการอนุมัติจากมนุษย์ การหยุดชั่วคราวและการดำเนินการต่อทำให้เกิดปัญหาด้านการซิงโครไนซ์ในตัวเอง
  • ลูปการมอบหมายงานและการลองใหม่ที่ทวีคูณ เอเจนต์ส่งงานให้กันไปมาซ้ำ ๆ เนื่องจากหน้าที่รับผิดชอบทับซ้อนกัน การพึ่งพาเป็นวงจร หรือเงื่อนไขการเสร็จสิ้นไม่ชัดเจน
  • การเข้าใจผิดว่าการควบคุมระดับคำสั่งคือความปลอดภัยในการดำเนินการ ออร์เคสเตรเตอร์อาจสั่งเอเจนต์ไม่ให้เข้าถึงทรัพยากรบางอย่างหรือดำเนินการที่ละเอียดอ่อน แต่คำสั่งของโมเดลไม่ได้บังคับใช้สิทธิ์ของระบบปฏิบัติการ ข้อจำกัดด้านเครือข่าย หรือขอบเขตการอนุญาต การวิจัยด้านวิศวกรรมความปลอดภัยของ Perplexity ชี้ให้เห็นว่าเหตุใดเอเจนต์จึงอาจข้ามขอบเขตความปลอดภัยได้ในขณะที่พยายามบรรลุเป้าหมายที่ชอบธรรม แม้จะไม่มีคำสั่งที่เป็นอันตรายก็ตาม

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

แนวทางปฏิบัติที่ดีที่สุด 7 ประการในการออร์เคสเตรชันเอเจนต์ AI เพื่อความน่าเชื่อถือในระบบโปรดักชัน

1. กำหนดข้อตกลงของงาน เกณฑ์การยอมรับ และเงื่อนไขการหยุดอย่างชัดเจน

เป้าหมายที่คลุมเครือและนิยามของคำว่าเสร็จสิ้นที่ไม่ชัดเจนมักนำไปสู่ผลลัพธ์จากเอเจนต์ที่น่าผิดหวัง ทางแก้คือข้อตกลงพรอมต์ (ขอบเขตงานสำหรับเอเจนต์): ตกลงเรื่องเป้าหมาย ข้อจำกัด รูปแบบเอาต์พุต และเงื่อนไขความล้มเหลวก่อนเริ่มดำเนินการ

ตัวอย่างเช่น นี่คือวิธีที่คุณอาจกำหนดข้อตกลงสำหรับเอเจนต์ที่รับผิดชอบการแก้ไขการทดสอบการผสานรวมที่ล้มเหลวเป็นครั้งคราว:

  • เป้าหมาย: ระบุและแก้ไขสาเหตุของการทดสอบการผสานรวม API การชำระเงินที่ให้ผลไม่คงที่ (flaky)
  • อินพุต: ซอร์สโค้ดของการทดสอบ ล็อกความล้มเหลวของ CI คอมมิตล่าสุด และโค้ดแอปพลิเคชันที่เกี่ยวข้อง
  • ข้อจำกัด: ห้ามปิดใช้งานการทดสอบ ผ่อนปรนการตรวจสอบ (assertion) หรือแก้ไขพฤติกรรมของแอปพลิเคชันที่ไม่เกี่ยวข้อง
  • เอาต์พุตที่คาดหวัง: แพตช์โค้ด คำอธิบายสาเหตุที่แท้จริง และผลการรันการทดสอบ
  • เกณฑ์การยอมรับ: การทดสอบที่เคยล้มเหลวผ่านติดต่อกัน 10 ครั้ง และชุดการทดสอบการถดถอยที่เกี่ยวข้องผ่านทั้งหมด
  • เงื่อนไขความล้มเหลว: ไม่สามารถระบุสาเหตุที่แท้จริงได้ การแก้ไขทำให้เกิดการถดถอย หรือไม่มีสภาพแวดล้อมการทดสอบที่จำเป็นให้ใช้งาน

แต่ยังมีอีกส่วนสำคัญหนึ่ง: เอเจนต์ควรหยุดเมื่อใด

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

กลับมาที่ตัวอย่าง CI ของเรา คุณอาจกำหนดเงื่อนไขการหยุดดังต่อไปนี้:

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

2. ทำให้ออร์เคสเตรเตอร์มีหน้าที่กระชับ และบังคับใช้การส่งต่องานที่มีโครงสร้าง

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

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

ลองพิจารณาตัวอย่างนี้: status: completed หมายถึงงานที่เอเจนต์ได้รับมอบหมาย ไม่ใช่เวิร์กโฟลว์ทั้งหมด เนื่องจากการทดสอบยังอยู่ในสถานะ pending ออร์เคสเตรเตอร์จึงไม่ควรอนุมัติผลลัพธ์สุดท้าย

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. จัดเก็บสถานะของเวิร์กโฟลว์อย่างถาวรและควบคุมการเติบโตของคอนเท็กซ์

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

ตัวอย่างเช่น หากเอเจนต์เขียนโค้ดสร้างแพตช์แล้วขัดข้อง เวิร์กเกอร์ถัดไปควรดึงอาร์ทิแฟกต์ที่บันทึกไว้และดำเนินการต่อจากสถานะของเวิร์กโฟลว์ที่บันทึกไว้ แต่หากเอเจนต์ได้สั่งให้รัน CI ภายนอกด้วย ออร์เคสเตรเตอร์ต้องตรวจสอบสถานะการรันนั้นแยกต่างหากก่อนทำซ้ำการดำเนินการ

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

4. ออกแบบการลองใหม่ที่คำนึงถึงความล้มเหลว และการเรียกใช้เครื่องมือที่กู้คืนได้

สมมติว่าเอเจนต์ CI ของคุณสั่งรันการทดสอบ แต่คำขอ API หมดเวลา การรันการทดสอบเริ่มไม่สำเร็จ หรือบริการ CI นำคำขอเข้าคิวแล้วแต่การตอบกลับสูญหายไป

การหมดเวลาไม่ได้หมายความว่าการดำเนินการล้มเหลวเสมอไป นั่นคือเหตุผลที่คุณต้องแยกแยะข้อผิดพลาดก่อนตัดสินใจว่าจะทำอะไรต่อ:

  • ข้อผิดพลาดชั่วคราว (429, 503): ลองใหม่โดยใช้ exponential backoff ที่มีขอบเขตจำกัดร่วมกับ jitter และปฏิบัติตาม Retry-After เมื่อมีการระบุไว้
  • ข้อผิดพลาดด้านการตรวจสอบความถูกต้องหรือสิทธิ์ (400, 403): หยุดหรือแก้ไขปัญหาที่ต้นเหตุ แทนที่จะส่งคำขอเดิมซ้ำ
  • ผลลัพธ์ที่คลุมเครือ (หมดเวลาหลังจากอาจมีการเขียนข้อมูลแล้ว): ตรวจสอบว่าการดำเนินการสำเร็จหรือไม่ก่อนลองใหม่อีกครั้ง

หมายเหตุ: แม้แต่ข้อผิดพลาดที่ลองใหม่ได้ก็ยังต้องมีขีดจำกัด ตั้งค่าการหมดเวลาสำหรับการเรียกใช้เครื่องมือแต่ละครั้ง จำกัดจำนวนครั้งและเวลารวมของการลองใหม่ และบังคับใช้กำหนดเวลาโดยรวมของเวิร์กโฟลว์ เพื่อไม่ให้เอเจนต์ที่ซ้อนกันเริ่มการดำเนินการเดิมซ้ำไปเรื่อย ๆ หากสิ่งที่พึ่งพาล้มเหลวซ้ำ ๆ ให้ใช้ circuit breaker เพื่อหยุดคำขอชั่วคราว

สำหรับการดำเนินการที่มีผลข้างเคียงภายนอก ให้กำหนดคีย์ idempotency ที่คงที่ให้กับการดำเนินการเชิงตรรกะแต่ละรายการ และนำกลับมาใช้ซ้ำในการลองใหม่ทุกครั้ง หาก API รองรับการขจัดข้อมูลซ้ำฝั่งเซิร์ฟเวอร์ ก็จะสามารถจดจำคำขอที่ซ้ำกันได้โดยไม่ต้องดำเนินการสองครั้ง หากไม่รองรับ ให้สืบค้นระบบภายนอกโดยใช้ correlation ID หรือข้อมูลอ้างอิงที่เชื่อถือได้อื่น ๆ

เมื่อคุณไม่สามารถระบุได้ว่าเกิดอะไรขึ้น ให้หยุดและยกระดับปัญหา

ตัวอย่างตรรกะการลองใหม่สำหรับเอเจนต์ CI ของเรา ซึ่งเขียนในรูปแบบซูโดโค้ด:

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

หมายเหตุเกี่ยวกับโค้ด: ตัวอย่างนี้สมมติว่า API ของ CI รองรับการค้นหาการรันด้วย ID คำขอ request_id จะป้องกันการทำซ้ำได้ก็ต่อเมื่อผู้ให้บริการรับประกัน idempotency อย่างชัดเจนเท่านั้น bounded_retry() เป็นซูโดโค้ดเพื่อการอธิบายเท่านั้น ในระบบโปรดักชัน การลองใหม่ควรถูกจำกัดทั้งด้วยงบประมาณการลองใหม่ต่อการดำเนินการ (จำนวนครั้งสูงสุดหรือเวลาที่ผ่านไป) และกำหนดเวลาโดยรวมของเวิร์กโฟลว์

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

5. กำหนดเส้นทางและแบ่งงานแบบขนานด้วยงบประมาณทรัพยากรที่ชัดเจน

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

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

ตัวอย่างเช่น Effort Mode ของ Perplexity Computer ช่วยให้คุณเลือกได้ว่างานหนึ่ง ๆ ควรใช้ความพยายามมากเพียงใดโดยไม่ต้องเลือกโมเดลด้วยตนเอง เลือก Light, Standard, High หรือ Ultra แล้ว Perplexity จะเลือกโมเดลที่ทำหน้าที่ออร์เคสเตรชันและระดับการให้เหตุผลของโมเดลนั้นให้โดยอัตโนมัติ จากนั้นออร์เคสเตรเตอร์จะมอบหมายงานย่อยให้กับเอเจนต์สนับสนุน ซึ่งสามารถใช้โมเดลจากผู้ให้บริการต่าง ๆ ได้

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

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

เพื่อให้การใช้ทรัพยากรคาดการณ์ได้ ให้บังคับใช้ขีดจำกัดทรัพยากรและการควบคุมการจัดกำหนดการ:

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

6. บังคับใช้การอนุมัติและแยกการดำเนินการของเอเจนต์

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

“ผมไม่ค่อยเชื่อมั่นในระบบหลายเอเจนต์ที่ซับซ้อนเกินไป โดยเฉพาะเมื่อเอเจนต์คอยรีวิวและอนุมัติงานของกันและกัน คุณอาจจบลงด้วยการที่เอเจนต์หลายตัวส่งต่อข้อผิดพลาดเดียวกันไปอย่างมั่นใจ โดยไม่มีใครจับได้เลย” Spilker เตือน

สำหรับการดำเนินการที่ต้องได้รับการอนุมัติจากมนุษย์ ให้หยุดการดำเนินการชั่วคราวและบันทึกการดำเนินการที่เสนอไว้อย่างตรงตามจริง:

  • พารามิเตอร์ของการดำเนินการ
  • ทรัพยากรเป้าหมายของการดำเนินการ
  • คอมมิตหรือเวอร์ชันสถานะของการดำเนินการ
  • การตัดสินใจของผู้รีวิว

นอกจากนี้ ให้กำหนดว่าจะเกิดอะไรขึ้นหากการอนุมัติถูกปฏิเสธ หมดอายุ หรือต้องยกระดับ ซึ่งเป็นสิ่งจำเป็นสำหรับเฟรมเวิร์กที่ดำเนินการต่อได้ (resumable) เนื่องจากการดำเนินการต่อของโหนดที่ถูกขัดจังหวะจะรันโค้ดซ้ำตั้งแต่ต้นของโหนดนั้น ผลข้างเคียงใด ๆ ที่เกิดก่อนการขัดจังหวะอาจเกิดขึ้นอีกครั้ง

ดังนั้น หากการอนุมัติถูกปฏิเสธหรือหมดอายุ คำขอจะถูกปิด หากคอมมิตเป้าหมาย พารามิเตอร์ หรือสิทธิ์มีการเปลี่ยนแปลงก่อนการดำเนินการ ให้ยกเลิกการอนุมัตินั้นและขออนุมัติใหม่

นอกจากนี้ Spilker ยังไม่สนับสนุนแนวคิดที่มองว่าเอเจนต์ที่ทำงานอัตโนมัติเต็มรูปแบบตั้งแต่ต้นจนจบคือเป้าหมาย “สำหรับผม แนวทางที่ดีกว่าคือการสร้างเอเจนต์ที่มุ่งเน้นเฉพาะด้านไม่กี่ตัว โดยมีความรับผิดชอบที่ชัดเจน สิทธิ์ที่กำหนดไว้ และการรีวิวโดยมนุษย์ในจุดที่เหมาะสม คุณยังคงได้ประสิทธิภาพโดยไม่ต้องสละการควบคุมทั้งหมด” เขากล่าวสรุป

7. ตรวจสอบเอาต์พุตอย่างอิสระและทดสอบพฤติกรรมการกู้คืน

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

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

ติดตามเวิร์กโฟลว์เพื่อระบุว่าเกิดข้อผิดพลาดที่จุดใด

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

ข้อตกลงเชิงความหมายสำหรับ GenAI ของ OpenTelemetry มอบวิธีมาตรฐานในการอธิบายการดำเนินการเหล่านี้ ตัวอย่างเช่น invoke_workflow ระบุการดำเนินการของเวิร์กโฟลว์ invoke_agent ระบุการเรียกใช้เอเจนต์ และ execute_tool ระบุการเรียกใช้เครื่องมือ การดำเนินการแต่ละรายการสามารถบันทึกเป็น span พร้อมด้วยระยะเวลา สถานะ และเมทาดาทาที่เกี่ยวข้อง

ขั้นตอนนี้จะให้เทรซของเส้นทางการดำเนินการแก่คุณ เพื่อให้คุณระบุได้ว่าเอเจนต์ติดขัดที่จุดใด

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

ตัวอย่างเทรซการดำเนินการเพื่อการอธิบาย

ตรวจสอบเอาต์พุตอย่างอิสระ

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

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

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

จำลองความล้มเหลวเพื่อทดสอบการกู้คืน

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

เพื่อทดสอบเรื่องนี้ ให้จงใจแทรกความขัดข้องในสภาพแวดล้อมสำหรับทดสอบ:

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

หลังการทดสอบแต่ละครั้ง ให้ตรวจสอบร่องรอยการดำเนินการ (execution trace) เพื่อดูว่าขั้นตอนใดทำงานไปแล้ว เวิร์กโฟลว์กลับมาทำงานต่อจากจุดใด และมีการดำเนินการใดถูกทำซ้ำหรือถูกข้ามไปหรือไม่ จากนั้นจึงตรวจสอบผลลัพธ์ที่เกิดขึ้นจริง

สมมติว่าเอเจนต์ CI ของคุณส่งคำขอเพื่อเริ่มการรันทดสอบ แต่การตอบกลับจาก API หมดเวลา เอเจนต์จึงลองใหม่ ได้รับการตอบกลับว่าสำเร็จ และรายงานว่า Success ทุกอย่างดูเรียบร้อยดี จนกระทั่งคุณตรวจสอบบริการ CI และพบว่ามีการรันทดสอบถูกสร้างขึ้นสองรายการแทนที่จะเป็นรายการเดียว

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

เพิ่มความล้มเหลวที่คุณค้นพบลงในการทดสอบการถดถอย (regression test) เพื่อไม่ให้การเปลี่ยนแปลงในอนาคตทำให้ปัญหาเหล่านั้นกลับมาอีก

ท้ายที่สุดแล้ว ความสำเร็จ หมายความว่าเวิร์กโฟลว์ผ่านการตรวจสอบที่กำหนดไว้ และผลลัพธ์ในระบบภายนอกได้รับการยืนยันแล้ว

คำถามที่พบบ่อยเกี่ยวกับการประสานงานเอเจนต์ AI

เหตุใดเอเจนต์ AI ที่ทำงานแยกส่วนกันจึงล้มเหลวเมื่อใช้งานในระดับองค์กร?

เอเจนต์ที่ทำงานแยกส่วนกันอาจทำงานของแต่ละตัวได้อย่างถูกต้อง แต่เมื่อนำมารวมกันกลับให้ผลลัพธ์ที่ไม่สอดคล้องกัน ลองนึกภาพว่าเอเจนต์ฝ่ายขายดึงเงื่อนไขของลูกค้าเมื่อเวลา 10:00 น. เอเจนต์ด้านราคาคำนวณใบเสนอราคาโดยใช้ราคาที่อัปเดตแล้วเมื่อเวลา 10:05 น. และเอเจนต์ด้านกฎหมายตรวจสอบสัญญาที่มีการเปลี่ยนแปลงเมื่อเวลา 10:07 น. เอเจนต์แต่ละตัวทำงานกับสแนปช็อตของธุรกิจคนละช่วงเวลา ผลลัพธ์ที่ได้จึงอาจขัดแย้งกันเอง

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

จะป้องกันไม่ให้เอเจนต์ AI ลองใหม่วนซ้ำไม่รู้จบได้อย่างไร?

กำหนดขีดจำกัดในหลายระดับ ได้แก่ จำนวนครั้งสูงสุดในการลองเรียกใช้เครื่องมือซ้ำ จำนวนรอบการทำงานสูงสุดของเอเจนต์ ความลึกของการมอบหมายงาน และกำหนดเวลาสิ้นสุดโดยรวมของเวิร์กโฟลว์ จำแนกประเภทความล้มเหลวก่อนลองใหม่ สำหรับการตอบกลับ 429 ที่เกิดขึ้นชั่วคราว ให้ปฏิบัติตาม Retry-After หากมีการระบุไว้ มิฉะนั้นให้ใช้ exponential backoff แบบมีขอบเขตร่วมกับ jitter

หยุดลองส่งคำขอเดิมที่ไม่มีการแก้ไขซ้ำหลังจากเกิดข้อผิดพลาดด้านการตรวจสอบความถูกต้องหรือด้านสิทธิ์ หากบริการปลายทางล้มเหลวซ้ำ ๆ ตัวตัดวงจร (circuit breaker) จะช่วยป้องกันไม่ให้เอเจนต์สร้างภาระงานเพิ่มเติมได้

จะกลับมาดำเนินเวิร์กโฟลว์ของเอเจนต์ AI ต่อหลังจากระบบล่มได้อย่างไร?

กลไกการกู้คืนขึ้นอยู่กับรันไทม์ที่คุณใช้ สำหรับ LangGraph ตัวบันทึกเช็กพอยต์แบบถาวร (persistent checkpointer) เช่น PostgresSaver จะจัดเก็บสถานะของกราฟไว้ภายใต้ thread_id ทำให้การดำเนินการทำต่อจากสถานะที่บันทึกไว้ได้ สำหรับ Temporal เวิร์กเกอร์ตัวอื่นสามารถสร้างเวิร์กโฟลว์ขึ้นใหม่ได้โดยเล่นซ้ำประวัติเหตุการณ์ของเวิร์กโฟลว์นั้น ระหว่างการเล่นซ้ำ เวิร์กเกอร์จะนำผลลัพธ์ของ activity ที่บันทึกไว้ก่อนหน้านี้กลับมาใช้

หากมีการดีพลอยแอปพลิเคชันใหม่ขณะที่เวิร์กโฟลว์ยังทำงานอยู่ สถานะที่บันทึกไว้และประวัติการดำเนินการอาจใช้ร่วมกันไม่ได้อีกต่อไป Temporal แก้ปัญหานี้ด้วย Worker Versioning และการแพตช์เวิร์กโฟลว์ (workflow patching) สำหรับระบบที่ใช้เช็กพอยต์ ให้วางแผนการย้ายสคีมาและทดสอบการกู้คืนกับสถานะที่บันทึกไว้ซึ่งมีอยู่แล้ว ก่อนนำการเปลี่ยนแปลงที่เข้ากันไม่ได้ออกใช้งาน

จะทดสอบความน่าเชื่อถือของการประสานงานเอเจนต์ AI ได้อย่างไร?

รันงานที่เป็นตัวแทนชุดเดิมหลายครั้ง และแยกความแตกต่างระหว่าง pass@k (ความพยายามอย่างน้อยหนึ่งครั้งจาก k ครั้งสำเร็จหรือไม่) กับ pass^k (ความพยายามทั้ง k ครั้งสำเร็จทั้งหมดหรือไม่)

วัดผลลัพธ์แยกตามหมวดหมู่ของงานและเวอร์ชันของเวิร์กโฟลว์ แทนที่จะอาศัยอัตราความสำเร็จรวมเพียงค่าเดียว ติดตามอัตราความสำเร็จในความพยายามครั้งแรก ความสม่ำเสมอระหว่างการรันซ้ำ เวลาแฝงที่ p95 ต้นทุนต่องานที่เสร็จสมบูรณ์ และสัดส่วนงานที่ต้องให้มนุษย์เข้ามาแทรกแซง รายงานขนาดตัวอย่างและช่วงความไม่แน่นอนของอัตราความสำเร็จด้วย