موضع واحد يُحسم فيه الأمر بشأن الحقيقة السارية

عندما يعمل عدة وكلاء انطلاقًا من الحقائق نفسها، تتغير تلك الحقائق ولا يعلم الوكلاء جميعًا بالتغيير في الوقت نفسه. ويوضح موعد استحقاق الدفع المشكلة بجلاء.

لنفترض أن الفاتورة INV-2041 تنص على أن الدفع مستحق في 22 أكتوبر، ثم نقلت رسالة بريد إلكتروني لاحقة من المورد الموعد إلى 29 أكتوبر. يقرأ وكيل الفاتورة، ويقرأ آخر الرسالة، ويجهز ثالث مدفوعات الأسبوع اعتمادًا على ما يجده. يجيب الأول «22 أكتوبر»، والثاني «29 أكتوبر»، أما الثالث فيجيب بالتاريخ الذي عثر عليه أولًا. لا يوجد في هذا الترتيب ما يحدد التاريخ المعتمد، لذا يتعين على الشخص الذي يدير الوكلاء أن يتحقق بنفسه.

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

الاسترجاع مفيد لمهمة أخرى

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

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

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

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

ما يفعله Neotoma اليوم

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

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

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

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

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

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

لنعد إلى الفاتورة. تقع كتابتا الوكيلين في كيان واحد. ويظهر موعد الاستحقاق الآن 29 أكتوبر، مع الإشارة إلى المشاهدة القادمة من الرسالة. ولا يزال المبلغ يشير إلى المشاهدة الأولى، لأنه لم يتغير. يقرأ وكيل المدفوعات 29 أكتوبر، وتبقى مشاهدة 22 أكتوبر مدرجة مع مصدرها.

يصل الوكلاء إلى Neotoma عبر خادم MCP وواجهة REST API وواجهة سطر الأوامر. ويشرح دليل التثبيت كيفية توصيل الأدوات وبيئات التشغيل المدعومة. وجّه كل أداة إلى المثيل وملف البيانات نفسيهما، أو إلى مدخل MCP نفسه، لتشارك السجلات؛ وقد تستخدم المداخل المنفصلة قواعد بيانات منفصلة.

ويستطيع الناس فحص سجلاتهم في تطبيق Neotoma المرفق.

يمكن أن يثبت طلب موقّع مقبول هوية وكيل موثَّقة. وتحدد المنح النشطة المحددة النطاق الإجراءات المسموح بها؛ فالتوقيع وحده ليس إذنًا.

إلى أين يتجه الأمر

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

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

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

وترد الرؤية الكاملة، مع حالة كل جزء منها اليوم، في README.

نظام سجل، لا مجرد استرجاع

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

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

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

استخدم خيار الإعداد المناسب لأداتك أو بيئة تشغيلك؛ ويغطي دليل التثبيت التكاملات المدعومة الأخرى. ثم احفظ حقائق سير العمل وكياناته المترابطة من وكيل واحد، واقرأها من وكيل آخر متصل بالمثيل المعدّ نفسه وملف البيانات أو مدخل MCP نفسه.

دليل التثبيت في neotoma.io/install. وتوجد الشيفرة ومتعقب المشكلات على GitHub في github.com/markmhendrickson/neotoma.