איך לנקות זיכרון מיושן של סוכני AI ולמנוע שגיאות

מדוע זיכרון של סוכן הופך למיושן

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

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

דעיכה וסחיפה הן תקלות שונות

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

סחיפה (Drift) היא עובדה שנשמרה פעם אחת ומעולם לא נבדקה מחדש. "מעדיף pnpm", "מסד הנתונים הוא Postgres 15", "פריסות עוברות דרך ענף ה-staging". אין שעון שהופך את אלו לשגויות. החלטה שהתקבלה במקום אחר היא זו שהופכת אותן לכאלו, ושום דבר לא מעדכן את מאגר הזיכרון שלך בנושא.

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

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

הגדרת תוקף לעובדות מוגבלות בזמן

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

CREATE TABLE memory (
  id            TEXT PRIMARY KEY,
  subject       TEXT NOT NULL,
  fact          TEXT NOT NULL,
  source        TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  confirmed_at  TEXT NOT NULL DEFAULT (datetime('now')),
  expires_at    TEXT,
  superseded_by TEXT REFERENCES memory(id) ON DELETE CASCADE
);

CREATE INDEX memory_expires ON memory(expires_at);
CREATE INDEX memory_superseded ON memory(superseded_by);

הפקודה datetime('now') מחזירה זמן אוניברסלי מתואם (UTC) בתבנית YYYY-MM-DD HH:MM:SS, אשר ממוין ומושווה כראוי כטקסט; לכן, כל שאילתת תאריכים להלן היא משפט WHERE פשוט. העמודה source אינה אופציונלית. עובדה שלא ניתן לעקוב אחריה עד להודעה, קובץ או פלט של פקודה, לעולם לא תוכל לעבור בדיקה חוזרת, ועובדה שלא ניתן לבדוק מחדש – דינה להימחק.

כתיבת זיכרון בעל תוקף פג:

INSERT INTO memory (id, subject, fact, source, expires_at)
VALUES ('m_0191', 'availability', 'Away from keyboard, replies are delayed',
        'chat 2026-08-08', datetime('now', '+7 days'));

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

CREATE VIEW live_memory AS
SELECT id, subject, fact, source, confirmed_at, expires_at
FROM memory
WHERE superseded_by IS NULL
  AND (expires_at IS NULL OR expires_at > datetime('now'));

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

בדקו את הפער באמצעות sqlite3 memory.db "SELECT count(*) FROM memory;" והשוו את אותו מספר מול live_memory. מאגר תקין יציג שני מספרים קרובים זה לזה. פער גדול מעיד על צבר של שורות מתות שטרם נוקו.

מדוע מחיקת זיכרון מותירה את הישן מאחור

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

UPDATE memory SET superseded_by = 'm_0207' WHERE id = 'm_0140';

השורה הישנה כעת בלתי נראית ל-live_memory, והשרשרת עדיין מתעדת מה השתנה. כעת מחק את m_0207, כיוון שהתברר שהיא שגויה. ה-ON DELETE CASCADE ב-superseded_by אמור לקחת את m_0140 איתו, שכן השורה הישנה היא הצאצא בקשר הזה. בדרך כלל זה לא קורה, כיוון ש-SQLite מתעלמת ממפתחות זרים אלא אם מפעילים אותם, וברירת המחדל היא כבויה:

sqlite3 memory.db "PRAGMA foreign_keys;"

זה מדפיס 0 בגרסה סטנדרטית. כאשר מפתחות זרים כבויים, DELETE FROM memory WHERE id = 'm_0207'; מצליח ו-m_0140 נשאר מאחור, ומצביע על id שכבר לא קיים. שום דבר לא מזהיר אותך. השורה הזו כעת מוסתרת מהסיבה הלא נכונה, וסקריפט הניקוי הראשון שמאפס מצביעים תלויים ל-NULL מחזיר את "prefers npm" ישר לתוך live_memory.

מצא את השרשראות השבורות:

sqlite3 memory.db "PRAGMA foreign_key_check;"

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

הכלל שבא לאחר מכן הוא קצר. PRAGMA foreign_keys = ON; הוא הגדרה לכל חיבור, לכן כל חיבור זקוק לו: היישום שלך, סקריפט הניקוי שלך, וסשן ה-sqlite3 שבו אתה מקליד. שים אותו כשורה הראשונה בכל קובץ SQL שמוחק משהו.

היכן הזיכרונות שלכם באמת מאוחסנים

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

mem0 הוא דוגמה מייצגת, ומבנה דומה מופיע גם במקומות אחרים. ספריית הקוד הפתוח שלו משתמשת כברירת מחדל ב-Qdrant כמאגר וקטורי ב-/tmp/qdrant בתוך אוסף ששמו mem0, ובנוסף ביומן שינויים ב-SQLite ב-~/.mem0/history.db, שמיקומו נקבע לפי משתנה הסביבה MEM0_DIR. הטבלה history מכילה את memory_id, old_memory, new_memory, event, created_at ו-is_deleted.

עיינו שוב ברשימת העמודות. קובץ ה-SQLite הוא יומן שינויים. הזיכרונות עצמם נמצאים ב-Qdrant, לכן מחיקת שורות מ-history.db מסירה את התיעוד על כך שמשהו השתנה, אך מותירה את הזיכרון זמין לשליפה. מחיקות חייבות להתבצע דרך ה-API (ממשק תכנות יישומים) של הספרייה עצמה כדי ששני המקומות יתעדכנו:

from mem0 import Memory

memory = Memory()
memory.delete(memory_id="mem_123")
memory.delete_all(user_id="alice")

ברירת המחדל /tmp ראויה לאזהרה מיוחדת. בגרסאות Ubuntu 24.10 ומעלה, /tmp הוא tmpfs, כלומר מערכת קבצים השוכנת בזיכרון ה-RAM; לכן, היא מתרוקנת לאחר כל אתחול והמאגר כולו אובד. בדקו את ההגדרה שלכם באמצעות findmnt /tmp. שורה המציגה את tmpfs משמעותה שעליכם להעביר את הנתיב עוד היום:

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"collection_name": "mem0", "path": "/srv/agent/qdrant"},
    }
}
memory = Memory.from_config(config)

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

קריאת המאגר באמצעות sqlite3

התקינו את ה-CLI (ממשק שורת הפקודה) אם הוא חסר, באמצעות sudo apt install -y sqlite3. לאחר מכן, ארבע פקודות יענו על רוב השאלות בנוגע לכל מאגר הנמצא על הדיסק שלכם.

• sqlite3 ~/.mem0/history.db ".tables" מציגה את רשימת הטבלאות. פלט ריק משמעו שפתחתם את הקובץ הלא נכון.
• sqlite3 ~/.mem0/history.db ".schema history" מדפיסה את העמודות המדויקות, וזהו התיעוד האמין היחיד למבנה של מאגר.
• sqlite3 -cmd ".mode line" ~/.mem0/history.db "SELECT * FROM history ORDER BY created_at DESC LIMIT 5;" מציגה את חמשת השינויים האחרונים, שדה אחד בכל שורה, מה ששומר על קריאות כאשר עמודה מכילה פסקה.
• sqlite3 ~/.mem0/history.db "SELECT event, count(*) FROM history GROUP BY event;" מציגה מה המאגר ביצע, ואילו שמות אירועים הספרייה שלכם כותבת בפועל.

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

סקירת עובדות שאינן פגות תוקף

סחיפה (drift) דורשת תור, מגבלה והרגל. התור מורכב מהאישורים הישנים ביותר:

SELECT id, subject, fact, source, confirmed_at
FROM live_memory
WHERE confirmed_at < datetime('now', '-90 days')
ORDER BY confirmed_at
LIMIT 20;

סקירה של עשרים שורות בשבוע היא משימה שמישהו באמת יבצע. סקירה של ארבע מאות שורות היא משימה שאף אחד לא יבצע, מה שישאיר אתכם בנקודת ההתחלה. לכל שורה יש שתי תוצאות אפשריות. בדקו אותה שוב מול ה-source שלה וחתמו עליה:

UPDATE memory SET confirmed_at = datetime('now') WHERE id = 'm_0140';

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

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

ההרגל השני אינו עולה דבר. הכניסו את הגיל לתוך ה-prompt. אם בלוק הזיכרון שה-retriever בונה נושא confirmed 2026-05-02 לצד כל עובדה, המודל יוכל לומר "נכון למאי השתמשת ב-pnpm" במקום לקבוע זאת כעובדה מוחלטת. עובדה ללא תאריך מצורף נקראת על ידי מודל שפה כזמן הווה, בכל פעם מחדש.

הרצת פעולת ה-prune לפי לוח זמנים

פעולת prune שמתבצעת רק כשזוכרים להריץ אותה אינה יעילה. הכניסו את פקודת ה-SQL לתוך /srv/agent/prune.sql:

PRAGMA foreign_keys = ON;

DELETE FROM memory
WHERE expires_at IS NOT NULL AND expires_at <= datetime('now');

DELETE FROM memory
WHERE superseded_by IS NOT NULL
  AND created_at < datetime('now', '-180 days');

שמרו את /etc/systemd/system/memory-prune.service:

[Unit]
Description=Prune expired agent memories

[Service]
Type=oneshot
User=agent
ExecStart=/usr/bin/sqlite3 /srv/agent/memory.db ".read /srv/agent/prune.sql"

והריצו את /etc/systemd/system/memory-prune.timer:

[Unit]
Description=Run the agent memory prune daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now memory-prune.timer
systemctl list-timers memory-prune.timer

הפקודה list-timers אמורה להציג עמודת NEXT עם זמן אמת, ועמודת LAST לאחר ההרצה הראשונה. הפעילו את התהליך ידנית פעם אחת באמצעות sudo systemctl start memory-prune.service, ולאחר מכן קראו את journalctl -u memory-prune.service -n 20. שורה המכילה את Error: database is locked מציינת שהסוכן החזיק ב-write lock בזמן שפעולת ה-prune רצה. הגדירו Write Ahead Logging פעם אחת באמצעות sqlite3 memory.db "PRAGMA journal_mode=WAL;", כדי שקוראים וכותב יחיד יפסיקו לחסום זה את זה, והוסיפו זמן המתנה ל-prune באמצעות sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql".

כל תוכן שהסוכן קורא עלול להפוך להוראה קבועה

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

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

• חלצו זיכרונות מתורות המשתמש בלבד, לעולם לא מפלט של כלים. פעולה זו מסירה את כל סוג הבעיה הזו, במחיר מסוים של נוחות.
• דרשו source בכל שורה והציגו זאת במהלך סקירה. עובדה שמקורה ב"דף אינטרנט שנטען במהלך משימה 41" היא עובדה שיש לקרוא פעמיים.
• שלחו במייל או תעדו את השורות החדשות מדי יום, עם SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day'); באותו טיימר.
• הרחיקו אישורים (credentials) מהמאגר לחלוטין, נושא המכוסה ב-שמירה על סודות מחוץ לסוכן AI.

נקודה טכנית אחת שייכת גם לכאן. מחיקת שורה אינה מוחקת אותה מהקובץ, כיוון ש-SQLite מסמן את הדף כפנוי ומשתמש בו שוב מאוחר יותר, כך שהטקסט הישן עדיין קריא באמצעות strings memory.db עד שמשהו דורס אותו. הריצו sqlite3 memory.db "VACUUM;" לאחר הסרת כל מידע רגיש, פעולה המכתבת את הקובץ כולו. PRAGMA secure_delete = ON; גורם לחיבור שמבצע את המחיקה לדרוס את התוכן שהתפנה באפסים תוך כדי עבודה.

מה לגבות ובאיזה סדר

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

sqlite3 /srv/agent/memory.db "VACUUM INTO '/srv/backup/memory-$(date +%F).db'"
sqlite3 /srv/backup/memory-$(date +%F).db "PRAGMA integrity_check;"

integrity_check הדפסת ok היא ההוכחה היחידה לכך שקובץ הגיבוי שמיש. כל תוצאה אחרת משמעותה שיש לשמור את הגיבוי הקודם ולבצע בדיקה לפני דריסתו.

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

FAQ

לכמה זמן יש לשמור זיכרון של סוכן לפני שהוא פג תוקף?

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

האם ניתן לזהות אוטומטית מתי עובדה מאוחסנת הפכה לשגויה?

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

מחקתי זיכרון והוא חזר. מדוע?

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

האם בטוח לערוך את מסד הנתונים של הזיכרון ידנית בזמן שהסוכן רץ?

קריאות הן בטוחות. כתיבות בטוחות רק במצב write ahead logging, וגם אז – כותב אחד בלבד בכל פעם. הריצו את sqlite3 memory.db "PRAGMA journal_mode;" כדי לראות באיזה מצב אתם נמצאים, ו-wal היא התשובה הרצויה. אם אתם רואים Error: database is locked, תהליך אחר מחזיק בנעילת הכתיבה; לכן, הגדירו המתנה לסשן שלכם עם sqlite3 -cmd ".timeout 5000" או עצרו תחילה את שירות הסוכן. עריכה ידנית של מאגר וקטורי היא עניין אחר: השאירו זאת לספרייה, כיוון שה-embedding והטקסט חייבים להישאר עקביים זה עם זה.