הערכות ל-WebMCP

Kasper Kulikowski

פורסם: 19 במאי 2026, עודכן לאחרונה: 28 במאי 2026

סרטון הסבר	פיתוח אתרים	תוספים	הסטטוס של Chrome	הרציונל
GitHub	גרסת מקור לניסיון		תצוגה	הבעת עניין בהשתתפות בניסוי

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

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

כתיבת הערכות כדי לבדוק את נקודות המגע של המערכת עם מודל שפה גדול (LLM):

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

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

מצבי כשל

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

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

כשל	דוגמה	פתרון בעיות
הסוכן לא מצליח לבחור את הכלי הנכון או שהוא קורא ישירות לכלי הלא נכון.	הסוכן מדלג על addToCart ועובר ישירות אל checkout.	האם התיאור של הכלי description ברור, מלא ומשקף באופן מדויק את מה שהכלי עושה? האם השם functionName אינטואיטיבי ומתאר את הפעולה? האם הכלי נחשף בצורה נכונה ל-LLM במצב או בהקשר הנוכחיים? האם הסכימה של הכלי הזה דומה מדי לסכימה של כלי אחר, ולכן יש דו-משמעות בקריאה?
הנציג מפעיל כלים בסדר שגוי	הסוכן מתקשר אל checkout ואז אל addToCart.	האם יש חפיפה בין תיאורי הכלים, שגורמת ל-LLM להתבלבל לגבי הרצף הנדרש? האם הפלט של כלי קודם מספק את ההקשר הדרוש לקריאה הבאה לכלי? האם המצב מתעדכן בצורה נכונה והאם כל הכלים החדשים נחשפים ל-LLM כצפוי? האם תרחיש השימוש מקצה לקצה עדיין נכון אם קוראים לכלים מסוימים בסדר שונה? האם בדקת את השרשרת הספציפית של קריאות הכלים בבידוד על ידי אילוץ הקריאות הקודמות כדי לאשר שמודל ה-LLM בוחר את השלב הבא הנכון?
הנציג קורא לכלי עם ארגומנטים שגויים	הסוכן מתקשר אל addToCart, אבל מוסיף נעליים במקום חולצת טישרט.	האם המאפיין inputSchema מוגדר באופן ברור, כולל ערכי enum וdescription טוב לכל מאפיין? האם כל הפרמטרים הנדרשים מסומנים ומסומנים בתיבת הסימון? האם תיאור הארגומנט מסביר במפורש למודל ה-LLM איך למפות את קלט המשתמש לנתונים המובְנים הצפויים (למשל, מזהה או פורמט ספציפיים)?

מה קורה אם המשתמש רוצה לבדוק מה יש בעגלת הקניות שלו?

כשל	דוגמה	פתרון בעיות
הפלט של הכלי שגוי או שהכלי פספס משהו.	המשתמש מבקש viewCart, אבל הסוכן מציג את העלות הכוללת של העגלה במקום את שמות המוצרים והמחירים שלהם.	האם יש באגים בלוגיקה של הכלי הבסיסי (כדאי לבדוק באמצעות בדיקות דטרמיניסטיות)? האם מצב ממשק המשתמש עודכן בצורה נכונה והאם הסוכן קיבל את המידע הנכון לגבי תופעת הלוואי? אם הפלט משמש את ה-LLM לשיחות הבאות, האם הפלט מעוצב בצורה ברורה לצורך הטמעה ב-LLM? האם הפלט מפורט מדי? האם הוא מכיל רק את המידע החיוני המינימלי שנדרש ל-LLM כדי לבצע את הפעולה הבאה?

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

• האם קוד הכלי מטפל בצורה נכונה בכל השגיאות והחריגים הפוטנציאליים בזמן הריצה?
• האם השגיאה מדווחת לסוכן ולמודל בצורה תקינה?
• האם ממשקי API או שירותים חיצוניים שהכלי מסתמך עליהם תקינים?
• האם מבנה השגיאה ברור מספיק כדי שהמודל יוכל להבחין בין בעיה זמנית (ניסיון חוזר) לבין כשל קריטי?

כלי בדיקה מבודדים

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

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

מדידת הדיוק של השיחות

מומלץ לעיין בהדגמה שלנו, WebMCP zaMaker. כשמשתמש מזין את ההנחיה 'I'd like a small pizza', אפשר לצפות לתגובה של המודל שמציינת את הכוונה לבצע קריאה ל-set_pizza_size עם הארגומנט "size":"Small".

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

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

‫expectedCall משמש לביצוע בדיקה דטרמיניסטית מבוססת-כללים:

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

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

כשפותחים את WebMCP, מוצגים הכלים add_topping, set_pizza_size ו-set_pizza_style. כדי לבדוק בצורה מדויקת כל אחד מהכלים האלה, צריך לכלול את כל הכלים כדי ליצור מצב מלא ומדומה.

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

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

הרצת בדיקות דטרמיניסטיות

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

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

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

הרצת בדיקות הסתברותיות

אם אתם צריכים פלט של מודל כדי להפעיל כראוי את הכלים הבאים, אתם צריכים לכתוב eval.

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

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

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

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

בדיקה מקצה לקצה

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

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

דוגמה למסע מוצלח של סוכן:

1. עוברים לקטגוריית הבגדים.
2. למצוא אחד מפריטי הלבוש המבוקשים (סדר הפריטים לא חשוב).
3. חיפוש פריט ספציפי (search_clothes).
4. קבלת פרטי המוצר שמכילים את רשימת החומרים (get_product_details).
5. חוזרים על שלבים 2-4 לכל פריט שרוצים להוסיף.

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

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

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

הערכת כשלים באמצע השרשרת

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

"אני רוצה פיצה פסטו קטנה. תשתמש בקוד ההטבה שלי, FreePizza".

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

ניסוי של WebMCP

מתחילים להתנסות בהערכות של כלים בבידוד, ומעריכים את האתרים שלכם עם WebMCP באמצעות סוכן שתואם ל-WebMCP:

• אפשר להוריד את כלי ההערכה הניסיוניים שלנו ב-GitHub.
• מומלץ לעיין בקורס שלנו בנושא יצירת הערכות של AI.