כל צוות שמעלה סוכנים נתקל באותה שאלה: איך יודעים שהסוכן עושה את הדבר הנכון? לא רק מייצר טקסט שנשמע נכון, אלא באמת משלים את המשימה, משתמש בכלים הנכונים, מכבד הרשאות, ומשאיר את המערכת במצב הנכון. זה מה שאיוול פריימוורק מגדיר.
נכון לספטמבר 2026, אוצר המילים מתייצב: אנתרופיק פרסמה פריימוורק איוול מפורט לסוכנים (Anthropic Engineering, 2026). DeepEval ו-Braintrust שניהם ממצבים את עצמם כפלטפורמות איוול ולא כפלטפורמות סוכנים. Google Cloud הוסיפה איוול ברמת פרודקשן לפלטפורמת הסוכנים שלה (נובמבר 2025). הפער הוא כבר לא אם איוול קיים, אלא אם הפריימוורק שלכם תואם את ההתנהגות בפועל של הסוכן שלכם.
בונה בפורום קהילת AI תיאר את הפריימוורק כרתמה: “המערכת שמאפשרת למודל לפעול כסוכן: היא מעבדת קלטים, מבצעת אורקסטרציה של קריאות כלים, ומחזירה תוצאות. כשאנחנו מעריכים סוכן, אנחנו מעריכים את הרתמה ואת המודל עובדים יחד.” ההבחנה הזו חשובה. להעריך את המודל לבדו זה לפספס חצי ממשטח הכישלון.
חמשת הפטרנים
אף פריימוורק יחיד לא מכסה כל ממד איכות. סוכנים בפרודקשן צריכים סטאק, לא ציון בודד. הנה חמשת הפטרנים, מהדטרמיניסטי ביותר לגמיש ביותר.
| פטרן | מה הוא בודק | מתי הוא רץ | דוגמה |
|---|---|---|---|
| שערים דטרמיניסטיים | כישלונות קשים: בדיקות, בדיקות טיפוסים, פטרני אבטחה, חוזי סטייט | לפני דיפלוימנט (שער CI). אופציונלית בזמן ריצה | “כל קריאה ל-generate_invoice() חייבת לכלול audit_event: 'invoice_generated' בלוג” |
| LLM rubric | איכות הנימוק, שלמות, טון, דיוק | אחרי כל ריצה. דירוג מצטבר תקופתי | “דרגו את ההסבר של הסוכן בבהירות (1-5) ובדיוק עובדתי (1-5)” |
| סטטיק אנליסיס | איכות קוד, שגיאות lint, היגיינת import-ים, כיסוי בדיקות | לפני דיפלוימנט. רציף | בדיקות ruff, mypy, bandit על קבצי הפלט של הסוכן |
| חוזי סטייט | מצב המערכת אחרי פעולת סוכן: עדכוני מסד נתונים, כתיבת קבצים, הענקות הרשאה | אחרי שהסוכן מסיים. מאומת מול סטייט ייחוס | “אחרי create_user(), שורת המשתמש קיימת ואין כפילות אימייל” |
| מדדי תמליל | אותות התנהגותיים: מספר תורות, קריאות כלים, שימוש בטוקנים, לטנסי, פטרני ניסיון חוזר | במהלך ואחרי כל ריצה. נעקב לאורך זמן | “בממוצע 3.2 תורות לבקשה השבוע, עלייה מ-2.1 בשבוע שעבר” |
כל שכבה עונה על שאלה אחרת. שערים שואלים: זה שבר משהו? רובריקות שואלות: זה נעשה טוב? בדיקות סטטיות שואלות: הקוד בטוח? חוזי סטייט שואלים: העולם בצורה הנכונה? תמלילים שואלים: ההתנהגות משתנה עם הזמן?
אם מריצים רק רובריקות, מפספסים כישלונות אבטחה. אם מריצים רק שערים, מפספסים ירידת איכות. פריימוורק פרודקשן צריך לפחות שלוש שכבות שרצות ברציפות.
למה רוב הדמואים של סוכנים נכשלים ברכש
מצב הכישלון הוא לא נימוק גרוע. הוא ראיות חסרות. סקירת רכש שואלת: איך אתם יודעים שהסוכן לא ידליף מידע, יקרא ל-API הלא נכון, או ישחית רשומה? התשובה “נראה בסדר” לא עוברת.
איוול פריימוורק פותר את זה בכך שהוא הופך איכות לניתנת לאימות. שער שבודק security_logs: {event_type: "auth_blocked"} מייצר ראיה שצוות אבטחה יכול לקרוא. ציון רובריק של 4.2 מתוך 5 הוא מספר שאפשר לראות בו מגמה. חוזה סטייט שמאמת שרשומת אודיט קיימת הוא עובדה בינארית.
פריימוורק גם מגן על הסוכן מפני עצמו. בלי שערים, הסוכן יכול להצליח במשימה אחת ולשחת בשקט את מסד הנתונים באחרת. עם שערים, הכישלון נתפס לפני דיפלוימנט. עם מעקב תמלילים, רואים את פטרן השחיתות לפני שהוא חוזר.
הרתמה היא מטרת האיוול
כשמעריכים סוכן, מעריכים שני דברים בו-זמנית: את המודל (האם הוא מבין את המשימה?) ואת הרתמה (האם היא מנתבת קלטים נכון, מנהלת הקשר, קוראת לכלים בסדר הנכון ומטפלת בשגיאות?). הפריימוורק חייב לבחון את שניהם.
הפריימוורק של אנתרופיק (2026) מפריד במפורש בין מדרגים לפי סוג: deterministic_tests (שערים קשים), llm_rubric (איכות גמישה), static_analysis (היגיינת קוד), state_check (אימות עולם), tool_calls (מעקב התנהגות), transcript (מדדי אינטראקציה) ו-latency (מהירות). כל מדרג מייצר ציון נפרד. אף מספר יחיד לא לוכד את איכות הסוכן.
בחירת העיצוב הזו מכוונת. ציון יחיד מסתיר פשרות: סוכן מהיר אבל לא אמין נראה אותו דבר כמו סוכן איטי אבל מושלם. מדרגים נפרדים נותנים לכם להחליט איזה ממד חשוב לאיזה דיפלוימנט.
שערים דטרמיניסטיים קודם
לפני כל רובריק או ניקוד, מגדירים את הכישלונות הקשים. אלה המקרים שבהם הסוכן חייב לעצור, לא רק לקבל ציון גרוע.
דוגמאות מדיפלוימנטים של סוכנים בפרודקשן:
- עקיפת אימות: כל ניסיון להגיע לנקודת קצה מוגנת בלי טוקנים תקפים חייב להידחות על ידי הרתמה, לא רק להירשם בלוג.
- דליפת מידע: כל תגובה שכוללת תוכן מחוץ לתחום ההרשאות של הקורא חייבת להפעיל כישלון מיידי, לא ציון רובריק נמוך.
- שחיתות סטייט: כל פעולה שכותבת לטבלה הלא נכונה, מעדכנת את הרשומה הלא נכונה, או מוחקת מידע שצריך להישמר חייבת להיכשל בחוזה הסטייט.
אלה לא שיפוטי איכות. אלה חוזים. הפריימוורק מגדיר אותם כבדיקות דטרמיניסטיות עם קלטים מפורשים ופלטים צפויים, בדיוק כפי שהפריימוורק של אנתרופיק מתאר אותם.
בונים פריימוורק לצוות שלכם
לא צריכים את הפלטפורמה של כל ספק. צריכים פריימוורק שמתאים להתנהגות של הסוכן שלכם. מתחילים בשלוש שאלות:
- מה הכישלונות הקשים שאסור שיעברו לעולם? (שערים)
- איך נראית הצלחה במשימות שהסוכן מטפל בהן? (רובריק)
- באיזה מצב המערכת חייבת להיות אחרי שהסוכן רץ? (חוזה)
אז מוסיפים מעקב תמלילים כדי לראות אם התנהגות הסוכן סוטה עם הזמן. פריימוורק שלוקח שבוע לבנות ורץ חודשים שווה יותר מפריימוורק מושלם שלוקח שישה חודשים לעצב.
לקריאה נוספת
- Permission-Aware RAG: בדיקות ההרשאות בצד השליפה ששער דטרמיניסטי צריך לאמת (באנגלית).
- MCP Server Architecture: חוזי כלים מוקלדים ותוצאות שגיאה שמדדי תמליל יכולים לעקוב אחריהם.
- AI Agent Audit Log: בדיקת רשומות הרשאה וזיהוי שינויים ברשומות לוג קודמות (באנגלית).
- AI Coding Agent Benchmark: A Production Checklist: לבדוק אם ציון של סוכן קוד שימושי להחלטת פרודקשן (באנגלית).