מבוסס על מחקר InfiAgent (ינואר 2026) ותובנות מפיתוח מערכות voice agents בפרודקשן
הבעיה שאף אחד לא מדבר עליה
כל מי שבנה AI agent יודע את הסיפור: המערכת עובדת מעולה על משימות קצרות, אבל ברגע שמנסים לתת לה משהו ארוך יותר - היא מתחילה “לשכוח”, מתבלבלת, ומייצרת תוצאות משונות.
זו לא באג. זו בעיה ארכיטקטונית שנקראת Unbounded Context Growth.
מה קורה בפועל?
כשאייג’נט רץ על משימה, הוא צובר היסטוריה:
- כל פעולה שביצע
- כל תשובה שקיבל מכלי
- כל החלטת ביניים
- כל שגיאה ותיקון
ה-context window של ה-LLM מתמלא. ואז קורים שני דברים רעים:
1. Error Accumulation - שגיאות קטנות מצטברות. אייג’נט ששכח פרט קטן בצעד 3 יקבל החלטה שגויה בצעד 10, שתגרום לכשל בצעד 20.
2. Memory Loss - ה-LLM מאבד מידע חשוב שהיה בתחילת השיחה כי הוא נדחק על ידי מידע חדש יותר.
צעד 1-10: עובד טוב צעד 11-30: מתחיל להתבלבל צעד 31+: שגיאות מצטברות, תוצאות לא רלוונטיות
למה זו “בעיה ארכיטקטונית”?
כשאני אומרת “בעיה ארכיטקטונית שדורשת פתרון ארכיטקטוני” - הכוונה שזה לא משהו שתפתרו עם prompt טוב יותר או מודל חזק יותר.
זה כמו פקק תנועה: לא תפתרו אותו עם מכונית מהירה יותר. צריך לשנות את הכבישים.
באותו אופן, context שגדל ללא גבול הוא בעיה במבנה המערכת עצמה. גם GPT-5 עם context window של מיליון טוקנים יתמודד עם אותה בעיה - רק מאוחר יותר.
הפתרונות הנפוצים - ולמה הם לא עובדים
Context Compression - לדחוס את ההיסטוריה לסיכום קצר יותר. הבעיה: מאבדים מידע קריטי. מה שנראה לא חשוב בצעד 5 עשוי להיות קריטי בצעד 50.
RAG (Retrieval-Augmented Generation) - לשמור הכל בווקטור DB ולשלוף לפי רלוונטיות. הבעיה: האייג’נט לא תמיד יודע מה רלוונטי. וחיפוש סמנטי לא תופס הקשרים לוגיים.
Sliding Window - לשמור רק את N הפעולות האחרונות. הבעיה: מאבדים את ההקשר הרחב. האייג’נט שוכח למה הוא עושה את מה שהוא עושה.
הגישה החדשה: State Externalization
מחקר חדש בשם InfiAgent (ינואר 2026, מאוניברסיטת הונג קונג פוליטכניק) מציע גישה אחרת לגמרי:
אל תנסה לתחזק context ארוך - החצן את ה-state החוצה.
במקום לדחוס הכל לתוך ה-prompt, האייג’נט מתחזק workspace של קבצים שמייצגים את מצב המשימה.
איך הקונטקסט נשאר קבוע?
הטריק המרכזי: בכל צעד ה-context נבנה מחדש מאפס.
צעד 47: +------------------------------------+ | System prompt (קבוע) | | Workspace snapshot (מצב נוכחי) | | צעדים 42-46 בלבד (חלון אחרון) | +------------------------------------+
צעד 48: +------------------------------------+ | System prompt (אותו דבר) | | Workspace snapshot (מעודכן) | | צעדים 43-47 בלבד (חלון זז) | +------------------------------------+
ההיסטוריה המלאה? נשמרת בקבצים או ב-DB - אבל לא נכנסת ל-prompt.
האייג’נט “זוכר” דרך ה-workspace snapshot, לא דרך היסטוריית השיחה.
Traditional Agent: +-------------------------------------+ | System Prompt | | + Step 1 result | | + Step 2 result | | + Step 3 result | | + … (גדל ללא סוף) | | + Step N result | Context מתפוצץ +-------------------------------------+
InfiAgent Architecture: +-------------------------------------+ | System Prompt | | + Workspace Snapshot (מצב נוכחי) | | + 5 פעולות אחרונות בלבד | גודל קבוע תמיד +-------------------------------------+ | +-------------------------------------+ | External Workspace (files/DB) | | - היסטוריה מלאה | | - תוצאות ביניים | | - לוג החלטות | +-------------------------------------+
External Attention Pipeline - סאב-אייג’נט לקריאת מסמכים
InfiAgent מוסיף רכיב שנקרא External Attention Pipeline.
אם אתם מכירים את Claude Code - זה בדיוק אותו עיקרון.
כש-Claude Code צריך לקרוא קובץ גדול, הוא לא טוען את כולו ל-context. הוא משתמש ב-sub-agent שקורא את הקובץ ומחזיר רק את מה שרלוונטי לשאלה.
ב-InfiAgent זה עובד אותו דבר: כשהאייג’נט צריך לקרוא PDF של 80 עמודים, הוא לא טוען אותו ל-context שלו. במקום זה:
- קורא ל-tool ייעודי (
answer_from_pdf) - ה-tool מריץ LLM נפרד רק על המסמך הזה
- מחזיר רק את התשובה הרלוונטית
+-------------------------------------+ | Main Agent | | “מה המסקנה העיקרית של מאמר X?” | +------------------+------------------+ | v +-------------------------------------+ | Sub-Agent (answer_from_pdf) | | קורא את כל ה-PDF | | מחזיר: “המסקנה היא ש…” | +------------------+------------------+ | v +-------------------------------------+ | Main Agent | | מקבל רק את התשובה הקצרה | | ממשיך לצעד הבא | +-------------------------------------+
האייג’נט הראשי נשאר “קל” - הוא לא נושא את המשקל של כל המסמכים שקרא.
ההוכחה: 80 מאמרים אקדמיים
InfiAgent נבדק על משימה אמיתית: לקרוא 80 מאמרים אקדמיים ולכתוב סקירת ספרות מקיפה.
התוצאות:
- אייג’נטים רגילים קרסו אחרי ~30 מאמרים
- InfiAgent סיים את כל 80 - ושמר על איכות עקבית
והנה הדבר המרשים: זה עובד בלי fine-tuning ספציפי למשימה. אותה ארכיטקטורה עובדת על כל domain.
מודל 20B פרמטרים עם InfiAgent התחרה במודלים proprietary גדולים בהרבה - רק בזכות הארכיטקטורה.
יישום מעשי: מה עושים בפועל
העיקרון
במקום לצבור את כל ההיסטוריה ב-prompt, בכל צעד בונים את ה-context מחדש משני דברים בלבד:
- Snapshot של המצב הנוכחי - מה האייג’נט יודע עכשיו, מה הוא כבר החליט, מה נשאר לעשות
- חלון קטן של פעולות אחרונות - נגיד 5 צעדים אחורה, לא יותר
ההיסטוריה המלאה נשמרת בצד (DB או קבצים) - אבל לא נכנסת ל-prompt.
ארבעה עקרונות:
1. הפרד state מ-history - ה-state הנוכחי קטן וממוקד: “באיזה שלב אני, מה החלטתי, מה נשאר”. ההיסטוריה המלאה של איך הגעתי לשם - נשמרת בצד.
2. מבנה על טקסט - JSON עם שדות ברורים עדיף על טקסט חופשי. קל יותר לקרוא, קל יותר לעדכן, קל יותר לשלוף.
3. שמור את ה”למה” - לא רק מה האייג’נט החליט, אלא למה. זה מה שעוזר לו להמשיך בכיוון נכון גם בלי לזכור את כל ההיסטוריה.
4. סאב-אייג’נטים לקריאה - כמו Claude Code, כשצריך לעבד מסמך גדול - תן לאייג’נט נפרד לקרוא ולהחזיר רק מה שרלוונטי. האייג’נט הראשי נשאר קל.
מתי זה רלוונטי?
השתמש ב-state externalization כש:
- משימות ארוכות (עשרות צעדים ומעלה)
- מערכות multi-agent שמעבירות מידע ביניהן
- תהליכים שצריכים לשמור על consistency לאורך זמן
- אייג’נטים שמעבדים הרבה מסמכים
לא חייב כש:
- שיחות קצרות וממוקדות
- משימות חד-פעמיות פשוטות
- כשה-context window מספיק גדול למשימה
שורה תחתונה
הבעיה של unbounded context היא לא באג שאפשר לתקן עם prompt טוב יותר או מודל חזק יותר. זו הדרך שבה המערכת בנויה. כמו שלא תפתרו פקק תנועה עם מכונית מהירה יותר - צריך לשנות את הכבישים.
InfiAgent הוכיח את זה עם 80 מאמרים. עכשיו השאלה היא רק איך מיישמים את זה במערכת שלכם.
קריאה נוספת: