Hive: منسّق خفيف متعدد الوكلاء

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

الخطوة التالية البديهية هي tmux عدد كبير من نُسخ Claude Code وجعلها تعمل على تذاكر منفصلة. أصبح هذا شائعًا إلى حد أن Anthropic بدأت تسميه "multi-Clauding". وبحسب مصطلحات ستيف ييغي، فهذا هو المستوى 6/7 من البرمجة بالوكلاء.

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

لذلك بنيت hive.

ما هو

Hive منسّق غير متزامن مكتوب بلغة Python ويعمل ضمن عملية واحدة، وينسّق عمل عدة وكلاء برمجة قائمين على نماذج اللغة الكبيرة باستخدام قائمة انتظار في SQLite، مع استخدام أشجار عمل git بوصفها بيئات تنفيذ معزولة.

هناك ثلاثة مكوّنات. الملكة هي جلسة Claude تؤدي دور مديرة مشروعك: تصف لها العمل، فتستكشف قاعدة الشيفرة، وتقترح تقسيمه إلى تذاكر مع تحديد تبعياتها، وتنتظر موافقتك. العاملون هم جلسات Claude (أو Codex) متوازية، تعمل كل منها في شجرة عمل git خاصة بها، وتسحب التذاكر من قائمة الانتظار وتنفّذها. أما مسار الدمج فهو وكيل آخر يعيد تأسيس الفروع، ويجري الاختبارات، ويدمج العمل المكتمل في main.

مبدأ التصميم الأساسي: تنسيق حتمي في Python، وتفويض القرارات التي يكتنفها الغموض إلى جلسات نماذج اللغة الكبيرة. انتقالات آلة الحالات، وحجز التذاكر، والتصعيد؟ Python. حلّ التعارضات، وتشخيص إخفاقات الاختبارات، والتقسيم الاستراتيجي للعمل؟ Claude.

إليك الصورة الكاملة:

You
  ├─ CLI / Queen (TUI)
  └─ Daemon (background)
       ↓
SQLite Database (~/.hive/hive.db)
  ├─ Issues (work queue)
  ├─ Dependencies (DAG)
  ├─ Agents (ephemeral identity)
  ├─ Events (audit trail)
  ├─ Notes (inter-agent knowledge)
  └─ Merge Queue
       ↓
Orchestrator (async event loop)
  ├─ Main Loop (spawn workers when slots open)
  ├─ Event Consumer (status updates from backends)
  └─ Merge Processor (per-project)
       ↓
Backend Pool
  ├─ Claude WS Backend (claude CLI via WebSocket)
  ├─ Codex App Server Backend (stdio protocol)
  └─ Tau Backend (testing)
       ↓
Workers (each in its own git worktree)

آلة الحالات

تمرّ كل تذكرة بدورة حياة من 7 حالات. وهذا أهم ما ينبغي فهمه عن hive، لأن كل قرار تصميمي ينطلق من الحفاظ على صحة عمل آلة الحالات هذه.

OPEN ──(claim)──→ IN_PROGRESS ──(success)──→ DONE ──(merge)──→ FINALIZED
  ↑                    │
  └──(retry/switch)────┘
                       │
                  (exhausted)──→ ESCALATED
                       │
                  (manual)─────→ CANCELED

تتبع سياسة التصعيد تسلسلًا من ثلاثة مستويات.

1. أعِد المحاولة مع الوكيل نفسه، بحد أقصى محاولتين. لعلّ النموذج مرّ بمحاولة غير موفقة فحسب.
2. بدّل الوكيل بآخر جديد لديه شجرة عمل نظيفة، بحد أقصى تبديلين.
3. صعّد الأمر إلى إنسان.

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

حجز العمل

قائمة انتظار العمل الجاهز هي استعلام SQL يعالج الرسم البياني الموجّه غير الدوري للتبعيات:

SELECT * FROM issues
WHERE status = 'open'
  AND assignee IS NULL
  AND type != 'epic'
  AND NOT EXISTS (
    SELECT 1 FROM dependencies d
    JOIN issues blocker ON d.depends_on = blocker.id
    WHERE d.issue_id = issues.id
      AND blocker.status NOT IN ('done', 'finalized', 'canceled')
  )
ORDER BY priority ASC, created_at ASC

لا تصبح التذكرة "جاهزة" إلا بعد زوال جميع العوائق أمامها.

الحجز تحديث ذرّي بأسلوب CAS: التحقّق من أن التذكرة لا تزال مفتوحة وغير مسندة لأحد، والتحقّق من أن تبعياتها لا تزال مستوفاة، ثم إجراء التحديث ضمن معاملة واحدة. إذا تسابق عاملان على التذكرة نفسها، يفوز أحدهما وتكون القيمة المُعادة للآخر هي False.

تجريد الواجهة الخلفية

هذا أكثر جزء أشعر بالرضا عنه. تضم واجهة HiveBackend نحو 15 دالة تغطي إدارة الجلسات (create_session، abort_session، get_session_status)، والتواصل (send_message_async، get_messages، reply_permission)، وبث الأحداث (on(event_type, handler)، connect_with_reconnect()). لا يهمّ المنسّق أيّ واجهة خلفية تعمل؛ فهو يستدعي الواجهة فحسب.

لماذا يهمّ هذا؟ تتناوب أحدث النماذج الرائدة على صدارة الترتيب كل بضعة أشهر. وليس واضحًا كيف تتفاعل النماذج المختلفة مع أغلفة سطر الأوامر المختلفة (أسمع أن GPT 5.4 يعمل جيدًا جدًا داخل Claude Code). يعني الاستقلال عن كلٍّ من النموذج وإطار التشغيل أن شيفرة التنسيق الأساسية لا تحتاج إلى التغيير بينما يتطور كل ما حولها بسرعة.

مسار الدمج

عندما يُكمل عامل تذكرة، يدخل العمل في مسار دمج.

تتولى عمليات الدمج جلسة Claude مخصّصة تُسمى "المصفاة". تتلقى المصفاة سياق التعارض أو مخرجات الاختبارات، وتحلّ المشكلة، وتكتب ملفًا منظّم البنية يتضمن النتيجة. ويمكنها دمج العمل (بعد حلّ التعارض ونجاح الاختبارات)، أو رفضه (بإعادته إلى open لإعادة العمل عليه)، أو تصعيده إلى إنسان (إذا كان بالغ التعقيد أو الغموض).

المصفاة جلسة طويلة العمر لكل مشروع، يُعاد استخدامها عبر عمليات دمج متعددة. عندما يتراكم فيها سياق أكثر من اللازم (>100 ألف رمز أو >20 رسالة)، يجدّد hive الجلسة لتبدأ بسياق جديد. يحصل كل مشروع على MergeProcessor خاص به، حتى لا يسبّب تنسيق مشاريع متعددة تزاحمًا بين المشاريع على عمليات الدمج.

نقل المعرفة بين الوكلاء

يكتب العاملون .hive-notes.jsonl أثناء التنفيذ:

{"category": "discovery", "content": "postgres dependency in main.py requires PGHOST to be set"}
{"category": "gotcha", "content": "tests require PYTHONPATH=src/"}

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

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

الملكة

الملكة هي نقطة التفاعل الرئيسية مع hive. إنها جلسة Claude تعمل في طرفيتك (وضع TUI). تزوّدها بمواصفات، فتستكشف قاعدة الشيفرة، وتقرأ .hive/project-context.md للاطّلاع على معرفة المشروع المتراكمة، وتقترح تقسيم العمل إلى تذاكر مع تحديد تبعياتها، وتنتظر موافقتك، ثم تنشئ التذاكر وتشغّل الخدمة الخلفية.

يوجد أيضًا وضع بلا واجهة للاستخدام في السكربتات:

hive queen --headless -p "Bump all dependencies and update the lockfile"

تتيح لك الملكة الانتقال من توجيه كل وكيل على حدة إلى إدارة مشروع. تفكّر في ما يجب إنجازه وكيفية تقسيمه.

الإعدادات وقابلية التعديل

يستخدم Hive منظومة إعدادات من 4 طبقات: القيم الافتراضية المضمّنة → ملف TOML عام (~/.hive/config.toml) → ملف TOML للمشروع (.hive.toml) → متغيّرات البيئة. الإعدادات الجديرة بالاهتمام:

ما تعلّمته

تضم قاعدة الشيفرة نحو 6,500 سطر من Python. صُمّمت لتعمل محليًا، وتستهلك أقل قدر من الموارد، وتكون بسيطة بما يكفي لتقرأها كاملة خلال فترة ما بعد الظهر وتبدأ تعديلها.

بعض ما تعلّمته أثناء العمل على hive:

SQLite هي قاعدة البيانات المناسبة لهذا الغرض. يتيح وضع WAL عمليات قراءة متزامنة أثناء الكتابة، ويتعامل توجيه busy_timeout مع التزاحم على الأقفال بسلاسة. يمكنك أن تجعل طبقة التنسيق بأكملها مجرد استعلامات SQL. مع 3-20 وكيلًا متزامنًا، تكون SQLite أكثر من كافية، ولبساطة التشغيل قيمة كبيرة.

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

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

الشيفرة متاحة على github.com/nwyin/hive. وهي مرخّصة بترخيص MIT ومصمّمة لتفريعها وتعديلها. إذا كنت تدير 3 وكلاء أو أكثر في tmux وتريد شيئًا أكثر تنظيمًا، فألقِ عليه نظرة.