סוכנים לא יכולים לחזות את ההוצאה של עצמם

טיוטת תרגום לעברית של Agents can't predict their own spend — לבדיקה ולעריכה לפני פרסום. מונחים טכניים נשארים באנגלית בכוונה.

אי אפשר לחזות תהליך סטוכסטי עם זנב שמן. אפשר רק לחסום אותו. זו, במשפט אחד, הסיבה שכל agent בפרודקשן צריך spend breaker — בדיוק כמו שכל שירות בפרודקשן צריך rate limiter.

הבעיה, בתקרית אחת

בתיאור שזכה לתפוצה רחבה, המהנדס Teja Kusireddy סיפר על pipeline של מחקר שוק עם ארבעה agents ב-LangChain, ששני agents בו נכנסו ללולאת ping-pong של בקשות בפרודקשן. זה רץ 11 ימים. החשבון היה $47,000. אף אחד לא שם לב עד שזה נגמר. (דיווח מגוף ראשון, לא ניתוח מבוקר — אבל צורת הכשל הקלאסית.)

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

ארבעה ממצאים

מעבדת הכלכלה הדיגיטלית של סטנפורד חקרה עומסי agent (How Do AI Agents Spend Your Money?, Brynjolfsson ואחרים). ארבע תוצאות צריכות לשנות את הדרך שבה מתקצבים:

1. משימות agentic צורכות פי ~1000 tokens לעומת chat. agent שמתכנן, קורא לכלים, משקף ומנסה שוב שורף שלושה סדרי גודל יותר מפנייה בודדת ב-chat. האינטואיציה שלך מעידן ה-chat טועה פי 1000.
2. אותה משימה משתנה עד פי 30 בעלות בין ריצות. אותו prompt, אותם כלים, אותו model — העלות של ריצה אחת לא מלמדת כמעט כלום על הבאה. השונות היא החשבון.
3. הדיוק מגיע לרוויה בהוצאה בינונית. מעבר לשיא, עוד הוצאה לא קונה עוד נכונות — זה בזבוז נטו. הזנב היקר של הריצות הוא לרוב הכי פחות שימושי.
4. מודלים מזלזלים באופן שיטתי בצריכה של עצמם. תשאל agent כמה יוציא — הוא יוריד את ההערכה. אי אפשר לסמוך עליו שינהל את עצמו.

למה אי אפשר לחזות — רק לחסום

טכניקות ייעול — caching, routing, context pruning, retrieval טוב יותר — מורידות את העלות הממוצעת. הן לא עושות כלום לגבי הזנב, ועם שונות פי 30 הזנב הוא המקום שאליו הולך הכסף. כלי observability מראים לך את השרפה אחרי שהבית כבר נשרף.

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

Measure everywhere. Enforce at the boundary.

זו התזה. למדוד כל קריאת model וכלי; לאכוף מדיניות הוצאה בגבול ה-hop — trip, degrade, and stop, לא רק alert. בדיוק את זה Breakerbox עושה, in-process:

from breakerbox import guard, Ladder

app = guard(
    my_langgraph_app,
    budget_usd=5.00,          # קיר קשיח שהריצה לא יכולה לחצות
    ladder=Ladder.default(),  # degrade before you die: model זול יותר ב-80%, עצירה חיננית ב-100%
    detect_loops=True,        # לתפוס את ה-runaway שהיה ל-pipeline של 11 הימים
)

עוד לא בטוח שאתה סומך על זה בפרודקשן? הפעל קודם ב-shadow mode — הוא רושם מה היה נתפס השבוע ולא אוכף כלום, כך שאתה רואה את הקיר לפני שאתה בונה אותו.