مشروع · 2026 · مؤلف

Fulcrum: منصة تحكم local-first للوكلاء

تتبع مهام وإنفاذ WIP واسترجاع ذاكرة هجين وسياق Chief-of-Staff لأساطيل من وكلاء الترميز بالذكاء الاصطناعي المتوازية.

Screenshot of the Fulcrum GitHub repo page showing topic tags, branches, and commit history

أشغّل خمسة وكلاء ترميز بالذكاء الاصطناعي بالتوازي في معظم أيام العمل. Claude Code وCodex وGemini CLI وPi وOpenCode - كل واحد قادر، وكل واحد يجهل تماماً ما يفعله الآخرون. قبل Fulcrum، كانت “طبقة التنسيق” لديّ لزقة ودعاء وربنا يستر. مش مبالغة. كانت فيه لزقة حرفياً.

لماذا يوجد

المشكلة ليست أن الوكلاء الأفراد سيئون. إنهم رائعون. المشكلة هي الفجوة بين جلسة وكيل منتجة واحدة وسير عمل متعدد الوكلاء ما يسيحش دماغك أثناء إدارته.

كل إطار عمل من البائعين قيّمته كان إما مقيّداً بمزوّد واحد (دي لأ)، أو مصمَّماً لحلقات request-response عديمة الحالة (عديم الفائدة لجلسات تمتد لساعات)، أو يحتاج backend سحابياً لا أثق به بسياق عملي الجاري. أردت شيئاً يعمل محلياً، ويبقى عبر إعادة تشغيل الحاسوب المحمول، ولا يتطلب مني شرح تاريخ مشروعي بالكامل من جديد في كل مرة أفتح علامة تبويب طرفية جديدة.

فبنيت الشيء الذي أردت استخدامه. يُسمى Fulcrum لأن الوكيل هو الرافعة؛ ومنصة التحكم هي ما يحدد أين يقع نقطة ارتكاز الرافعة فعلاً.

كيف يعمل

يُعرض Fulcrum كـMCP server - Model Context Protocol الذي تقدّمه Anthropic كسطح الاستدعاء القياسي للأدوات لـClaude Code. كل وكيل يتصل يحصل على الوصول إلى نفس مجموعة المكتبيات الأساسية: إدارة المهام، وتتبع دورة حياة التشغيل، ومخزن ذاكرة هجين.

طبقة التخزين هي SQLite مع FTS5 للبحث النصي الكامل، مُعزَّزة بفهرس متجهي للاسترجاع الدلالي. حين يريد وكيل استرجاع شيء - “ماذا قررنا بشأن مخطط auth الأسبوع الماضي؟” - تُشغّل Fulcrum استرجاعاً ثلاثي المراحل: مطابقة كلمات مفتاحية FTS5، وتشابه جيب تمام المتجهات، واجتياز رسم بياني عبر الكيانات المذكورة في الاستعلام. تُدمج النتائج عبر Reciprocal Rank Fusion المُرجَّحة وتُصفّى بعتبة ثقة قبل أن يصل أي شيء إلى نافذة سياق الوكيل.

الذاكرة لها ثلاث طبقات. L0 تفريغات خام - حرفية، غير قابلة للتغيير، مُلحَقة فقط. L1 صفحات wiki منسّقة يحتفظ بها منسّق LLM بدرجات ثقة وطبقات احتجاز ومراجع مرجعية خلفية لمصادر L0 الخاصة بها. L2 الفهرس المتجهي على L1. حين تطلب من Fulcrum استرجاع شيء، تحصل على صفحات L1 مع سند L0 مُرفَق، حتى تتمكن دائماً من تتبع ادعاء إلى نص الجلسة الخام الذي ولّده.

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

دور Chief-of-Staff هو طبقة التنسيق: يبني لقطات حالة العالم من المهام النشطة والوكلاء الجارية والأحداث الأخيرة، ثم يستخدم تلك اللقطات لتوزيع العمل على الأدوار المتخصصة. COS لا يمكنه كتابة كود. الأدوار المتخصصة لا يمكنها إنشاء تنسيق فرعي. تسلسل الأدوار هرمي مُنفَّذ على طبقة الأداة، لا طبقة الـprompt.

ما الذي يثير الاهتمام

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

الوكلاء يتعطلون. الطرفيات تُغلَق. أغطية الحاسوب المحمول تُخفَض. تشغيل كان “جارياً” منذ ساعتين قد لا يكمل استدعاء complete_agent_run أبداً. لدى Fulcrum كاسح تشغيل قديم يعمل عند بدء الجلسة ويُلغي أي تشغيل لم تتجاوز آخر نبضة قلب له العتبة الزمنية. بدون ذلك، تمتلئ حالة مساحة العمل بوكلاء يعملون وهمياً ويبدأ Chief-of-Staff في اتخاذ قرارات تخطيط بناءً على أشباح.

الشيء الآخر غير الواضح: جعل مسارات كتابة الذاكرة متكافئة (idempotent) أصعب بكثير مما يبدو حين يكون لديك خمسة وكلاء متزامنة كلها تسجّل ربما نفس القرار المعماري من زوايا مختلفة قليلاً. مهمة المنسّق هي إلغاء التكرار والإحلال والحفاظ على سطح L1 متماسك - مما يعني أن طبقة L0 الخام تحتاج تحمّل حجم كتابة عالٍ ومسار التنسيق يحتاج التعامل مع حل التعارضات بشكل رشيق.

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

ما الذي كنت سأغيّره

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

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

مسار الإرسال - حيث ينشئ COS فعلاً subprocess من Claude Code لدور متخصص - هو fire-and-forget الآن. أريد بثّ stdout مناسباً حتى يتمكن COS من مراقبة ما يحدث والتدخل إن كان التشغيل يسير في اتجاه خاطئ، دون الانتظار حتى يبرد نبض القلب.

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