Agentic evals: לבדוק מה ה-agent עשה, לא מה הוא כתב

יולי 2025, היום התשיעי של ניסוי ה-vibe coding של ג’ייסון למקין, המייסד של SaaStr. ה-agent של Replit מריץ פקודה הרסנית על ה-DB של production. זה קורה באמצע code freeze שלמקין הגדיר לו במפורש, והוא מוחק רשומות של 1,206 מנהלים וכ-1,200 חברות. אחר כך הוא מסביר שאי אפשר לעשות rollback. אפשר היה. למקין עשה את זה לבד.

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

בגדול, זה כל העניין של agentic evals: לבדוק מה ה-agent עשה, לא מה הוא כתב. בפברואר 2026 אמזון פרסמה שמאז 2025 נבנו אצלה אלפי agents. בשבילם הם היו צריכים workflow הערכה אחיד לכל הארגון, לא עוד benchmark למודל.

מאיפה זה בא, ומה זה לא

אף אחד לא המציא את המונח, הוא פשוט נדבק. ב-2024–2025 צוותים התחילו לשים agents ב-production וגילו ש-MMLU, GSM8K ו-HumanEval לא עונים על השאלה שלהם. NVIDIA ניסחו את זה הכי טוב במאי 2026: model benchmark בודק אם המנוע מספיק חזק. agent eval בודק איך המערכת כולה נוסעת על הכביש, עם תכנון, כלים ואי-ודאות.

השורשים קודמים. SWE-bench מפרינסטון (אוקטובר 2023) לא קרא את ה-diff שה-agent כתב. הוא הריץ את הטסטים של ה-repo אחרי ה-patch. τ-bench של Sierra (יוני 2024) עשה משהו חכם יותר: בסוף כל שיחה עם לקוח מדומה הוא משווה את ה-DB למצב היעד, ומריץ כל משימה כמה פעמים. משם הגיע pass^k, ההסתברות שה-agent מצליח בכל k הריצות, לא באחת מהן.

מה זה לא: זה לא leaderboard של מודלים, זה לא שופט LLM על ההודעה האחרונה, וזה גם לא observability. traces הם חומר הגלם. ה-eval הוא מה שאתם מצפים למצוא בהם.

שלוש שכבות בכל ריצה

Databricks כתבו את זה בינואר 2026 בשתי שורות:

For example, an answer may be correct, but the tool calls leading to it may be inefficient, risky or inconsistent. Evaluating only the final output can hide underlying reasoning failures, while evaluating steps without the outcome may overlook holistic performance.

— Databricks, What is AI Agent Evaluation

אז בודקים שלוש שכבות:

• תוצאה. מצב העולם אחרי הריצה: שורה ב-DB, קובץ, PR, מייל שנשלח או לא נשלח. IBM מזכירים שלפעמים אין בכלל טקסט לבדוק, רק רשומה שהתעדכנה.
• מסלול. אילו כלים, באיזה סדר, עם אילו ארגומנטים, ומה ה-agent עשה עם מה שחזר. באמזון מודדים במפורש כמה מדויקת בחירת הכלים.
• מעטפת. עלות, latency, מספר צעדים, tokens. ב-Confident AI קוראים לזה operating envelope. agent שמגיע לתשובה הנכונה ב-40 צעדים במקום 6 הוא באג, גם אם התשובה נכונה.

ב-Confident AI גם מונים את דפוסי הכשל שה-eval הקלאסי מפספס: לולאות retry שלא מתכנסות, סטייה ממה שהמשתמש רצה לאורך השיחה, ו-false task completion. ה-transcript אומר done ושום דבר לא השתנה. בדיוק Replit.

דוגמה: agent שמבטל הזמנה

נגיד שיש לכם agent תמיכה. המשימה: לבטל את הזמנה 4411 ולהחזיר כסף. הוא קורא ל-lookup_order, ל-check_policy, ל-issue_refund. ה-API של התשלומים מחזיר timeout, אז הוא מנסה שוב, וההחזר יוצא פעמיים. update_status נופל על 500. והתשובה ללקוח: “ההזמנה בוטלה, הכסף הוחזר”.

שופט על הטקסט נותן 5 מתוך 5. SELECT אחד על ה-DB מגלה שני החזרים והזמנה שעדיין פעילה.

רגע, ולמה להריץ כל תרחיש כמה פעמים? כי agent הוא לא פונקציה. אם ריצה בודדת מצליחה ב-90%, הסיכוי שחמש ריצות רצופות יצליחו הוא 0.9^5, בערך 59%. pass@1 של 90% נראה מצוין בדשבורד. pass^5 של 59% אומר שכמעט בחצי מהתרחישים משהו נופל לפחות פעם אחת מתוך חמש. וזה המספר שהלקוחות שלכם חווים.

וזה לא יקר. 40 תרחישים כפול 5 ריצות זה 200 ריצות. ב-80K tokens קלט לריצה יוצא 16 מיליון tokens, כ-$48 במחיר של $3 למיליון. פחות מארוחת צהריים לצוות.

איך מקימים את זה בלי framework

לא צריך פלטפורמה כדי להתחיל. מספיקים pytest, DB טרי לכל ריצה, וה-trace שה-agent שלכם כבר כותב:

import sqlite3
import pytest
from my_agent import run_agent, seed_db  # your agent + a fixture loader

TASK = 'Cancel order 4411 and refund the customer'
FORBIDDEN = {'delete_order', 'run_sql'}
N_RUNS = 5  # report pass^5: the scenario passes only if all 5 do

@pytest.mark.parametrize('run', range(N_RUNS))
def test_cancel_order(tmp_path, run):
    db = tmp_path / 'shop.db'
    seed_db(db)                      # fresh state every run
    trace = run_agent(TASK, db_path=db)
    con = sqlite3.connect(db)

    # 1. outcome: check the world, not the reply text
    status = con.execute('select status from orders where id=4411').fetchone()[0]
    assert status == 'cancelled'
    refunds = con.execute('select count(*) from refunds where order_id=4411').fetchone()[0]
    assert refunds == 1              # exactly one, retries included

    # 2. trajectory: right tools, right order, nothing forbidden
    tools = [step.tool for step in trace.steps]
    assert tools.index('lookup_order') < tools.index('issue_refund')
    assert not FORBIDDEN & set(tools)

    # 3. envelope: budget from today's p95 + 50%
    assert len(trace.steps) <= 8
    assert trace.input_tokens <= 60_000

קודם כל, state טרי בכל ריצה. אחרת ריצה 3 עוברת בזכות מה שריצה 2 השאירה. חוץ מזה, ה-assert הראשון הוא על העולם, לא על הטקסט. ובסוף, תקציב קשיח: 8 צעדים ו-60K tokens. תתחילו מה-p95 שלכם היום פלוס 50%, ותדקו משם.

אם אתם רוצים משהו מנוהל: MLflow 3 אצל Databricks, AgentCore Evaluations בבדרוק, או DeepEval עם @observe בקוד. כולם עובדים באותה שיטה: trace אחד שמשמש גם ל-observability וגם ל-eval.

איפה זה נשבר

שופט LLM עדיין נחוץ, למשל לטון, או כדי לבדוק אם ה-agent הבין מה המשתמש רצה. אבל הוא סטוכסטי בעצמו. ב-Confident AI ממליצים לכייל אותו מול rubric אנושי על מדגם של traces, כדי לתפוס את מה שהם קוראים לו metric green, user red.

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

עוד שני דברים שנופלים. mocks של כלים מתיישנים: ה-API האמיתי שינה שדה, ה-mock לא, וה-eval ירוק בזמן ש-production שבור. תריצו לפחות חלק מהתרחישים מול sandbox אמיתי. והדבר השני, goldens נרקבים. תרחישים שכתבתם לפני חצי שנה לא מכסים את מה שמשתמשים עושים היום. תמשכו תרחישים חדשים מ-production כל כמה שבועות.

מה לנסות השבוע

• תבחרו 10 תרחישים מ-logs אמיתיים: escalations, תלונות, ריצות שנתקעו.
• לכל תרחיש לפחות assert אחד על מצב העולם. לא על טקסט.
• רשימת כלים אסורים לכל תרחיש: delete_*, DROP, git push --force.
• תקציב צעדים ו-tokens: ה-p95 הנוכחי פלוס 50%.
• 5 ריצות לתרחיש. תדווחו pass^5 ליד pass@1.
• תחברו את זה ל-CI על כל שינוי ב-prompt, בכלים או בגרסת המודל.

ה-agent של Replit היה עובר את ה-eval של רוב הצוותים. תוודאו שהוא לא עובר את שלכם.