techmeat.dev

كيف بنيت OpenSecondBrain

· · 8 دقائق للقراءة

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

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

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

هكذا ظهر مشروع OpenSecondBrain — محاولة لإعطاء الوكلاء ذاكرة طبيعية عما نفعله، ولماذا نفعله، وما القرارات التي تم اتخاذها بالفعل.

من سير العمل اليدوي إلى Dark Fabric

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

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

أردت الوصول إلى نموذج أكثر صرامة، والذي يبدو بشكل متزايد مثل Dark Fabric: على المدخل فكرة ميزة، وعلى المخرج — الميزة محققة ومختبرة ومنشورة. ليس “الوكيل كتب قطعة كود”، بل مصنع قادر على تقسيم العمل إلى مراحل بنفسه وقيادته عبر العملية.

لا يزال الوصول إلى Dark Fabric الكاملة بعيدًا. لكن الخطوة العملية الأولى موجودة بالفعل: Hermes، مرفوع على VPS، مع وكلاء لمهام مختلفة، ومهارات، وواجهة Telegram، وتوجيه رخيص للنماذج عبر OmniRoute.

وظهر تقريبًا على الفور الجزء الثاني الإلزامي من هذا المصنع: الوكلاء يحتاجون إلى ذاكرة.

لماذا يحتاج الوكيل إلى Second Brain

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

يحتاج أن يعرف:

والأهم — لا يجب أن يعتمد هذا فقط على “ذاكرة النموذج”. أحتاج نظام معرفة بسيط، قابل للتحقق، قائم على الملفات، يمكن فتحه يدويًا، وقراءته في Obsidian، ومزامنته، والالتزام به جزئيًا أو عدم الالتزام به على الإطلاق.

لذلك كان open-second-brain من البداية ليس “روبوت محادثة آخر بذاكرة”، بل بنية تحتية صغيرة حول Markdown vault.

لماذا Obsidian وMarkdown

كان اختيار vault متوافق مع Obsidian شبه واضح.

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

ثانيًا، Obsidian يحل بالفعل بشكل جيد الجزء البشري من Second Brain: الملاحظات، wikilinks، Daily، التنقل اليدوي، الرسم البياني، البحث. لم يكن من المنطقي إنشاء واجهة خاصة للمعرفة عندما تتوفر أداة مألوفة.

ثالثًا، الوكلاء لا يحتاجون إلى Obsidian كله. يحتاجون إلى عمليات حتمية: إنشاء هيكل خدمي، إضافة حدث في السجل اليومي، بناء فهرس الصفحات، فحص صحة vault، تصدير الإعدادات بدون أسرار. كل هذا يمكن فعله عبر CLI وMCP، دون إجبار النموذج على “التفكير” في عمليات الملفات حيث من الأفضل تنفيذ أمر دقيق.

حاليًا ينشئ open-second-brain منطقة للوكلاء في AI Wiki/ داخل vault، ويدير سجلات يومية في Daily/*.md، ويحدّث فهرس Markdown، ويتحقق من الإعدادات، ولا يمس الملاحظات البشرية فوق القسم الخدمي ## Raw events.

أعطيت مستودعًا فارغًا — اختار الوكيل البنية

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

كان الالتزام الأول توثيقيًا بالكامل: README وbootstrap المشروع في 6 مايو. ثم بنى الوكيل بسرعة أساس CLI، أمر o2b، init/doctor، vault primitives والفهرس. في نفس اليوم ظهر MCP server — طبقة مهمة، لأنه عبر MCP يمكن لبيئات تشغيل مختلفة الحصول على نفس الأدوات دون تحليل يدوي لسطر الأوامر.

كانت الإصدارات الأولى عملية للغاية: جعل Hermes قادرًا على تثبيت الإضافة، ورفع vault، والتحقق من الحالة، وكتابة الأحداث. ليست بنية مثالية على الورق، بل ذاكرة عاملة بحد أدنى لوكيل حقيقي.

ثم بدأ المشروع يتغير تحت ضغط التكاملات.

من Hermes إلى إضافة عالمية

ظل Hermes بيئة التشغيل الرئيسية. تم تصميم المشروع من أجله: تثبيت الإضافة، تحديد vault، إعطاء الوكيل الأدوات وجعله يكتب الأحداث المهمة في Second Brain.

لكن سرعان ما أصبح واضحًا أن الارتباط بـ Hermes فقط ليس صحيحًا. لديّ بالفعل وكلاء مختلفون وبيئات مختلفة: Claude Code، Codex، OpenClaw. إذا كان Second Brain يجب أن يكون ذاكرة مشتركة، فلا يمكنه أن يعيش في عميل واحد فقط.

هكذا ظهرت في المشروع المحولات وبيانات الوصف لعدة بيئات تشغيل:

هذا قرار معماري مهم: يجب أن تكون النواة واحدة، والمداخل يمكن أن تكون متعددة. لا يحتاج الوكلاء للنزاع حول مكان الحقيقة. الحقيقة — في vault وفي مجموعة العمليات المشتركة.

ما الذي اضطررت لإصلاحه على الطريق

تطور open-second-brain بسرعة كبيرة: من 6 إلى 9 مايو قطع المشروع طريقًا من README إلى إصدار 0.7.0. وكان كل إصدار تقريبًا ليس “تجميلًا”، بل رد فعل على مشكلة تكامل حقيقية.

على سبيل المثال، حصل OpenClaw أولاً على native plugin compatibility، لكن بيئة التشغيل كانت أكثر صرامة مما كان متوقعًا. اضطررنا لإضافة name داخل tool objects، وجعل register() متزامنًا، ثم إعادة كتابة إضافة OpenClaw بـ JavaScript نقي بدون child_process، لأن ماسح الأمان كان يحظر subprocess.

الموضوع الكبير التالي — الهوية. إذا كان في السجل اليومي مكتوبًا ببساطة @agent، فهذا السجل شبه عديم الفائدة. لذلك في 0.6.0 ظهر سير العمل مع أسماء الوكلاء: o2b init --agent-name، التسجيل في AI Wiki/identity/agents.md والتحقق من أن السجلات في Daily تحصل على @agent-name طبيعي، وليس placeholder.

ثم أُضيفت المنطقة الزمنية، والحماية من الكتابة في vault خاطئ، وبيانات الوصف marketplace لـ Claude وCodex، والتعليمات التلقائية لـ MCP، وتطبيع الوسائط الفارغة، والتحقق من مسار التثبيت، وسجل الوكلاء المتعددين. هذا لا يبدو كميزة منتج بطولية، لكن هذه التفاصيل تحديدًا هي ما يميز اللعبة عن الأداة التي يمكن تركها تعمل على الخادم.

الإصدار 0.7.0: نواة واحدة على TypeScript وBun

حدث أكبر تغيير في 0.7.0: انتقل المشروع إلى نواة TypeScript موحدة على Bun.

قبل ذلك كان في المستودع منطق متوازي: تنفيذ Python لـ CLI/MCP، جزء JavaScript لـ OpenClaw، Hermes shim. هذا المخطط يبدأ بالانحراف بسرعة. أصلحت خطأً في مكان — ليس من المؤكد أنك أصلحته في مكان آخر. أضفت المنطقة الزمنية في Python — يجب أن لا تنسى تكرارها في JS.

في 0.7.0 أزال الوكيل التكرار: Hermes، Claude Code، Codex وOpenClaw الآن يستهلكون وحدات مشتركة من src/core/. CLI يعيش في src/cli/، MCP — في src/mcp/، ونقطة دخول OpenClaw تُبنى من TypeScript إلى JS bundle عبر bun build.

في نفس الوقت ظهرت قاعدة اختبار طبيعية: bun:test بـ 176 حالة اختبار، Python shim tests، اختبار append-event المتزامن في 12 عملية، فحوصات حداثة bundle ومزامنة الإصدارات في بيانات الوصف.

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

كيف يعيش هذا على VPS

كل هذه القصة تعمل على VPS عادي بحوالي 8 دولارات في الشهر. هناك يعيش Hermes أيضًا، وهناك يمكن تطوير البرمجيات، وهناك تُدار اشتراكات AI والتوجيه عبر OmniRoute.

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

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

هذا لا يزال ليس Dark Fabric. لكنه لم يعد مجرد “محادثة مع نموذج”.

ماذا حصلنا

في وقت كتابة هذا المسودة، open-second-brain هو طبقة ذاكرة صغيرة لكنها مفيدة بالفعل لتطوير البرمجيات بالوكلاء.

يستطيع:

الأكثر قيمة ليس قائمة الأوامر. القيمة في أن الوكلاء حصلوا على بروتوكول ذاكرة مشترك: عندما يحدث شيء دائم — كود، إصلاح، إعدادات، محتوى، نتيجة بحث، قرار تصميم — يجب تسجيله بحيث يمكن لـ future-me وfuture-agent العثور عليه لاحقًا.

ماذا بعد

الهدف الأقرب — الوصول بالربط بين Hermes وopen-second-brain إلى حالة حيث لا يكتب الوكيل الأحداث فقط، بل يستخدم فعلاً الذاكرة المتراكمة عند التخطيط والمراجعة.

بعد ذلك أريد:

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

open-second-brain — خطوتي العملية الأولى في هذا الاتجاه.

كيف كُتب هذا المنشور

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