Memory — מה שורד מעבר לשיחה

ברירת המחדל: שום דבר לא נשמר

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

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

תרשים המציג תיבת session 1 מלאה בשורות טקסט (כחול), קו מקווקו אנכי המסמן את סיום ה-session, תיבה מקווקווית דהויה המסמלת את היעלמות הקונטקסט, ותיבת session 2 ריקה לגמרי בצד ימין — ממחיש שהקונטקסט נעלם לחלוטין בסיום כל session ו-session חדש מתחיל מאפס.
כברירת מחדל, הקונטקסט נעלם לגמרי בסיום ה-session — ה-session הבא מתחיל ריק, בלי זיכרון מהקודם

מה זה בעצם Memory

Memory הוא אחסון חיצוני לקונטקסט — קובץ, מסד נתונים או אינדקס וקטורי — שהסוכן כותב אליו ומשהו קורא ממנו בתחילת session חדש. הכתיבה נחשפת לסוכן בדרך כלל ככלי ("שמור את זה"), והקריאה נעשית לפעמים ככלי ולפעמים אוטומטית, כשה-harness טוען את הזיכרון לקונטקסט לפני שהעבודה מתחילה.

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

תרשים המציג תיבת קונטקסט מימין עם שני חצים אל גליל אחסון חיצוני משמאל: חץ כחול 'כתיבה' מהקונטקסט אל הגליל, וחץ כתום 'קריאה' מהגליל בחזרה אל הקונטקסט — ממחיש ש-Memory היא שכבה חיצונית שה-agent כותב אליה וקורא ממנה במפורש, נפרדת מהקונטקסט עצמו.
Memory היא שכבת אחסון חיצונית שה-agent כותב אליה וקורא ממנה במפורש — לא יכולת מובנית של המודל

שני דפוסים נפוצים: קובץ הערות מול Retrieval

הדפוס הפשוט: קובץ טקסט (או כמה קבצים לפי נושא) שהסוכן מעדכן כשהוא לומד משהו ששווה לזכור — העדפת סגנון של המשתמש, החלטה ארכיטקטונית, מבנה הפרויקט. הקובץ נטען במלואו בתחילת כל session, כך שהמידע פשוט נמצא שם מההתחלה.

כשהזיכרון גדל מכדי לטעון את כולו, עוברים ל-retrieval: הזיכרונות נשמרים כ-embeddings באינדקס וקטורי (כמו בנושא ה-Vector Search), והסוכן שולף רק את מה שרלוונטי לשאלה הנוכחית. זה אותו עיקרון RAG, רק שהמסמכים המאוחזרים הם הזיכרונות של הסוכן עצמו.

תרשים המחולק לשני חלקים: משמאל קובץ הערות עם ארבע שורות טקסט וחץ יורד המראה שהכול נטען במלואו לתוך תיבת קונטקסט. מימין פיזור של נקודות כתומות (אינדקס וקטורי של זיכרונות), כשרק שתיים מודגשות ומחוברות בחצים לתיבת קונטקסט — שאר הנקודות נשארות בחוץ, ממחיש ששולפים רק את הקטעים הרלוונטיים.
קובץ הערות נטען במלואו תמיד; דפוס Retrieval שולף רק את קטעי הזיכרון הרלוונטיים לשאלה הנוכחית

זיכרון קצר טווח מול ארוך טווח

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

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

תחזוקת זיכרון: לא רק להוסיף

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

לכן מערכת זיכרון טובה מאפשרת לעדכן ולמחוק רשומות ולא רק להוסיף, שומרת מתי כל רשומה נכתבה, ומעדיפה עובדות מתומצתות על פני העתקה של שיחות שלמות. ויש גם צד אבטחתי: אם תוכן לא אמין (דף אינטרנט, מייל) יכול לגרום לסוכן לכתוב לזיכרון, ההוראה הזדונית תשרוד לכל ה-sessions הבאים — memory poisoning, שנפגוש שוב בפרק 13.

דוגמה מלאה: סוכן שמשתמש בקובץ זיכרון בין שתי שיחות

session א׳: המשתמש מבקש מהסוכן לבנות פיצ'ר, ותוך כדי מציין שהוא מעדיף named exports על פני default exports. הסוכן שומר את ההעדפה בקובץ memory.json ומסיים את המשימה.

session ב׳, למחרת: המשתמש מבקש פיצ'ר אחר לגמרי. לפני שהעבודה מתחילה, ה-harness טוען את memory.json (למטה) לקונטקסט. הסוכן "נזכר" בהעדפה בלי שהמשתמש יצטרך לחזור עליה, וכותב את הקוד החדש בהתאם.

JSON
{
  "preferences": [
    {
      "fact": "named exports, not default exports",
      "source": "user",
      "updated_at": "2026-09-22"
    }
  ]
}

שאלות נפוצות

מה ההבדל בין memory לבין RAG על מסמכי הארגון?

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

איך מונעים מזיכרון של משתמש אחד לדלוף למשתמש אחר?

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

האם המשתמש צריך לראות ולערוך את מה שהסוכן זוכר עליו?

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