מהו סוכן AI ואיך מתכננים מערכת שאפשר לסמוך עליה

הגדרה שימושית לסוכן AI

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

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

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

הלולאה עוברת מקליטה ועד בדיקת התוצאה

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

let messages = [{ role: "user", content: task }];

while (true) {
  const response = await model.create({ tools, messages });
  messages.push({ role: "assistant", content: response.content });

  // כל סיבת עצירה אחרת אומרת שיש תשובה סופית, או שקרה משהו שצריך לטפל בו
  if (response.stop_reason !== "tool_use") break;

  const results = await Promise.all(
    response.content
      .filter((block) => block.type === "tool_use")
      .map(async (block) => ({
        type: "tool_result",
        tool_use_id: block.id,
        content: await runTool(block.name, block.input),
      })),
  );

  messages.push({ role: "user", content: results });
}

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

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

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

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

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

{
  "name": "orders_get_status",
  "description": "מחזיר את סטטוס ההזמנה ותאריך המשלוח הצפוי לפי מספר הזמנה. להשתמש כשלקוח שואל היכן ההזמנה שלו. לא מתאים לביטול או לשינוי הזמנה.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "מספר הזמנה כפי שמופיע במייל האישור, למשל 10432-B"
      }
    },
    "required": ["order_id"]
  }
}

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

• מעט כלים חדים, לא הרבה כלים חופפים. חשיפת כל נקודות הקצה של ה-API כרשימת כלים היא הדרך הבטוחה לקבל סוכן שבוחר לא נכון. עדיף להגדיר כלים סביב תהליכי עבודה שלמים.
• מרחב שמות. קידומת אחידה לכל משפחת כלים, למשל orders_ או crm_, מונעת התנגשות ומבהירה גבולות כשמחוברים כמה מקורות.
• להחזיר תוכן שאדם היה מבין. מזהה UUID בפני עצמו אינו אומר למודל דבר. שם לקוח, סטטוס וקישור אומרים הרבה.
• לשלוט בנפח התשובה. משתמשים בעימוד, בסינון ובהגבלת תוצאות. פלט גדול מדי תופס את חלון ההקשר ומקשה על המודל לזהות את המידע הדרוש.
• איפה הכלי רץ. כלים שאתם מגדירים רצים אצלכם, ואתם אחראים ללולאה. כלים שהספק מריץ אצלו, כמו חיפוש ברשת או הרצת קוד בארגז חול, מחזירים תוצאה בלי שתתערבו.
• MCP כחיבור תקני. Model Context Protocol הוא תקן פתוח לחיבור אפליקציות AI למקורות חיצוניים. שרת יכול לחשוף Tools לפעולות, Resources למידע ו-Prompts לתבניות, בכפוף ליכולות שהלקוח והשרת תומכים בהן.

לאוטונומיה יש כמה רמות

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

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

השכבות שמגבילות אוטונומיה כבר קיימות בתשתיות ואין צורך להמציא אותן. אפשר להגדיר רשימת היתר של כלים, אבל התיעוד של אנתרופיק מדגיש שרשימת היתר לבדה אינה מכבה את שאר הכלים, והם עדיין זמינים למודל ונופלים למצב ההרשאות שהוגדר. כדי לבנות עוזר לקריאה בלבד התיעוד ממליץ לשלב רשימת היתר עם מצב שמסרב במקום לשאול, ולכבות כלים הרסניים ברשימת חסימה מפורשת, שמסירה את הגדרת הכלי מהבקשה כך שהמודל אינו רואה אותו כלל. בתוך MCP קיים מנגנון elicitation שמאפשר לשרת לבקש מהמשתמש מידע נוסף או אישור לפעולה, וב-Agents SDK של OpenAI, guardrails הם רכיב מוגדר שמאמת קלט ופלט ועוצר את הריצה מוקדם.

מה הסוכן זוכר וכיצד שומרים את המידע

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

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

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

למה סוכנים נכשלים

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

1. שגיאות מצטברות. אנתרופיק מציינת זאת במפורש כסיכון מובנה בסוכנים. הבעיה אריתמטית. לצורך המחשה בלבד, אם כל צעד מצליח בתשעים וחמישה אחוזים מהמקרים, עשרה צעדים ברצף מצליחים בפחות משישים אחוזים. אמינותו של כל צעד אינה פרט טכני אלא המכפלה שמכריעה את התוצאה.
2. הקשר שהתנפח. פלט ענק של כלי, היסטוריה ארוכה ומסמכים שנשאבו פנימה מדללים את מה שחשוב. מכאן מגיעה ההרגשה שהסוכן ״שכח״ את ההוראה מתחילת הריצה.
3. כלים מעורפלים. כאשר התיאור אינו חד, המודל עלול לבחור כלי לא מתאים. כאשר חסר ארגומנט, הוא עלול לנסות להשלים ערך במקום לבקש הבהרה. צריך לוודא את הארגומנטים בצד הקוד ולדחות ערך חסר או לא תקין לפני הפעלת הכלי.
4. אין אות אימות. המשוב הטוב ביותר הוא כללים מוגדרים ותשובה שמסבירה איזה כלל נכשל ולמה: בדיקות, ולידציה של סכמה, בדיקת טיפוסים. צילום מסך עוזר במשימות ויזואליות, ומודל שופט הוא הפתרון האחרון והפחות יציב מכולם.
5. תוצאה של כלי שמטופלת כהוראה. מה שחוזר מכלי הוא נתון, לא פקודה. מערכת שמתייחסת לטקסט שחזר מדף אינטרנט, ממייל או מכרטיס תמיכה כאל הוראה תקפה, מוסרת שליטה לכל מי ששולט בטקסט הזה. ההפרדה בין מקור ההוראות לבין התוכן שנקרא בדרך היא החלטת תכנון.
6. אין תקציב. בלי תקרת צעדים ותקרת עלות, לולאה שנתקעת בניסיון חוזר יכולה לרוץ הרבה מעבר לכל היגיון כלכלי לפני שמישהו מבחין בכך.

מה צריך להחליט לפני שבונים סוכן

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

1. מה גבול המשימה. אילו פניות או מקרים הסוכן מטפל בהם, ומה במפורש מחוץ לתחום ועובר לאדם.
2. מה נחשב הצלחה. לא ״תשובה טובה״, אלא קריטריון שאפשר לבדוק. אם אין להצלחה ניסוח שניתן לבדיקה, אין למה לכוון.
3. מה אות האימות. מה בודק אוטומטית שהצעד הצליח. בלעדיו אין לולאה שמתקנת את עצמה, אלא רק לולאה שממשיכה.
4. אילו כלים, ומה כל אחד מורשה לעשות. רשימה מפורשת, כולל מה כבוי. פעולות קריאה ופעולות שינוי הן שתי קטגוריות שונות.
5. איפה עובר קו האישור האנושי. אילו פעולות דורשות אישור לפני ביצוע, ומי מאשר אותן בפועל בשעה שתיים בלילה.
6. מה קורה בכישלון. העברה לאדם, פתיחת פנייה, התראה. סוכן שנכשל בשקט גרוע ממערכת שלא נבנתה.
7. מה מודל העלות. עלות הסוכן תלויה במספר הסיבובים, בגודל ההקשר, בכלים החיצוניים ובניסיונות החוזרים. הערכת עלות לפי מספר הפניות בלבד אינה מספיקה בלי למדוד גם את עומק הריצה.
8. מה נשמר ואצל מי. יומני ריצה, זיכרון, מידע אישי של לקוחות, ואילו ספקים חיצוניים רואים אותם.

שאלות נפוצות

מה ההבדל בין סוכן AI לבין אוטומציה רגילה?

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

האם צ׳אטבוט הוא סוכן AI?

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

כמה עולה להפעיל סוכן AI?

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

האם סוכן AI עובד היטב בעברית?

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

מתי כדאי להשתמש בכמה סוכנים ולא בסוכן אחד?

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

איך יודעים אם הסוכן באמת עובד?

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