כותרת: איך נותנים לסוכן AI משימה שמחכה לתשובה בלי ליצור כפילויות?

**תשובה קצרה:** מגדירים מה בדיוק מחכים לקבל, מתי מפסיקים לחכות ומה צריך לבדוק מחדש לפני הפעולה. שומרים מצב ומזהה למשימה, ומוודאים שהפעולה עדיין נחוצה כשהתשובה מגיעה.

### הופכים המתנה לחלק מהמשימה

משימה כמו "חכה לתשובה ואז תפתח טיקט" כוללת שתי החלטות שונות. הראשונה היא לזהות תשובה רלוונטית. השנייה היא להחליט אם עדיין צריך לפתוח טיקט. בין הבקשה לתשובה יכול להשתנות הרבה: מישהו אחר כבר טיפל, נוספה מגבלה או שהתשובה מתייחסת לבקשה אחרת.

כתבו מהו המקור, לאיזו שיחה או משימה הוא שייך, ואיזו תשובה מאפשרת להמשיך. תשובה כמו "כן" בלי ההקשר אינה תנאי מספיק. שמרו גם את גבולות הפעולה שהותרה, במקום לפרש את ההסכמה מחדש אחרי שעות.

### שומרים מצב שאפשר לחזור אליו

רשומת עבודה קצרה יכולה להכיל מזהה משימה, הבקשה המקורית, המקור שממתינים לו, התנאי להמשך והמצב האחרון שאומת. כדאי להפריד בין "ממתין", "התשובה התקבלה", "נבדק המצב הנוכחי" ו"הפעולה הושלמה".

המחשה: בקשה לאסוף תשובה על תקלה יכולה להישאר במצב ממתין. אחרי תשובה שמספיק טיקט, הסוכן בודק אם קיים טיקט מתאים. רק אחרי יצירה או שימוש בטיקט קיים ואימות הקישור, אפשר לסמן שהמשימה הושלמה. הדוגמה מתארת תכנון תהליך, לא תוצאה של מערכת מסוימת.

המזהה צריך להישאר קבוע גם כשאירוע נשלח פעמיים. כך אפשר לזהות מסירה חוזרת של אותה תשובה במקום להתחיל משימה חדשה.

### בודקים מחדש לפני פעולה

לפני יצירה או עדכון חזרו למערכת שבה הפעולה מתבצעת. בדקו אם התוצאה כבר קיימת, מי טיפל בה ואם הבקשה עדיין תקפה. זיכרון של המצב לפני ההמתנה אינו תחליף לבדיקה הזו.

אם ניסיון קודם הסתיים בלי תשובה ברורה מהשרת, חפשו קודם את התוצאה. timeout אינו הוכחה שהפעולה נכשלה. ניסיון חוזר בלי בדיקה עלול ליצור כפילות דווקא כשהפעולה הראשונה הצליחה.

### מגדירים סוף להמתנה

כתבו מתי ההמתנה מסתיימת ומה עושים אז: דיווח לבעל המשימה, סגירה ללא פעולה או בקשת החלטה. הודעה על חוסר תשובה צריכה להבדיל בין מקור שלא החזיר תשובה לבין מקור שלא היה נגיש.

כשמממשים חלק מהתהליך ב-GitHub Actions, אפשר להשתמש ב-concurrency כדי למנוע ריצות חופפות באותה קבוצה. זה מנגנון ביצוע, לא בדיקה שהפעולה העסקית טרם התרחשה.

חשוב לקרוא את התנהגות התור: ברירת המחדל של קבוצה מאפשרת ריצה אחת פעילה וריצה אחת ממתינה, וריצה ממתינה חדשה יכולה להחליף את הקודמת. הגדרה שמבטלת ריצה ישנה מתאימה לפעמים לבדיקת קוד, אך עלולה להיות שגויה כשכל בקשה צריכה טיפול. גם סדר הביצוע אינו הבטחה לסדר שבו הבקשות הגיעו.

### בודקים גם אירוע כפול ותשובה מאוחרת

הניסוי הראשון צריך לכלול תשובה בזמן, תשובה אחרי סגירה, אותה תשובה פעמיים ומקרה שבו מישהו כבר ביצע את הפעולה. בכל מקרה בדקו את התוצאה במערכת, לא רק את ההודעה שהסוכן החזיר.

הצלחה היא פעולה אחת נכונה, או החלטה נכונה שלא לפעול, עם מצב שאפשר להבין בדיעבד. עצם קבלת התשובה היא רק שלב בדרך.


## מהניסיון שלי

בפוסט שלי על המתנה בת׳רד תיארתי בקשה ל-Grok Bot לחכות לתשובה, ואז לטפל אם מספיק טיקט. כשהתשובה הגיעה, הוא מצא טיקט קיים והחזיר אותו במקום לפתוח כפילות. המדריך מתרגם את המקרה הזה לרשימת החלטות שאפשר לבדוק בתהליך אחר.

## בקצרה

מגדירים מה בדיוק מחכים לקבל, מתי מפסיקים לחכות ומה צריך לבדוק מחדש לפני הפעולה. שומרים מצב ומזהה למשימה, ומוודאים שהפעולה עדיין נחוצה כשהתשובה מגיעה.



## שאלות נפוצות

### מה צריך להגדיר לפני שהסוכן מתחיל לחכות?

מקור ומזהה, תשובה שמאפשרת להמשיך, גבולות הפעולה, סוף להמתנה ומצב אחרון שאומת.

### האם concurrency מונע כפילות בטיקטים?

הוא יכול למנוע ריצות חופפות, אבל אינו מוכיח שטיקט טרם נוצר. צריך לבדוק את המערכת לפני פעולה.

### מה עושים כשניסיון יצירה הסתיים ב-timeout?

בודקים אם התוצאה קיימת לפני ניסיון חוזר. חוסר תשובה אינו הוכחה שהפעולה נכשלה.

## על הכותב

עופר שפירא - The Israeli AI Agency - התאמה והתקנת סוכני AI לעסקים קטנים בישראל, בעברית, עם ליווי לאורך זמן.