تحتاج مراكز قيادة العملاء إلى مصدر واحد للحقيقة

كتب باول جوزيفياك مؤخرًا عن تشغيل وكيل شخصي للذكاء الاصطناعي والأدوات التي صممها لإدارته. انتقل من Notion إلى Obsidian إلى لوحة مخصصة مدعومة بـ SQLite، ثم إلى تطبيق SwiftUI الأصلي مع وضع التركيز وإمكانية رؤية شريط القوائم.

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

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

##الفجوة التي وصفها

كانت خيارات Jozefiak إما عامة للغاية (Trello، Linear) أو تقنية للغاية (terminal، JSON). اللوحات العامة لا تعرف حالة الوكيل. من ادعى ماذا؟ هل الوكيل يعمل أم ينتظر المراجعة؟ كيف يتم تسجيل الإكمال بحيث لا يقوم الوكيل بتشغيل نفس المهمة مرتين؟ لا تمنحك السجلات الأولية وJSON لوحة على الإطلاق.

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

ما توفره طبقة الحقيقة

يقوم Neotoma بتخزين الكيانات والملاحظات والعلاقات المكتوبة. إنه يعرضهم عبر MCP بحيث يمكن لأي وكيل (Claude Code، Cursor، عداء مجدول) تخزين الحالة وتصحيحها. إن العجز والمعرفات الحتمية مدمجة.

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

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

المكان المناسب للذاكرة المكونة من ست طبقات

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

Neotoma لا يقوم بالضغط أو التلخيص. إنه المتجر المتين والمنظم الذي تقرأ منه الطبقات وتكتب إليه. قد تكون الذاكرة العاملة "آخر ملاحظات N" أو "الكيانات التي تم لمسها خلال الـ 48 ساعة الماضية." قد يؤدي التمرير الأسبوعي إلى كتابة ملاحظات جديدة (ملخصات، فهارس) مرة أخرى إلى Neotoma. قد يتم تشغيل البحث الدلالي على نفس الرسم البياني للكيان. الحدود واضحة: الورم النيوتوما هو طبقة الحقيقة؛ تقوم الطبقات الموجودة فوقها بتنفيذ سياسة الاحتفاظ واستراتيجية الاسترجاع.

لماذا هذا مهم للبناة

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

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

كيف يتناسب هذا مع الاتجاهات التي أراهن عليها

في [ستة اتجاهات فاعلة كتبت عنها مؤخرًا] (/posts/six-agentic-trends-betting-on)، زعمت أن الوكلاء سوف يصبحون فاعلين اقتصاديين، وأن الأخطاء سوف تصبح مرئية اقتصاديًا، وأن تجزئة الأداة سوف تستمر، وأن الاستخدام سوف يكون قابلاً للقياس. وتقع فجوة مركز القيادة التي ضربها جوزيفياك عند تقاطع تلك الضغوط.

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

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

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