## اختيار قاعدة البيانات الذي يتقادم بشكل سيئ

تقوم الشركة ببناء وكيل واحد لدعم العملاء. يقوم بتخزين الملاحظات في قاعدة بيانات، Postgres، Mongo، Redis، مهما كان الفريق الذي يديره بالفعل. وبعد أشهر، قام فريق آخر بإنشاء وكيل صحة الحساب. يقوم شخص ما بربطها لأن الإنسان قد سئم من سياق النسخ واللصق بين الأدوات. يصبح هذا الاتصال، وهو جدول قاعدة بيانات مشترك، حالة مشتركة متعددة الوكلاء عن طريق الصدفة.

يتشارك ثلاثة وكلاء الآن الحالة المتعلقة بحسابات العملاء: الدعم الوارد، وتسجيل الصحة، وتوصيات التجديد.

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

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

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

## لماذا تخفي أنظمة الوكيل الفردي المشكلة

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

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

## ما الذي يتغير مع تعدد الوكلاء؟

عندما يكتب العميل "أ" الملاحظات التي يقرأها العميل "ب" ويتصرف بناءً عليها، تظهر طوبولوجيا فشل مختلفة.

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

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

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

##المراحل الأربع

الصناعة تتحرك من خلال قوس يمكن التنبؤ به.

### 1. "فقط استخدم Postgres" (أو [استخدم فقط ملف تخفيض السعر](/posts/the-markdown-memory-ceiling))

يستخدم كل من Manus وClaude Code وOpenClaw ملفات نصية عادية للذاكرة. التطور المتقارب، وليس قواعد اللعبة المشتركة. عندما يصل فريق إلى قاعدة بيانات، يتم تثبيت الذاكرة على كل ما هو موجود بالفعل: RAG عبر Postgres باستخدام pgvector، وRedis لحالة الجلسة، والتضمينات في Pinecone. يعمل كلا المسارين لحالات الاستخدام البسيطة. النموذج العقلي هو أن الوكلاء يحتاجون إلى تذكر الأشياء، أو تخزين الملفات أو قواعد البيانات، وحل المشكلة.

### 2. تحسين الاسترجاع

تقبل منتجات مثل Mem0 وZep وMemPalace أن الوكلاء يحتاجون إلى تجريد مخصص للذاكرة، ولكنهم يضعون المشكلة في إطار جودة الاسترجاع. كيفية إدخال السياق الصحيح في الموجه في الوقت المناسب. يؤدي هذا إلى حل مشكلة قد يشعر بها المطورون بالفعل: استدعاء سيء، ونوافذ السياق المتضخمة، وعمليات الاسترجاع غير ذات الصلة. لكن هذه المرحلة تترك مسار الكتابة غير مدقق. مهما كانت مقتطفات LLM يتم التعامل معها على أنها حقيقة أساسية.

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

### 3. أزمة الثقة

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

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

### 4. التشعب

انقسامات الصناعة. المسار أ: تضيف قواعد البيانات الموجودة العناصر الأولية الوكيلة. يحصل Postgres على امتدادات لتسجيل المراقبة وحل الكيان. يقوم Supabase أو PlanetScale بشحن طبقة منتج "ذاكرة الوكيل". وهذا يجسد العديد من حالات الاستخدام حيث تكون متطلبات الثقة معتدلة.

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

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

تكامل الكتابة ليس ميزة أمان يتم تثبيتها بعد حدوثها. إنه الأساس الذي يجعل التشغيل المستقل ممكنًا.

## كيف سيتم بناء الأنظمة متعددة الوكلاء فعليًا

لن يتم تصميم معظمها كأنظمة متعددة الوكلاء. سوف تتراكم.

**التبادل والتحدث مع محور بشري** هو النمط السائد حاليًا. يواجه أحد الوكلاء الأساسيين المستخدم ويفوض المهام الفرعية إلى وكلاء متخصصين. الحالة المشتركة هي نافذة سياق الوكيل الأساسي. مخاطر سلامة الكتابة منخفضة. لكن هذه الهيكلية لها سقف صعب: حيث يعاني وكيل المحور من اختناقات ولا يمكنه الحفاظ على السياق عبر مسارات العمل طويلة الأمد. يؤدي هذا إلى تعيين المرحلتين 1 و2: "فقط استخدم Postgres" أو أن طبقة الاسترداد تعمل بشكل جيد لأن وكيلًا واحدًا يتحكم في الحالة.

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

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

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

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

## سطح التكامل المهم

ربما لا تكون البنية الفائزة هي "استبدال قاعدة البيانات الخاصة بك" ولكن "الجلوس بين وكلائك وقاعدة البيانات الخاصة بك".

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

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

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

## ما أقوم ببنائه

هذا ما يفعله [Neotoma](https://github.com/markmhendrickson/neotoma). إلحاق الملاحظات فقط. المصدر المرتبط بالتجزئة. يكتب مقيد بالمخطط. قرار الكيان الحتمي. كل ملاحظة يكتبها الوكيل يمكن تتبعها وتدقيقها ومتسقة منذ اليوم الأول.

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

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