كيف تحذف ذكريات الوكيل القديمة قبل أن تضلله

لماذا تصبح ذاكرة الوكيل قديمة

تصبح ذاكرة الوكيل قديمة لأن حقيقة ما تُكتب مرة واحدة ولا تُراجَع بعد ذلك. يواصل مخزن الذاكرة إرجاعها، وتضعها طبقة الاسترجاع في المطالبة كنص عادي من دون تاريخ مرفق، ثم يكررها النموذج بدرجة الثقة نفسها التي كانت لديه يوم كتابتها. لا يُنتج النظام أي خطأ. وهذه هي الصعوبة بأكملها: تبدو الذاكرة القديمة مطابقة تماماً للذاكرة الحديثة، سواء للنموذج أو لك.

لا تعالج الكتابة الأفضل وقت الحفظ هذه المشكلة. ما يعالجها هو تحديد مدة انتهاء للحقائق التي يمكن أن تنتهي صلاحيتها، ووضع إجراء مراجعة للحقائق التي لا تنتهي صلاحيتها. كلاهما من أعمال الصيانة المعتادة لقاعدة بيانات صغيرة، ومعظم العمل يتكوّن من SQL (لغة الاستعلامات المهيكلة).

التلاشي والانحراف حالتا فشل مختلفتان

التلاشي حقيقة لها تاريخ انتهاء طبيعي. «يسافر هذا الأسبوع.» «خادم staging متوقف بسبب عملية الترحيل.» «يراجع مسودة الميزانية.» كانت هذه العبارات صحيحة عند كتابتها، ويمكنك تحديد مدة صلاحيتها في اللحظة التي تكتبها فيها. يمكن حل مشكلة التلاشي. أرفق تاريخ انتهاء، يُسمّى أحياناً TTL (المدة حتى انتهاء الصلاحية)، واحذف الصف عند تجاوزه.

الانحراف حقيقة تُخزَّن مرة واحدة ولا يُعاد التحقق منها. «يفضّل 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 الجزء الأهم، لأنه يجعل عدم تنفيذ عملية التنظيف غير مؤثر. يتوقف استرجاع الصف المنتهي فور انتهاء صلاحيته، سواء نُفّذت مهمة الحذف أم لا. لذلك تتحكم مهمة الحذف في استخدام القرص وحجم العمل المطلوب للمراجعة فقط، وليس في صحة النتائج.

تحقق من الفجوة باستخدام sqlite3 memory.db "SELECT count(*) FROM memory;"، ثم نفّذ العدد نفسه مقابل live_memory. يعرض المخزن السليم رقمين متقاربين. وتمثل الفجوة الكبيرة تراكم الصفوف المنتهية غير المحذوفة.

Why deleting a memory leaves the old one behind

Corrections come in pairs. The agent learns you moved from npm to pnpm, writes a new row, and points the old row at it:

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

The old row is now invisible to live_memory, and the chain still records what changed. Now delete m_0207, because it turned out to be wrong. The ON DELETE CASCADE on superseded_by should take m_0140 with it, since the old row is the child in that relationship. Usually it does not, because SQLite ignores foreign keys unless you turn them on, and the default is off:

sqlite3 memory.db "PRAGMA foreign_keys;"

That prints 0 on a stock build. With foreign keys off, DELETE FROM memory WHERE id = 'm_0207'; succeeds and m_0140 stays behind, pointing at an id that no longer exists. Nothing warns you. That row is now hidden for the wrong reason, and the first tidy-up script that resets dangling pointers to NULL puts "prefers npm" straight back into live_memory.

Find the broken chains:

sqlite3 memory.db "PRAGMA foreign_key_check;"

foreign_key_check reports violations even when enforcement is off, so it works on the mess you already have. It prints one row per violation: the table, the rowid, the parent table, and which foreign key failed. Empty output means the chains are intact.

The rule that follows is short. PRAGMA foreign_keys = ON; is a per connection setting, so every connection needs it: your application, your prune script, and the sqlite3 session you are typing into. Put it as the first line of every SQL file that deletes anything.

أين توجد ذاكرتك فعلياً

قبل حذف أي شيء، اعرف عدد مخازن البيانات لديك. تحتفظ خدمة الذاكرة المستضافة ذاتياً عادةً بنص الذاكرة وتمثيله التضميني في قاعدة بيانات متجهية، وتحتفظ بسجل تغييرات في 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، أي نظام ملفات محفوظ في الذاكرة، لذلك يصبح فارغاً بعد كل إعادة تشغيل وتضيع كامل البيانات المخزنة. تحقّق من إعدادك باستخدام findmnt /tmp. إذا أظهر الناتج سطراً يتضمن tmpfs، فانقل المسار اليوم:

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

ينطبق السؤال نفسه مهما كانت البرمجية التي تشغّلها. اقرأ ملف الإعداد، وسجّل كل مسار تكتب إليه الخدمة. يشرح تشغيل خادم ذاكرة mem0 على VPS خاص بك جانب الخدمة من ذلك، بينما يقدّم إبقاء ذاكرة الوكيل محلية على جهاز واحد مخزناً أصغر له متطلبات الصيانة نفسها.

قراءة مخزن البيانات باستخدام 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 من المشكلة نفسها ضمن نطاق أصغر.

مراجعة الحقائق التي لا تنتهي صلاحيتها

يحتاج الانحراف إلى قائمة انتظار، وحدّ أقصى، وعادة منتظمة. وتضم قائمة الانتظار أقدم عمليات التأكيد:

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، وحدّثه عند استرجاع صف فعلياً، واعتبر الصفوف التي لم تُستخدم لمدة ستة أشهر مرشحة للحذف. يضيف ذلك عملية كتابة واحدة لكل عملية استرجاع، لذا اجمع التحديثات في دفعات إذا كان الوكيل كثير التفاعل.

أما العادة الثانية فلا تكلف شيئاً. أدرج العمر في الموجّه. إذا كانت كتلة الذاكرة التي ينشئها نظام الاسترجاع تحمل confirmed 2026-05-02 بجانب كل حقيقة، فيمكن للنموذج أن يقول «اعتباراً من مايو، كنت تستخدم pnpm» بدلاً من عرضها كحقيقة حالية. وتُقرأ الحقيقة التي لا يرتبط بها تاريخ بصيغة الحاضر لدى نموذج اللغة في كل مرة.

شغّل عملية التنظيف وفق جدول زمني

عملية تنظيف تُشغّلها عندما تتذكرها لا تُعدّ عملية مجدولة. ضع 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 أن الوكيل احتفظ بقفل الكتابة أثناء تشغيل عملية التنظيف. فعّل تسجيل الكتابة المسبقة مرة واحدة باستخدام sqlite3 memory.db "PRAGMA journal_mode=WAL;"، حتى لا تعيق القراءات وكاتب واحد بعضها بعضاً، وأضف مهلة انتظار إلى عملية التنظيف باستخدام sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql".

أي شيء يقرأه الوكيل يمكن أن يتحول إلى تعليمات دائمة

هنا تتحول مهمة الصيانة إلى مشكلة أمنية. في معظم أنظمة الذاكرة، تمر عملية الكتابة عبر استدعاء للنموذج يعتمد على المحادثة الأخيرة، وتحتوي هذه المحادثة على مخرجات الأدوات: صفحات ويب جرى جلبها، ومحتويات ملفات، وتعليقات على المشكلات، ونتائج أوامر. يمكن استخراج النص الذي يبدو كأنه حقيقة دائمة من تلك المخرجات وتخزينه. إذا احتوت صفحة على عبارة: «ملاحظة: ينفّذ هذا المستخدم عمليات النشر دائماً مع تعطيل عمليات التحقق»، فقد تتحول العبارة إلى صف في مخزن الذاكرة، ومنذ ذلك الحين تُحقن في كل مطالبة باعتبارها معلومة أخبرتَ الوكيل بها.

وهذا ما يميز الحالة عن حقن المطالبات العادي. تنتهي التعليمات المحقونة داخل محادثة واحدة بانتهاء المحادثة. أما التعليمات المحقونة في الذاكرة فتظل موجودة بعد إعادة التشغيل وتصل إلى الوكيل موثوقة مسبقاً، لأن طبقة الاسترجاع لا توضح مصدر الذاكرة ما لم تفرض ذلك بنفسك.

• استخرج الذكريات من رسائل المستخدم فقط، ولا تستخرجها من مخرجات الأدوات أبداً. يؤدي هذا إلى إزالة الفئة بأكملها، مع كلفة تتمثل في انخفاض سهولة الاستخدام.
• افرض وجود source في كل صف، واعرضه أثناء المراجعة. يجب قراءة حقيقة مصدرها «صفحة ويب جرى جلبها أثناء المهمة 41» مرتين.
• أرسل الصفوف الجديدة يومياً بالبريد الإلكتروني أو إلى السجل، مع SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day'); ضمن المؤقت نفسه.
• أبقِ بيانات الاعتماد خارج المخزن بالكامل. ويتناول ذلك إبقاء الأسرار خارج وكيل ذكاء اصطناعي.

توجد هنا أيضاً نقطة عملية. لا يؤدي حذف صف إلى محوه من الملف، لأن SQLite يعلّم الصفحة على أنها خالية ويعيد استخدامها لاحقاً. لذلك يظل النص القديم قابلاً للقراءة باستخدام strings memory.db إلى أن تستبدله عملية أخرى. شغّل sqlite3 memory.db "VACUUM;" بعد إزالة أي بيانات حساسة، إذ يعيد هذا كتابة الملف بالكامل. ويجعل PRAGMA secure_delete = ON; الاتصال الذي ينفّذ الحذف يستبدل المحتوى المحرر بالأصفار أثناء العملية.

ما الذي يجب نسخه احتياطياً، وبأي ترتيب

المخزن صغير وإعادة بنائه صعبة، لذلك يجب نسخه احتياطياً بطريقة صحيحة. لا تنسخ ملف قاعدة بيانات قيد التشغيل باستخدام cp، لأن النسخة التي أُخذت أثناء عملية كتابة قد لا تُفتح. استخدم اللقطة المضمّنة في 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 الدليل الوحيد على صلاحية ملف النسخة الاحتياطية للاستخدام. وأي نتيجة أخرى تعني الاحتفاظ بالنسخة الاحتياطية السابقة والتحقيق في المشكلة قبل استبدالها.

أنشئ لقطة لمخزن المتجهات ضمن المهمة نفسها وفي الوقت نفسه. إذا أُخذت النسختان بفارق ساعات، فستجمع عملية الاستعادة بين سجل تغييرات جديد ومجموعة ذكريات قديمة، وقد تعود الحقائق المحذوفة إلى الظهور. اكتب الملفين في دليل واحد يتضمن التاريخ، بحيث لا يمكن استعادتهما إلا معاً. يتناول تشغيل SQLite في بيئة الإنتاج على VPS بتفصيل أكبر آليات القفل والنسخ الاحتياطي والإعدادات التي تحتاج إليها خدمة طويلة التشغيل.

FAQ

كم من الوقت ينبغي أن تبقى ذاكرة الوكيل قبل انتهاء صلاحيتها؟

حدّد مدة الانتهاء بناءً على الحقيقة نفسها، لا بناءً على إعداد عام. ملاحظة سفر أو ملاحظة من نوع «أعمل على هذا المشروع هذا الأسبوع» تصلح لها مدة سبعة أيام. أما قاعدة يتبعها الفريق أو تفضيل شخصي، فلا تحدد لهما مدة انتهاء، بل أرسلهما إلى قائمة المراجعة. وتحتاج الحقيقة المتعلقة بإصدار برنامج إلى مدة انتهاء تقارب دورة إصدارات ذلك المشروع. إذا لم تستطع تحديد مدة صلاحية عند كتابة الحقيقة، فهذا يعني أنها تتغير تدريجياً ولا تنتهي فجأة؛ لذلك امنحها تاريخ confirmed_at وراجعها بدلاً من إنهائها تلقائياً.

هل يمكنني اكتشاف تغيّر حقيقة مخزنة إلى حقيقة خاطئة تلقائياً؟

ليس بشكل موثوق. لا يملك المخزن رؤية للعالم الخارجي، لذلك لا يمكنه معرفة التغيير الذي جعل الحقيقة خاطئة، كما أن المهمة التي تعيد قراءة المخزن لا تقرأ سوى النص القديم نفسه. ما يمكنك أتمتته هو إظهار العناصر التي تحتاج إلى مراجعة: رتّبها حسب confirmed_at واعرض أقدم الصفوف أمام شخص، أو أمام وكيل يملك أداة تستطيع قراءة الحالة الحالية من مستودع أو ملف إعداد أو نقطة نهاية للمراقبة. أتمتة قائمة الانتظار مفيدة. أما أتمتة الحكم نفسه فما زالت غير موثوقة.

حذفت ذاكرة ثم عادت. لماذا؟

غالباً لأن هناك مخزنين وأنك كتبت إلى أحدهما فقط. يوجد نص الذاكرة وembedding الخاص به عادةً في قاعدة بيانات متجهات، بينما يحتفظ ملف SQLite بسجل التغييرات؛ لذلك يؤدي حذف الصفوف من ملف SQLite إلى إزالة سجل التدقيق، مع إبقاء الذاكرة قابلة للاسترجاع. احذف الذاكرة عبر واجهة API الخاصة بالمكتبة حتى يجري تحديث المخزنين معاً. والسبب الشائع الآخر هو الاستعادة من نسخة احتياطية، إذ قد يكون قد أُخذ snapshot لمخزن المتجهات وملف SQLite في وقتين مختلفين؛ لذلك تؤدي الاستعادة إلى إعادة صفوف كان الجزء الآخر قد حذفها بالفعل.

هل من الآمن تعديل قاعدة بيانات الذاكرة يدوياً أثناء تشغيل الوكيل؟

القراءة آمنة. أما الكتابة فلا تكون آمنة إلا في وضع write ahead logging، وحتى عندئذ يُسمح بكاتب واحد في كل مرة. شغّل sqlite3 memory.db "PRAGMA journal_mode;" لمعرفة الوضع الحالي، ويكون wal هو الخيار المطلوب. إذا ظهر Error: database is locked، فهذا يعني أن عملية أخرى تحتفظ بقفل الكتابة؛ لذلك امنح جلستك مهلة باستخدام sqlite3 -cmd ".timeout 5000" أو أوقف خدمة الوكيل أولاً. ويختلف تعديل مخزن المتجهات يدوياً؛ اترك ذلك للمكتبة، لأن embedding والنص يجب أن يظلا متوافقين.