Memory Systems לסוכנים, זיכרון ארוך טווח

הבעיה: כל session מתחיל מאפס

כשאתה מריץ Claude Agent לטיפול בכרטיסי תמיכה, הוא לא זוכר שאתמול החלטת להגיב תמיד בעברית, שהלקוח מסוים כועסן, או שכבר ניסית טקטיקה מסוימת ולא עבדה. כל session מתחיל עם context window ריק לחלוטין.

זה לא באג, זה ה-design של LLMs. אבל סוכנים שצריכים לפעול לאורך זמן (שבועות, חודשים) חייבים ארכיטקטורת זיכרון מחוץ ל-context. ב-23 לאפריל 2026 השיקה Anthropic את Claude Managed Agents Memory ב-public beta, אחת ההוכחות שהתחום הזה הפך מחקרי לפרודקשן.

ארבעת שכבות הזיכרון, טבלת השוואה

סוג	היכן נשמר	משך חיים	מתאים ל	עלות טוקנים
In-Context	בתוך ה-API request	שיחה נוכחית בלבד	multi-turn קצר, הקשר שיחה	גבוהה, גדל עם כל turn
External Files	קבצי /memories (filesystem)	לצמיתות	העדפות, progress log, SOPs	נמוכה, נקרא רק כשצריך
Vector DB	Pinecone / pgvector / ChromaDB	לצמיתות	חיפוש סמנטי, אלפי זיכרונות	נמוכה, top-k retrieval
Episodic Log	DB / JSON	לצמיתות	audit trail, "מה עשיתי ומתי"	נמוכה, לפי שאילתה

Memory Tool הרשמי של Anthropic

ב-2025 פרסמה Anthropic כלי זיכרון רשמי שניתן לצרף לכל messages.create call. הוא עובד בצד הלקוח, אתה שולט על הגב-אנד (קבצים, DB, cloud storage). Claude מקבל הנחיה אוטומטית: "ALWAYS VIEW YOUR MEMORY DIRECTORY BEFORE DOING ANYTHING ELSE", כלומר הוא בודק מה שמור לפני שמתחיל בכל משימה.

כך מוסיפים אותו ל-request:

// Python
client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    messages=[{"role": "user", "content": user_message}],
    tools=[{"type": "memory_20250818", "name": "memory"}]
)

Claude יכול לבצע 6 פעולות על directory /memories: viewcreatestr_replaceinsertdeleterename. הכל מגיע כ-tool_use call שה-application שלך מממש.

Episodic vs. Semantic, ההבדל שחשוב

"Episodic memory captures what happened. Semantic memory captures what is true." (Databricks Blog, 2026)

Episodic: "שלחתי הצעת מחיר ל-acme@example.com ב-14 לאפריל, הלקוח ענה תוך שעה בחיוב.", רשומה עם timestamp, action, outcome.
Semantic: "לקוחות בתחום נדל"ן מגיבים מהר יותר כשהמחיר מופיע בשורה הראשונה.", עובדה מוכללת שנגזרת מעשרות אפיזודות.

המעבר מ-Episodic ל-Semantic נקרא Memory Consolidation, תהליך שמתבצע לרוב בסוף session ומסכם את מה שנלמד. זה מה שמונע ניפוח של זיכרון עם noise.

דוגמה ישראלית: CRM Agent לצוות מכירות בסטארטאפ ת"א

נניח שבניתם CRM Agent עבור צוות מכירות ב-SaaS ישראלי. 5 Account Executives, כל אחד מנהל 80+ לקוחות. הבוט צריך לזכור:

פרטי לקוח קבועים (שם, תחום, גודל חברה, שפה מועדפת) ← Semantic Store, נטען ל-System Prompt
היסטוריית שיחות עם לקוח ("מה דיברנו עם מיקרוסופט IL לפני חצי שנה?") ← Vector DB עם semantic search
Action Items שנולדו מכל שיחה ("שלח הצעה, קבע follow-up, העבר ל-Legal") ← Episodic Log, מובנה עם תאריכים
Progress מהפגישה שנכנסת עכשיו ← In-Context, נבנה בזמן אמת

כל שכבה ממלאת תפקיד שונה. טעות נפוצה: לשים הכל ב-context ולקרוס ב-50,000 tokens.

שגיאות נפוצות ואיך להימנע

שגיאה 1, שמירת הכל: agent שכותב כל token לזיכרון מייצר noise בקצב מסחרר. הכלל: כתוב רק decisions, outcomes, ו-facts, לא transcript. Anthropic ממליצה על הנחיה מפורשת: "Only write down information relevant to [topic]".
שגיאה 2, חוסר הגנת path traversal: קלט זדוני יכול לנסות ../../../etc/passwd כ-path לזיכרון. חובה לוודא שכל path מתחיל ב-/memories ולהשתמש ב-pathlib.Path.resolve().relative_to() ב-Python.
שגיאה 3, לא לעדכן זיכרון לפני סיום session: Memory Tool מנחה Claude לכתוב progress לפני שהשיחה נגמרת. session שנגמר בלי עדכון = מידע אבוד לצמיתות.