בניית צינור אספקה (Pipeline) בטוח עבור סוכנים (Agents)
רוב ההדגמות של סוכנים מדלגות על שאלה חיונית. איך מאפשרים למערכת אוטונומית לשלוח דברים בשמכם מבלי לשלוח פעמיים או לשלוח עבודה שלא אושרה?
שליחה כפולה אינה שגיאה נדירה. זוהי התנהגות ברירת המחדל של תור (queue) פשוט כאשר עובד (worker) קורס באמצע משימה. עובד שולח הודעה ואז קורס לפני שהוא מתעד הצלחה. המערכת חושבת שהמשימה נכשלה ומורה לעובד חדש לנסות שוב. הלקוח מקבל שני אימיילים ואתם מקבלים פנייה לתמיכה.
אי אפשר למנוע כל קריסה. עליכם לתכנן למקרה של קריסה בתוך הפער שבין הפעולה לבין התיעוד שלה.
השתמשו בצינור ה-pipeline בן ששת השלבים הזה עבור כל פלט של סוכן בעל השלכות ממשיות:
• Produce: הסוכן מייצר את התוצר (artifact) המלא. הוא עדיין לא שולח דבר. • Persist: כתבו תחילה את הכוונה ואת התוצר לאחסון עמיד (durable storage). • Score: צרפו ציון ביטחון (confidence score) לפלט. • Review: הפנו פריטים עם רמת ביטחון נמוכה לאדם. • Approve: השתמשו בשער מסוג fail-closed. המערכת חוסמת את כל השליחות אלא אם אדם נותן אישור מפורש. • Send and Attest: שלחו את הפריט תחת lease, ולאחר מכן כתבו קבלה של ראיה (evidence receipt).
כל שלב חייב להיות מעבר עמיד ונפרד. המצב (state) חי במסד הנתונים שלכם, לא בזיכרון של העובד.
כדי למנוע כפילויות, השתמשו ב-row-level leasing. ב-Postgres, השתמשו ב-SELECT ... FOR UPDATE SKIP LOCKED. זה מבטיח שעובד אחד בלבד מחזיק במשימה בכל רגע נתון.
הכלל החשוב ביותר הוא איך אתם מטפלים ב-leases שפג תוקפם. אם עובד קורס בזמן שליחת הודעה חיצונית, אל תנסו אותה שוב באופן אוטומטי. במקום זאת, השאירו את המשימה "תקועה" לצורך סקירה אנושית. משימה תקועה גלויה עדיפה על שליחה כפולה בלתי נראית.
עליכם גם לפעול לפי עקרונות fail-closed:
- השליחה כבויה כברירת מחדל. דגל (flag) יחיד חייב לאפשר את כל התעבורה היוצאת.
- הזהות נבדקת. המערכת חייבת לאמת את כתובת השולח ואת אבטחת התעבורה (transport security) ברגע השליחה.
- לכל דבר נשארת קבלה. שליחה שלא תועדה היא כישלון.
אל תבנו זאת למשימות בעלות סיכון נמוך כמו לוגים פנימיים. השתמשו בזה כאשר טעות עולה בכסף, יוצרת בעיה משפטית או דורשת פנייה לתמיכה.
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi