كنت أعمل على شيء يسمى **[Neotoma](/posts/truth-layer-agent-memory)**.[^1]

لا يوجد شيء لتجربته بعد. هذه ليست مشاركة إطلاق، وأنا لا أعلن عن منتج أو أطلب الاشتراك. لقد أزعجتني المشكلة لفترة من الوقت، والأهم من ذلك أنها كانت تعيق العمل الذي كنت أحاول القيام به.

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

لم يكن هذا القيد نظريًا فقط. لقد كان مانعًا عمليًا للأتمتة.

## تعمل أنظمة الذكاء الاصطناعي على تغيير الأدوار بهدوء

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

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

والدولة لديها متطلبات مختلفة.

## الشيء الذي يستمر في الانكسار ليس الذكاء، بل الثقة

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

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

وهذا أمر مقبول عندما يكون الذكاء الاصطناعي استشاريًا ولكن ليس عندما يكون عمليًا.

## جزء من المشكلة هو عدم تطابق الفئة

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

هذه ليست مشكلة تجربة المستخدم. إنها مشكلة أنظمة.

## ما يبدو مفقودًا هو بدائي أساسي

حالة شخصية صريحة وقابلة للفحص وقابلة لإعادة التشغيل.

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

وكلاء تغيير هذا الافتراض.

## النتيجة غير المريحة هي أن القيام بذلك بشكل صحيح يزيد الاحتكاك

لا يمكن أن تكون تغييرات الحالة ضمنية.

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

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

لا يوجد طريق مختصر حول هذه المقايضة. تسير أنظمة الراحة أولاً والأنظمة الآمنة للوكلاء في اتجاهين متعاكسين.

## أتعامل مع البيانات الشخصية بنفس الطريقة التي تتعامل بها أنظمة الإنتاج مع الدولة

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

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

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

تأتي الذاكرة من كل من المستندات التي تقوم بتحميلها ويكتبها وكلاء البيانات أثناء المحادثات، وهو رسم بياني منظم يوحد الكيانات والأحداث حتى يتمكن الوكلاء من التفكير في كل ذلك.

هذه ليست تفضيلات جمالية. إنهم يفشلون بشكل مباشر في أتمتة سير العمل الحقيقي دون فقدان الثقة في النظام الذي يقوم بالعمل، ثم يفشلون بشكل متكرر.

## لماذا أصممه بهذه الطريقة

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

أنا أيضًا أصنعه عبر الأنظمة الأساسية والخصوصية أولاً حسب التصميم. إنه يعمل مع ChatGPT وClaude وCursor عبر MCP، وليس مقيدًا بمزود واحد. تظل بياناتك ملكًا لك، ويتحكم فيها المستخدم، ولا يتم استخدامها مطلقًا للتدريب. هذه ليست وسائل الراحة. إنها متطلبات أساسية للثقة.

## ما ليس كذلك

إنه ليس تطبيقًا لتدوين الملاحظات أو "عقلًا ثانيًا"؛ إنها ركيزة ذاكرة منظمة للعملاء.

إنها ليست ذاكرة ChatGPT أو مشاريع Claude التي يتحكم فيها الموفر؛ إنها الركيزة الخاصة بك، والتي تم كشفها عبر MCP حتى يتمكن أي وكيل من استخدامها.

إنه ليس مخزنًا متجهًا أو طبقة RAG؛ إنها ذاكرة منظمة ذات مخطط أولاً ومصدرها.

إنه ليس وكيلًا مستقلاً أو محرك سير عمل أو مساعد ذكاء اصطناعي بذاكرة غير مرئية؛ إنها عوامل طبقة الذاكرة التي تقرأ وتكتب، وأنت تتحكم فيها.


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

## لماذا الآن

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

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

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

## معاينة المطور القادمة

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

كيف أقترب من البناء: أقوم بتطبيقه أولاً في مجموعة الوكلاء الخاصة بي حتى أتمكن من رؤية أين تساعد الحتمية والمصدر فعليًا وأين يعيقان الطريق. حالات الاستخدام تشمل:

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

إنني أعطي الأولوية لاستقرار MCP والحد الأدنى من واجهة سطر الأوامر (CLI) قبل إضافة المزيد من مساحة السطح وكيان اختبار الضغط وحل العلاقات واستعلامات الجدول الزمني كمقاييس للاستخدام.

إذا كان لهذا الإطار صدى، فإن العمل يحدث في العلن هنا:
[https://github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma)

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

[^1]: سمي على اسم جنس *Neotoma* (packrats)، المعروف بجمع المواد وحفظها.