เอเจนต์ของคุณน่ะโอเคแล้ว แต่การส่งต่องานระหว่างกันต่างหากที่มีปัญหา
เดโมระบบ multi-agent ส่วนใหญ่มักจะแสดงให้เห็นเอเจนต์เพียงตัวเดียวที่สวมบทบาทต่าง ๆ พวกเขาแสดงให้เห็นว่าเอเจนต์ A ทำงานอย่างหนึ่ง แล้วเอเจนต์ B ก็ทำอีกอย่างหนึ่ง แต่พวกเขาไม่ได้แสดงให้เห็นว่าจะเกิดอะไรขึ้นเมื่อเอเจนต์ A ไม่สามารถส่งสิ่งที่เอเจนต์ B ต้องการให้ได้
ปีนี้ผมได้ปล่อยระบบ multi-agent ออกสู่การใช้งานจริง (production) ไปแล้ว 3 ระบบ ตัวเอเจนต์ไม่ใช่ส่วนที่ยาก แต่การส่งต่องาน (handoff) ต่างหากที่ยาก
การส่งต่องานเป็นมากกว่าแค่การส่งข้อความ คุณต้องจัดการเรื่องเหล่านี้:
- Schema alignment: เอเจนต์ B ต้องสามารถ parse ผลลัพธ์จากเอเจนต์ A ได้ทุกครั้ง
- Failure propagation: ระบบต้องรู้ว่าเมื่อใดที่เอเจนต์ตัวใดตัวหนึ่งทำงานล้มเหลว
- Context hygiene: ทุกการส่งต่อจะเพิ่ม noise เข้าไปใน context window ของคุณ
ข้อผิดพลาดที่ใหญ่ที่สุดคือการปฏิบัติกับเอเจนต์เหมือนเป็นกล่องดำ (black boxes) ที่เชื่อมต่อกันด้วยเชือก คุณเขียน prompt ให้เอเจนต์ A ได้ผลลัพธ์มา แล้วก็ยัดมันใส่เอเจนต์ B วิธีนี้ใช้ได้ผลจนกระทั่งมันพัง และเมื่อมันพัง คุณจะไม่รู้เลยว่าเพราะอะไร
หลีกเลี่ยงรูปแบบความล้มเหลวที่พบบ่อย 3 ประการนี้:
Silent truncation: เอเจนต์ A สร้างข้อมูลมากเกินไป เอเจนต์ B เลยตัดส่วนท้ายทิ้ง ทำให้เอเจนต์ B ประมวลผลข้อมูลเพียงบางส่วนและให้ผลลัพธ์ที่ไร้สาระออกมา คุณควรวัดจำนวน token ในทุกขั้นตอน
Schema drift: คุณเปลี่ยน prompt ของเอเจนต์ A ทำให้มันส่งผลลัพธ์ในรูปแบบที่ต่างออกไป เอเจนต์ B จะพังเพราะมันคาดหวังรูปแบบเดิม ควรใช้ structured output อย่าง Pydantic แทนการพึ่งพาแค่ prompt
Race conditions: คุณรัน worker 5 ตัวพร้อมกัน 3 ตัวทำงานเสร็จ แต่ 2 ตัวยังทำงานอยู่ ตัวรวบรวมข้อมูล (aggregator) ของคุณเริ่มทำงานเร็วเกินไปด้วยข้อมูลที่ไม่ครบถ้วน วิธีนี้อาจใช้ได้ในการทดสอบ แต่จะล้มเหลวเมื่อใช้งานจริง ควรใช้ barrier เพื่อรอให้ทุกงานเสร็จสิ้นก่อน
ระบบแรกของผมนั้นดูฉลาดแต่ยุ่งเหยิง มันใช้ dynamic routing และการส่งต่อแบบ implicit มันทำงานได้ดีจนกระทั่งเจอ traffic จริงและล้มเหลวโดยไม่แจ้งเตือน (failed silently)
ระบบที่สองของผมดูไม่สวยงามแต่ถูกต้อง ทุกการส่งต่อใช้ typed contract ทุกความล้มเหลวมีการระบุไว้อย่างชัดเจน (explicit) และเอเจนต์แต่ละตัวถูกแยกออกจากกัน (isolated)
ระบบปัจจุบันของผมรวมทั้งสองอย่างเข้าด้วยกัน มันใช้ระเบียบวินัยแบบเวอร์ชันที่สอง แต่ซ่อนโค้ดที่น่าเบื่อไว้เบื้องหลัง framework
หากคุณกำลังสร้างระบบ multi-agent ให้เริ่มจากเวอร์ชันที่ดูไม่สวยงามแต่ถูกต้องก่อน อย่าเพิ่งพยายามทำอะไรให้ดูฉลาดเกินไป ทำให้มันใช้งานได้จริงใน production ก่อน แล้วค่อยทำให้มันดูสง่างาม (elegant)
ปัญหาเรื่องการส่งต่องานไม่ได้ง่ายขึ้นหรอก แต่คุณจะไม่ต้องตกใจกับมันอีกต่อไป
Source: https://dev.to/mrclaw207/your-agents-are-fine-the-handoff-between-them-isnt-2dij
Optional learning community: https://t.me/GyaanSetuAi