بنية ذاكرة وكلاء الذكاء الاصطناعي: الأنواع الأربعة على Postgres

بنية ذاكرة وكلاء الذكاء الاصطناعي (AI Agent Memory Architecture) هي تصميم الطريقة التي يخزّن بها الوكيل ما يتعلمه ويحدّثه ويستدعيه — عبر الخطوات والجلسات والمستخدمين — بدلًا من نسيان كل شيء لحظة انتهاء نافذة السياق. المخطط الذي يعتمده معظم الممارسين اليوم يتكون من أربع طبقات: الذاكرة العاملة (Working) والحدثية (Episodic) والدلالية (Semantic) والإجرائية (Procedural). سوق مزدحم من منصات الذاكرة يريدك أن تصدق أن هذا يتطلب بنية تحتية جديدة. الحقيقة غالبًا غير ذلك: الطبقات الأربع كلها ترتسم بوضوح على PostgreSQL العادي مع امتداد pgvector — قاعدة البيانات "المملة" نفسها التي تشغّلها أصلًا. هكذا أشغّل ذاكرة الوكلاء في الإنتاج فعليًا، وهذه المقالة تشرح الخريطة الكاملة مع SQL الفعلي، والحالات الصادقة التي يستحق فيها إطار الذاكرة مكانه.

الذاكرة ليست RAG

أغلى خطأ في بناء الوكلاء حاليًا هو التعامل مع الذاكرة كأنها "RAG باسم مختلف". الفرق يكمن في المحور الوحيد المهم:

• RAG مسار قراءة عديم الحالة فوق مستندات قمت بفهرستها. محتواه دالة في مستنداتك. بعد ألف محادثة يبقى المخزن كما هو بايتًا ببايت.
• الذاكرة مسار قراءة وكتابة ذو حالة فوق ما تعلمه الوكيل نفسه. محتواها دالة في تاريخ الوكيل. وكيلان بنفس المستندات وتاريخين مختلفين يجيبان إجابتين مختلفتين.

الاختصار الذي أستخدمه: RAG يجيب عن "ماذا تقول المستندات؟" — الذاكرة تجيب عن "ماذا تعلّم هذا الوكيل، ومتى توقف ذلك عن كونه صحيحًا؟" الشطر الثاني هو ما لا يمنحك إياه البحث بالتشابه وحده: الحقائق تنتهي صلاحيتها. "العميل على خطة Starter" تتوقف عن كونها صحيحة يوم يرقّي خطته، وفهرس المتجهات لا يملك مفهومًا أصيلًا لـ"لم يعد صحيحًا" — مخططك هو من يجب أن يحمله.

النتيجة العملية: بما أن الفرق هو مسار الكتابة والزمن — لا محرك التخزين — فإن نسخة Postgres نفسها تخدم الاثنين معًا. جداول RAG تُعاد فهرستها من المستندات المصدر (كما في مقالتي عن حزمة RAG)، بينما جداول الذاكرة يعدّلها الوكيل داخل معاملات (Transactions).

الأنواع الأربعة لذاكرة الوكلاء

التصنيف الذي يستخدمه الجميع الآن يعود إلى ورقة CoALA عام 2023 ("Cognitive Architectures for Language Agents")، التي استعارته بدورها من خمسين عامًا من علم النفس المعرفي: تمييز Tulving بين الحدثي والدلالي (1972)، وفصل الإجرائي عن التقريري في بنى مثل Soar وACT-R. كل الأطر التجارية — Mem0 وZep وLetta وLangMem — تتحدث بهذه المفردات. إليك كل نوع، وبناء Postgres الذي ينفذه.

1. الذاكرة العاملة — المسوّدة

الخيط الحي: الرسائل الحالية ونتائج الأدوات والخطط الجزئية. تتغير مع كل خطوة وتُضغَط أو تُهمَل حين تمتلئ نافذة السياق. في Postgres هذه نقاط حفظ على مستوى الخيط:

CREATE TABLE thread_state (
  thread_id  uuid,
  step       int,
  state      jsonb,
  created_at timestamptz DEFAULT now(),
  PRIMARY KEY (thread_id, step)
);

إن كنت تستخدم LangGraph فلن تكتب هذا الجدول أصلًا — PostgresSaver يحفظ كل خطوة في قاعدة بياناتك، وهو ما يمنحك الاستئناف وإعادة التشغيل وتدخل الإنسان مجانًا.

2. الذاكرة الحدثية — اليوميات

ما حدث ومتى: كل تفاعل، بطابع زمني، إلحاقي فقط. الحلقات القديمة تُلخَّص كي لا يُعاد تشغيل السجل كاملًا أبدًا:

CREATE TABLE events (
  id        bigserial PRIMARY KEY,
  thread_id uuid,
  user_id   uuid,
  role      text,
  content   text,
  embedding vector(512),
  ts        timestamptz DEFAULT now()
);
CREATE INDEX ON events USING hnsw (embedding vector_cosine_ops);

الاسترجاع = حداثة × تشابه: نافذة WHERE ts > … مع بحث أقرب الجيران عبر pgvector، ومهمة خلفية تلخص الحلقات المغلقة في جدول summaries بمتجهاته الخاصة.

3. الذاكرة الدلالية — الحقائق

معرفة مقطّرة بعيدًا عن أي محادثة بعينها: تفضيلات وكيانات وحقائق مجال. الشرط الحاسم هو الإحلال (Supersedence) — الحقائق الجديدة يجب أن تحدّث القديمة أو تبطلها، لا أن تتراكم فوقها:

CREATE TABLE memories (
  id             uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id        uuid,
  namespace      text,
  content        text,
  embedding      vector(512),
  valid_from     timestamptz DEFAULT now(),
  invalidated_at timestamptz,
  superseded_by  uuid
);
CREATE INDEX ON memories USING hnsw (embedding vector_cosine_ops)
  WHERE invalidated_at IS NULL;

مسار الكتابة: نموذج لغوي يستخرج حقائق مرشحة من سجل الأحداث، يبحث بالتشابه في الصفوف الموجودة، ثم يقرر لكل حقيقة: إضافة أو تحديث أو إبطال أو لا شيء. هذه حلقة ADD/UPDATE/DELETE/NOOP المنشورة لدى Mem0، وتتسع كلها في معاملة واحدة. وثنائية valid_from/invalidated_at هي تقريب Postgres البسيط لنموذج Zep ثنائي الزمن، حيث تحمل الحقائق نوافذ صلاحية بدل أن تُحذف.

4. الذاكرة الإجرائية — العادات

كيفية التصرف: قواعد ("أكّد دائمًا قبل لمس الإنتاج")، مهارات، وتعليمات الوكيل المتطورة. تُحدَّث نادرًا وبقصد، وتُقرأ عند الإقلاع لا مع كل استعلام:

CREATE TABLE instructions (
  agent_id   text,
  name       text,
  version    int,
  content    text,
  active     boolean DEFAULT false,
  updated_at timestamptz DEFAULT now(),
  PRIMARY KEY (agent_id, name, version)
);

الوكيل (أو محسّن خلفي) يكتب صف نسخة جديدة ويقلب active — فتحصل على تطور للتعليمات قابل للمقارنة والتراجع. كتل الذاكرة الشهيرة ذاتية-التحرير في Letta هي تحت الغطاء هذا بالضبط: صفوف في Postgres يعيد الوكيل كتابتها عبر استدعاءات أدوات.

مسار الكتابة هو الجزء الصعب

لاحظ أن لا شيء من التخزين أعلاه صعب. أربعة جداول وفهرسا HNSW وانتهينا. الـ20% الصعبة فعلًا في ذاكرة الوكلاء هي مسار الكتابة: تقرير ما يستحق التذكر (الاستخراج)، ومطابقته مع المعروف سابقًا (إزالة التكرار والإحلال)، وضغط التاريخ دون فقدان التفاصيل الحاملة (التوحيد)، وإسقاط ما لم يعد مهمًا (النسيان). هذه مشكلات تنسيق نماذج لغوية لا مشكلات قواعد بيانات — وهي ما تشتريه فعلًا حين تشتري إطار ذاكرة. مع مخزن pgvector في Mem0 تهبط الصفوف في Postgres الخاص بك على أي حال؛ المنتج هو أوامر مسار الكتابة وتنسيقه.

ثلاثون يومًا صاخبة في عالم الذاكرة

إن شعرت أن موضوع الذاكرة علا صوته فجأة، فهذا صحيح. في الشهر الأخير وحده:

• 4 يونيو — OpenAI أطلقت "Dreaming V3" لـChatGPT: عملية خلفية تُركّب الذكريات وتراجعها بين المحادثات — تحوّل "مسافر إلى سنغافورة في يوليو" إلى "سافر في يوليو" — بدل قائمة ذكريات محفوظة إلحاقية. تقييمات OpenAI الداخلية للاستدعاء الوقائعي قفزت من 41.5% (2024) إلى 82.8% معها.
• 18 يونيو — Perplexity عرضت "Brain": ذاكرة ذاتية-التحسين لوكيلها Computer تبني خريطة سياق لعمل الوكيل (لا للمستخدم) وتنقّحها ليلًا.
• 29 يونيو — Microsoft Research نشرت Memora (مع ورقة في ICML 2026): خزّن الذكريات كاملة، لكن استرجعها عبر تجريدات من 6–8 كلمات مع مراسي استدعاء. تقارير Microsoft: حتى 98% أقل من رموز السياق مقارنة بالاستدلال كامل-السياق.
• 30 يونيو — Harrison Chase نشر مقالته "Wiki Memory" — ليست منتجًا بل نمطًا: ويكي من ملفات يديره الوكيل يضغط البيانات الخام إلى طبقة معرفة دائمة وقابلة للفحص والإصدار، بتركيبٍ محسوب مسبقًا لا مسترجَع كمقاطع خام.
• 10 يوليو — Mem0 نشرت تقرير "State of AI Agent Memory 2026" بأرقام معيارية جديدة لخوارزميتها الموفرة للرموز الصادرة في أبريل، وإحصاء لـ21 تكاملًا مع الأطر.

تحذير صادق قبل اقتباس أي من هذه الأرقام: كلها معلنة ذاتيًا من المورّدين وعلى معايير متنازع عليها. خلافات منهجية LoCoMo بين Mem0 وZep جرت في الاتجاهين — كلٌّ أعاد تسجيل الآخر نزولًا. اقرأ كل معيار ذاكرة كتسويق اتجاهي حتى يحسمه اختبار مستقل. وإن أردت تقييم الذاكرة لوكيلك، قِسها على آثار محادثاتك أنت (أستخدم Ragas لهذا تحديدًا).

لكن النقطة الجوهرية قائمة: الذاكرة تعيش اليوم اللحظة التي عاشتها هندسة السياق قبل عام. إنها تتحول إلى مكوّن أساسي في بنية الوكلاء — ولهذا بالذات يستحق ما تحت المنصات أن تفهمه.

متى يستحق إطار الذاكرة مكانه

• Mem0 — حين تريد خط الاستخراج/التحديث/إزالة التكرار جاهزًا ومصانًا بدل كتابة أوامر ADD/UPDATE/DELETE/NOOP بنفسك. مفتوح المصدر برخصة Apache-2.0، وpgvector مخزن أساسي لديه — فأنت تشتري تنسيق مسار الكتابة لا قاعدة بيانات.
• Zep / Graphiti — حين يكون الاستدلال الزمني على العلاقات هو متطلب المنتج الفعلي ("بماذا كان هذا العميل يعتقد قبل تغيير الخطة؟"). تميّز حقيقي — لكنه يعمل على Neo4j أو FalkorDB أو Kuzu؛ دعم Postgres طلب ميزة مفتوح، أي قاعدة بيانات ثانية عليك تشغيلها.
• Letta — حين تريد وكلاء يديرون ذاكرتهم بأنفسهم (ترقية، توحيد، إعادة كتابة الشخصية) وأنت متبنٍّ منظومته كاملة. ومن المفارقة أن خادم Letta المستضاف ذاتيًا يخزّن كل شيء في… PostgreSQL مع pgvector. أطروحة هذه المقالة، مثبتة من الإطار نفسه.
• Cognee — حين تعني "الذاكرة" عندك فعليًا رسمًا معرفيًا مؤسسًا على أنطولوجيا يُبنى من مستندات (مشكلة على شكل GraphRAG)، لا حالة محادثة.
• PostgresSaver / PostgresStore في LangGraph — إن كنت على LangGraph فهذا ليس إطارًا إضافيًا أصلًا. قصة الذاكرة الرسمية للإطار المرجعي هي حرفيًا "وجّهه إلى Postgres" — والمخزن يجري بحثًا دلاليًا مدعومًا بـpgvector. LangMem يضيف منطق استخراج وتوحيد جاهزًا فوقه، لكنه ما يزال قبل الإصدار 1.0؛ أنا أنسخ أنماطه بدل الاعتماد على واجهته.

القاعدة التي أقدمها للناس: إن كان متطلبك "تذكّر تفضيلات مستخدمِيّ واسترجعها بالتشابه"، فجدول حقائق مع أمر استخراج واحد هو بضع مئات من الأسطر يمكنك قراءتها وفهرستها ونسخها احتياطيًا وتصحيحها عبر psql. الجأ إلى إطار حين يصبح تنسيق مسار الكتابة عنق الزجاجة الحقيقي — لا لأن رسمًا بيانيًا في معيار أخبرك بذلك.

ما أشغّله في الإنتاج

حزمتي لمساعد SaaS متعدد المستأجرين: Postgres + pgvector، متجهات Voyage (voyage-3-lite بـ512 بعدًا)، LangGraph لحلقة الوكيل، وRagas للتقييم. جداول RAG وجداول الذاكرة تعيش في قاعدة البيانات نفسها بمساري كتابة مختلفين — جانب RAG يعيد بناءه مفهرِس، وجانب الذاكرة يعدّله الوكيل. وتعدد المستأجرين بمخطط لكل مستأجر يعني أن الذاكرة تتقسم طبيعيًا لكل عميل، وهو ما يحل بهدوء صنفًا كاملًا من مشكلات "ذاكرة من هذه؟".

ملاحظتان عمليتان عن pgvector نفسه. أولًا، HNSW هو الافتراضي الصحيح لجداول الذاكرة — استدعاء وزمن استجابة أفضل من IVFFlat، بلا خطوة تدريب، ويتحمل الإدراجات المتزايدة التي ينتجها عبء ذاكرة كثيف الكتابة. ثانيًا، أبقِ الامتداد محدّثًا: سلسلة 0.8.x أصلحت استعلامات ANN المفلترة بمسح الفهرس التكراري (0.8.0)، ورقّعت ثغرة تجاوز مخزن في بناء HNSW المتوازي (0.8.2)، وأصلحت حالات تلف HNSW أثناء الـvacuum (0.8.3–0.8.5، الحالي حتى يوليو 2026). جداول الذاكرة تتعرض لـvacuum عنيف بسبب دوران الإحلال، فهذه الإصلاحات ليست نظرية.

الأسئلة الشائعة

ما هي بنية ذاكرة وكلاء الذكاء الاصطناعي؟

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

ما الفرق بين ذاكرة الوكيل وRAG؟

RAG مسار استرجاع للقراءة فقط فوق مستندات فهرستَها؛ مخزنه لا يتغير لمجرد حدوث محادثة. الذاكرة مسار قراءة وكتابة فوق تجربة الوكيل نفسه — يستخرج ويحدّث ويُحل ويَنسى الحقائق عبر الجلسات. إن لم يكتب شيء إلى المخزن أثناء المحادثة، فهو RAG لا ذاكرة.

كيف يتذكر الوكلاء المحادثات السابقة إذا كانت النماذج عديمة الحالة؟

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

ما الأنواع الأربعة للذاكرة في وكلاء الذكاء الاصطناعي؟

العاملة (حالة الخيط الحي)، والحدثية (تاريخ موقوت لما حدث)، والدلالية (حقائق وتفضيلات مقطّرة)، والإجرائية (قواعد ومهارات وتعليمات الوكيل). التصنيف من ورقة CoALA التي كيّفته من علم النفس المعرفي.

هل أحتاج قاعدة متجهات مخصصة لذاكرة الوكيل أم يكفي Postgres؟

للأغلبية الساحقة من وكلاء الإنتاج يكفي Postgres مع pgvector — فهارس HNSW تتعامل مع البحث بالتشابه على نطاق جداول الذاكرة بسهولة، وتحصل على المعاملات والنسخ الاحتياطي وقابلية الرصد بـSQL مجانًا. قاعدة المتجهات المخصصة تصبح مثيرة عند مئات ملايين المتجهات، وهو نطاق لا يبلغه أي عبء ذاكرة تقريبًا.

هل أستخدم Mem0 أو Zep أو Letta — أم أبني ذاكرتي بنفسي؟

ابنِ التخزين بنفسك — إنها أربعة جداول. ثم قرر بصدق إن كنت تحتاج تنسيق مسار الكتابة من إطار: Mem0 للاستخراج/إزالة التكرار الجاهز، Zep للرسوم المعرفية ثنائية الزمن (مع قاعدة رسوم عليك تشغيلها)، Letta للوكلاء ذاتيي الإدارة. وإن كنت على LangGraph أصلًا، فنقاط الحفظ والمخزن على Postgres تغطي الذاكرة العاملة والدلالية قبل أن تضيف أي شيء.

تبني وكيلًا يحتاج أن يتذكر — أو تحاول فصل الذاكرة عن RAG في منتج قائم؟ هذا نوع الأنظمة الذي أصممه وأشحنه. تواصل معي.