Agent-to-Human Escalation Design — מתי ואיך סוכן מעביר משימה לבן אדם

מאת צוות מדיה דיל · 12.08.2026 · Agentic Development · 5 דק׳

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

סוכן תמיכה אוטומטי קיבל פנייה מלקוח נסער שטען שחויב פעמיים על אותה עסקה. הסוכן, שהוגדר לפתור בעיות באופן עצמאי, ניגש לזכות את הכרטיס — אבל טעה בזיהוי איזו משתי החיובים היה השגוי, וזיכה את החיוב הלגיטימי במקום את הכפול. שום דבר בהתנהגות הסוכן לא היה "שגוי" מבחינה טכנית — הוא ביצע בדיוק את הפעולה שהתבקש לבצע, במהירות ובביטחון מלא. הבעיה האמיתית הייתה שהמצב דרש שיקול דעת שהסוכן לא היה אמור לקחת על עצמו לבד. Agent-to-Human Escalation Design הוא בדיוק על זה: איך מתכננים, מראש ובכוונה, את הרגעים שבהם סוכן AI צריך לעצור ולהעביר את ההחלטה לבן אדם, במקום לנסות לפתור הכול לבד.

למה "פשוט לשאול" לא פותר את הבעיה

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

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

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

עיצוב תנאי ההסלמה

תנאי הסלמה יעילים בנויים משילוב של כמה קריטריונים, לא קריטריון בודד:

• חומרת הפעולה — פעולות בלתי הפיכות (מחיקה, חיוב, ביטול הרשאה) מקבלות סף הסלמה נמוך משמעותית מפעולות הפיכות.
• סטייה מדפוס מוכר — כשהמצב הנוכחי שונה מהותית מכל תרחיש שהסוכן נתקל בו קודם (בהתבסס על נתוני טלמטריה היסטוריים, ראו Agent Telemetry Standardization), זה סימן שנדרש שיקול דעת אנושי גם אם הסוכן "מרגיש" בטוח.
• עומס רגשי/עסקי גבוה — פניות עם סימני מצוקה, כעס, או השפעה על יחסי לקוח משמעותיים מוסלמות כברירת מחדל, בלי קשר לרמת המורכבות הטכנית.
• ריבוי פרשנויות סבירות — כשיש יותר מדרך פעולה סבירה אחת ואין מידע מספיק כדי להכריע ביניהן.

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

איך בונים בקשת הסלמה שימושית

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

עיצוב הבקשה משפיע ישירות על מהירות התגובה. בקשה עם יותר מדי טקסט חופשי דורשת קריאה מלאה לפני שאפשר להגיב; בקשה עם אפשרויות בחירה ברורות ("אישור פעולה A / אישור פעולה B / דחייה מלאה") מאפשרת תגובה כמעט מיידית כשהמצב פשוט, ומשאירה מקום להרחבה רק כשבאמת נדרש. עקרון זה קרוב לדפוס שנדון במדריך על Prompt-to-Tool Binding, שם בקשת הבהרה ממוקדת עדיפה על שאלה פתוחה מדי.

מניעת עומס התראות

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

מדד שימושי לבדיקת בריאות מנגנון ההסלמה הוא יחס הסלמות שמובילות לפעולה שונה מההמלצה שהסוכן הציע, לעומת הסלמות שהאדם פשוט מאשר ללא שינוי. יחס גבוה מדי של אישור אוטומטי בלי שינוי מרמז שההסלמה מיותרת ואפשר להעלות את סף האוטונומיה; יחס נמוך מדי של אישור מרמז שרמת האוטונומיה כרגע נמוכה מדי ביחס למה שהסוכן באמת מסוגל לבצע נכון, נושא שמתקשר ישירות לתכנון harness שנדון במדריך Coding Agent Harness.

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

תגיות: human in the loop · AI escalation · agent design · confidence thresholds · AI safety · customer support automation

← חזרה לבלוג · צור קשר