أُدير Fulcrum — لوحة تحكّم وكلاء local-first لتنسيق عمل البرمجة متعدّد الوكلاء. يوجد في السوق عشرات إطارات الوكلاء في 2026. السؤال “لماذا واحداً آخر؟” يستحق جواباً صريحاً، وها هو: لا أحد منها كان يتولّى الأجزاء التشغيلية المُملّة التي تجعل النموذج فعلاً قابلاً للاستخدام عند 3,400 commit في السنة.

ما هو Fulcrum فعلاً

Fulcrum runtime صغير بـTypeScript يكشف، عبر MCP server وCLI، حفنة من الأوليّات التي يستطيع أي وكيل برمجة (Claude Code، Codex، Gemini، Cursor، أي متحدّث MCP) استدعاءها:

  • تتبّع المهام — ابدأ/حدّث/أتمم وحدة عمل، مع حدود WIP وتتبّع العوائق.
  • استرجاع ذاكرة هجين — FTS5 + vector + مخزن graph اختياري مع supersession وتتبّع الثقة، كي تستطيع الوكلاء تراكم سياق دائم عبر الجلسات دون إعادة التلخيص في كل مرة.
  • سياق Chief-of-Staff — لقطة حالة العالم التي يستطيع الوكلاء الآخرون استهلاكها كإحاطة “ها هو ما يجري عبر workspace”، بدلاً من إعادة اكتشاف الحالة في كل جلسة.
  • دورة حياة تشغيل الوكيل — تسجيل، heartbeat، حجب، إتمام. التشغيل الخامل-غير-المكتمل يظهر في CLI بدلاً من أن يختفي.

كل شيء يتحمّل محلياً. لا مكوّن مستضاف، لا telemetry افتراضياً، لا قفل مورّد. يعمل على نفس الجهاز الذي يعمل عليه محرّرك ووكلاؤك.

الفضاء الذي يحلّه

معظم إطارات الوكلاء في السوق في 2026 محسّنة لأحد الشكلين:

الشكل A: المُنسّق السحابي المستضاف. LangChain-hosted، LlamaIndex-hosted، الواحدة الخاصة بكل مورّد. أوليّاتها تفترض أنك مرتاح لحالة مهام وكيلك التي تعيش على جهاز شخص آخر وخطته التسعيرية تُطبَّق على كل خطوة.

الشكل B: runtime داخل المحرّر. الوكيل المدمج في Claude Code، Cursor، إلخ. أوليّاتها تفترض أنك تعمل في محرّر واحد في وقت واحد مع وكيل واحد، بشكل مؤقّت، وأن أي شيء دائم مشكلة المستخدم.

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

Fulcrum يعيش في الشكل الثالث: local-first، متعدّد الوكلاء، مرئي للوكلاء. الوكلاء تستطيع الاستعلام عن قائمة المهام والذاكرة مباشرةً؛ البيانات تخصّك لا المورّد؛ والأوليّات التشغيلية (WIP، العوائق، heartbeats) من الدرجة الأولى.

خيارات التصميم المهمّة

بعض القرارات التي أدافع عنها في أي review:

1. الوكلاء تحصل على صلاحية قراءة، البشر يحصلون على صلاحية كتابة

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

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

2. الذاكرة متدرّجة، لا مسطّحة

طبقة الذاكرة لها ثلاث طبقات: L0 (تفريغات خام، غير قابلة للتغيير، صفر اقتطاع)، L1 (صفحات wiki منقّحة، مع ثقة واحتفاظ، يُعدّلها وكيل منقّح)، L2 (vectors فوق L1). الاسترجاع يمرّ عبر L1 مع مراجع L0 لأصولها، كي تستطيع الوكلاء تتبّع أي ادعاء إلى مصدره الخام.

هذه المعمارية ليست جديدة (MemGPT ونسبه ألهموا كثيراً منها)، لكنها مُنفّذة بطريقة تجعل مسار المصدر رخيص الاتّباع. حين يخبر Fulcrum وكيلاً بشيء، الوكيل يستطيع أن يسأل “من أين جاء هذا؟” ويحصل على جواب.

3. حدود الأدوار مُطبَّقة، لا مقترَحة

Fulcrum عنده مفهوم أدوار الوكلاء (مهندس، مختبر، مراجع، chief-of-staff، إلخ). فقط chief_of_staff يستطيع استدعاء فِرق. فقط الوكلاء المناسبون للدور يستطيعون المطالبة ببعض المهام. هذه ليست اتفاقيات — تُفحَص على طبقة MCP. إن حاول وكيل software_engineer استدعاء فريق، يحصل على خطأ.

سبب دمج هذا: بدونه، سير عمل الوكلاء تنهار سريعاً إلى “الجميع يفعل كل شيء”، وهو بالضبط الأمراض التي يُفترض أن متعدّد الوكلاء يتجنّبها.

4. يعمل بلا إنترنت

لا استدعاءات شبكة مطلوبة للعمليات الأساسية. كل شيء يعمل ضد SQLite محلية، ملفات vault markdown محلية، وembeddings محلية. إن انقطع إنترنت homelab، Fulcrum يستمر في العمل، وكذلك الوكلاء الموجّهة إليه.

ما ليس عليه

لتحديد التوقعات:

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

جواب “لماذا تكلّف نفسك”

الجواب الصريح على “لماذا تكتب هذا حين X موجود”: كتبتُه لأن استخدام X كان يُكلّفني 20 دقيقة في كل جلسة كحمل عمل زائد، وFulcrum يُكلّفني 30 ثانية. عمل متعدّد الوكلاء ومتعدّد التعاملات له حمل عمل ثابت يتراكم سريعاً. إما تدفعه وإما تستثمر مرة في أداة تجعله يختفي. استثمرتُ مرة.

إن كنت تعمل بشكل مشابه — وكلاء متعدّدون، سياق دائم، انضباط مهام حقيقي — جرّب Fulcrum. إن كنت تعمل بوكيل واحد، جلسة واحدة، عمل مؤقّت، لا تحتاجه. هذا مقبول. ليس يحاول أن يكون كل شيء.

النمط يعمّم

ما أكثر شيء أفتخر به في Fulcrum ليس الكود. إنه النمط: local-first، مرئي للوكلاء، متعدّد الوكلاء، مستمر. هذا النمط سيأكل كثيراً من سوق المُنسّقين المستضافين في السنتين القادمتين. الفِرق التي تبني فوق مُنسّقين مقيّدين بمورّد ستستيقظ تريد هذا الشكل وليس عندها إياه. أفضّل أن أكون على جانب الناس الذين يبنون الشكل على جانب من ينتظر شخصاً آخر.

أيضاً: رسم بياني commit الخاص بي في السنة الماضية هو في معظمه Fulcrum والموقع الذي تقرأ فيه هذا. إن أردت معرفة ما يفعله “محمد خير” حسين أبو الرز بين الوظائف، هذا هو الجواب. البطالة لم تشحن هذا العدد من الـcommits قط.