תבנית ה-PRG עבור סוכני AI
סוכני AI נתקלים בבעיה ישנה. זהו אותו באג ששיבש טפסים באינטרנט בשנות ה-90.
בימי האינטרנט הישנים, משתמש היה שולח טופס. אם הוא היה לוחץ על רענון (refresh), הדפדפן היה שולח שוב את הנתונים. המשמעות הייתה שתי הזמנות, שני חיובים או שני אימיילים.
הפתרון היה תבנית ה-Post/Redirect/Get (PRG).
הלוגיקה פשוטה:
- המשתמש שולח בקשת POST.
- השרת מעבד את הפעולה.
- השרת שולח הפניה (302 Redirect) לכתובת URL חדשה.
- הדפדפן מבצע את ההפניה באמצעות בקשת GET.
רענון כעת רק טוען מחדש את דף התוצאה. הוא אינו חוזר על הפעולה.
סוכני AI החזירו את הבאג הזה לשכבה חדשה.
כשסוכן קורא לכלי (tool) כדי לחייב כרטיס או ליצור רשומה, דברים משתבשים. מתרחשת נפילת רשת. קונטיינר עובר ריסטארט. מופעל מגבלת קצב (rate limit). הסוכן אינו יודע אם הקריאה האחרונה הצליחה. לכן, הוא מנסה שוב.
ללא תיקון, הסוכן יוצר הזמנות כפולות ומחייב לקוחות כועסים.
עליכם ליישם את תבנית ה-PRG בצינורות העבודה (pipelines) של הסוכנים שלכם באמצעות מפתחות אידמפוטנטיות (idempotency keys).
מפתח האידמפוטנטיות הוא ההפניה (redirect) שלכם. הוא מפריד בין הפעולה לבין התוצאה.
איך ליישם זאת:
- כל כלי משנה מצב (mutating tool) חייב לקבל מפתח אידמפוטנטיות.
- צרו את המפתח לפני הניסיון הראשון.
- גזרו את המפתח מכוונת המשתמש (user intent), ולא מחותמת זמן (timestamp).
- השרת חייב לבדוק אם הוא ראה את המפתח בעבר.
- אם המפתח קיים, החזירו את התוצאה השמורה במקום להריץ את המשימה שוב.
עבור משימות ארוכות, אתם זקוקים ליותר מסתם מפתח. אתם זקוקים לנקודות בקרה (checkpointing).
checkpointing שומר את המצב (state) בכל שלב. אם הסוכן קורס באמצע משימה בת עשרים דקות, הוא ממשיך בדיוק מהנקודה שבה הפסיק. הוא לא מתחיל מחדש.
אם אתם יכולים לעשות רק דבר אחד, הפכו כל קריאה לכלי לבטוחה להרצה כפולה.
בנו את הסוכנים שלכם עם חמש הבדיקות הללו:
- האם כל כלי מקבל מפתח אידמפוטנטיות?
- האם המפתח מבוסס על כוונה ולא על זמן?
- האם המפתח משתמש מחדש בכל ניסיון חוזר?
- האם השרת מחזיר תוצאות שמורות עבור מפתחות כפולים?
- האם שלבי הביניים נשמרים עבור משימות ארוכות?
התבנית היא אותה תבנית. רק השכבה השתנתה.