Explainable Agent UI — הצגת פעולות, מקורות והרשאות למשתמש

מאת צוות מדיה דיל · 12.08.2026 · Generative UI · 5 דק׳

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

סוכן AI במערכת פיננסית ממליץ להעביר תקציב שיווק מערוץ אחד למשנהו, ומראה רק את המסקנה: "מומלץ להעביר 20% מהתקציב לערוץ B". מנהל השיווק שרואה את זה לא יכול להחליט אם לאשר, כי אין לו מושג על סמך אילו נתונים ההמלצה נבנתה, מאיפה הם הגיעו, ואיזו הרשאה היה לסוכן לגשת אליהם מלכתחילה. Explainable Agent UI הוא השכבה שהופכת סוכן מ"קופסה שחורה שפולטת המלצות" לשותף שאפשר לבקר את החלטותיו — הצגת פעולות, מקורות מידע והרשאות בצורה שמשתמש אנושי יכול לבחון ולהעריך, לא רק לקבל או לדחות בעיוורון. זה לא רק עניין של אמון סובייקטיבי — במערכות שמקבלות החלטות בעלות השפעה עסקית או רגולטורית, שקיפות היא לעיתים דרישת ציות ממש כמו כל בדיקת אבטחה אחרת.

שלוש שכבות שקיפות

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

Citation כאזרח מדרגה ראשונה בממשק

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

{
  "claim": "המכירות ברבעון האחרון עלו ב-12%",
  "source": {
    "type": "database-query",
    "ref": "sales_q3_2026",
    "confidence": 0.94
  }
}

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

הצגת שרשרת הפעולה בלי להציף

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

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

כלים שהסוכן הפעיל כרשימת ביקורת

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

הרשאות: מה הסוכן רואה ומה הוא לא רואה

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

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

שקיפות היא גם עניין ביצועים

יש פיתוי להשאיר את כל שכבת השקיפות כ"תוספת אופציונלית" שנטענת רק לפי בקשה, כדי לא להכביד על זמן הטעינה הראשוני. בפועל, זו טעות שגורמת בדיוק לתופעה ההפוכה מהרצויה: כשמידע השקיפות איטי או לא זמין באופן מיידי, משתמשים לומדים במהירות שלא כדאי לטרוח לבדוק אותו, וחוזרים להרגל של קבלה עיוורת. עדיף לתכנן מראש שנתוני citation ו-tool calls מגיעים כחלק מאותו payload שמייצר את התשובה עצמה — לא כקריאת API נפרדת שרצה אחרי מעשה — כדי שהמידע יהיה זמין באותה מהירות בדיוק כמו התשובה שהוא מסביר.

תגיות: Explainable AI · Agent Transparency · Citations · Structured Outputs · Permissions · Generative UI

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