SwarmForge: ما يصيبه سرب وكلاء أنكل بوب
يشغّل SwarmForge عدة وكلاء برمجة بالذكاء الاصطناعي في نوافذ tmux، كل واحد في شجرة عمل git خاصة به، وكل واحد يحمل دورًا هندسيًا واحدًا فقط. الأدوات مملة بشكل متعمد، والمثير هو الهيكل التنظيمي الذي تُرمّزه.
ما هو SwarmForge فعلًا
SwarmForge هيكل مكتوب بالـ shell وBabashka حول ثلاثة عناصر تملكها معظم الفرق أصلًا: نوافذ tmux، وأشجار عمل git، وملفات المطالبات. كل نافذة تشغّل وكيلًا واحدًا في دور واحد على شجرة عمل خاصة تحت .worktrees/، فلا يتنازع وكيلان على دليل العمل نفسه. يأتي السلوك من نص عادي في swarmforge/roles/<role>.prompt، مبنيًّا على constitution.prompt مشترك ومقالاته. لا يكتب الوكلاء في طرفيات بعضهم، بل يضعون تسليمات مُتحقَّقًا منها في طابور عبر .swarmforge/handoffs/، والحِمل إما اختصار كوميت من عشرة أحرف أو ملاحظة لا تتجاوز ثمانين حرفًا. تُختار الخوادم الخلفية لكل دور، فيمكن لجلسة واحدة أن تمزج Claude وCodex وCopilot وGrok.
فرع main توثيقي. الأسراب القابلة للتشغيل توجد على فروع two-pack وfour-pack وsix-pack: تُنزّل الفرع الذي تريد شكله ثم تشغّل ./swarm. المتطلبات هي zsh وgit وtmux وBabashka وواجهة سطر أوامر مُهيّأة لوكيل.
ثلاثة أشكال للسرب
كل فرع إجابة مختلفة على سؤال: كم من الإجراءات تستحق هذه المهمة؟ التدفق حلقة لا طابور: العمل يعود مرة أخرى.
two-pack
coder → cleaner → coder
coder يعمل بمنهج الاختبار أولًا، وcleaner ينظّف ويراجع CRAP وDRY ويصلح البنية. أصغر حلقة مفيدة: اكتبه ثم سلّمه لمن لا يتعلّق به عاطفيًا.
four-pack
specifier → coder → refactorer → architect → specifier
مواصفات القبول بصيغة Gherkin تدخل في المقدمة. يقوم refactorer بتنظيف يحفظ السلوك ويرفع التغطية، ويراجع architect البنية واتجاه التبعيات قبل أن تعود الحلقة إلى المواصفة.
six-pack
specifier → coder → cleaner → architect → hardener → QA
يضيف مرور تصليب يُطفِّر الكود لاكتشاف النقاط العمياء، ودور QA يشغّل تحققًا فعليًا. هذا هو الشكل الذي يتعامل مع الجودة كاهتمامات منفصلة لا كحسن نية وكيل واحد.
وكيل واحد، تخصص واحد
الأدوار هي الحجة. كل واحد منها عمل يُحشر عادة في الشخص نفسه، في الساعة نفسها، تحت الموعد النهائي نفسه.
specifier
يكتب مواصفات القبول بصيغة Gherkin وإجراءات ضمان الجودة. لا شيء يدخل السرب كجملة غامضة، وهذا تحديدًا نمط الفشل الذي لا تتعافى منه معظم تدفقات عمل الوكلاء.
coder
ينفّذ بمنهج الاختبار أولًا. ما يجعل TDD السلوك الافتراضي لهذه النافذة هو مطالبة الدور، لا صفحة سياسات لا يقرأها أحد.
cleaner
تنظيف محلي وتغطية ومراجعة CRAP وDRY. التسمية والتكرار يحصلان على مرور مخصص بدلًا من تعليق مراجعة لا ينفّذه أحد.
architect
بنية الوحدات والحدود واتجاه التبعيات. الدور الوحيد المسموح له بالاهتمام بشكل الكل بدلًا من التذكرة التي أمامه.
دور التصليب
التصليب بالتطفير: تغيير الكود لمعرفة أين تكون مجموعة الاختبارات عمياء. فحص سلبي، موضوع بعد أن يصبح الكود نظيفًا بالفعل.
QA
سكربتات تحقّق قابلة للتشغيل وإشعارات. التحقق شيء يعمل ويُبلّغ، لا إحساس بأن التغيير كان يبدو سليمًا.
كيف يعمل التنسيق
ثلاثة ملفات وثلاثة سكربتات تحمل البروتوكول كله. وهذا هو المقصود: الطوبولوجيا بيانات، والانضباط نص.
الطوبولوجيا ملف إعداد واحد
confكل سطر يعرّف نافذة tmux: أي دور، وأي خادم وكيل، وأي شجرة عمل، وهل يستلم العمل لكل مهمة أم على دفعات.
# swarmforge/swarmforge.conf
# window <role> <agent> <worktree> [task|batch] [extra-cli-args...]
window coordinator codex master
window coder codex coder
window architect codex architectالتسليمات مُتحقَّق منها لا مُتحاور فيها
shيضع الوكيل تسليمًا صادرًا في الطابور، ويقبل الدور التالي العمل عندما يفرغ، وإغلاق العنصر الحالي فعل صريح. الحِمل كوميت أو ملاحظة قصيرة جدًا، فعلى الكود أن يحمل المعنى.
# queue work for the next role: a commit, or a note of <= 80 chars
./swarm_handoff.sh coder 4f2a9c1b0d "boundary rule now specified"
# on the receiving side
./ready_for_next.sh # accept the next item or batch
./done_with_current.sh # close it out and free the windowالمعيار يعيش في شجرة المطالبات
textالمقالات المشتركة تحمل قواعد الهندسة وقواعد التسليم وسير العمل، والمقالات المحلية هي حيث يتجاوزها المشروع. مطالبات الأدوار تجلس فوق ذلك. يصبح معيار كتابة الكود مُدخلًا للعمل بدلًا من وثيقة عنه.
swarmforge/
swarmforge.conf
constitution.prompt
constitution/articles/
engineering.prompt
handoffs.prompt
workflow.prompt
project.prompt
local-engineering.prompt
local-workflow.prompt
roles/
<role>.promptما يستحق الاقتباس حتى لو لم تشغّله أبدًا
أعطِ كل مرور اسمًا ومهمة واحدة
- - افصل المواصفة والتنفيذ والتنظيف والبنية والتحقق إلى مرورات مستقلة بتعليمات مستقلة
- - توقّف عن مطالبة وكيل واحد، أو مهندس واحد، بحمل الاهتمامات الخمسة في وقت واحد
- - سمِّ المرور في طلب الدمج ليعرف المراجعون أي الأسئلة أُجيب عنها بالفعل
اعزل مساحة العمل لا الفرع فقط
- - شجرة عمل git لكل دور تُلغي عائلة الأخطاء كاملة التي يعدّل فيها وكيلان الملف نفسه في الوقت نفسه
- - العزل يجعل العمل المتوازي مقروءًا: لكل دور شجرة يمكن فحصها باستقلال
- - الحيلة نفسها تنفع شخصًا واحدًا يشغّل عدة وكلاء محليًا، بلا أي سرب
اجعل التسليمات ضيقة ومُتحقَّقًا منها
- - مرجع كوميت مع سطر قصير يدفعان النية إلى الكود وإلى رسالة الكوميت
- - التحقق عند حدود التسليم يمسك الطلب المعطوب قبل أن يهدر الدور التالي تشغيلًا عليه
- - التسليمات الضيقة قابلة للتدقيق: يمكن إعادة بناء من سلّم ماذا ومتى
أبقِ المعيار حيث يحدث العمل
- - قواعد الهندسة المكتوبة كمقالات مطالبات تُقرأ في كل مهمة، بخلاف صفحة ويكي
- - افصل القواعد المشتركة عن التجاوزات المحلية حتى لا يصبح استثناء فريق قاعدةً للجميع
- - أدرِج القواعد في إدارة الإصدارات مع الكود، وراجع تغييراتها كما تراجع الكود
أين تكمن التحفظات الصريحة
الحلقة تكلّف ما تكلّفه
ستة أدوار تراجع عمل بعضها تعني عدة تشغيلات وكيل لكل تغيير. في المهام الصغيرة تكون حلقة two-pack هي الخيار العقلاني عادة، وsix-pack مخصص لعمل تكون عيوبه مكلفة.
ثمانون حرفًا أنبوب ضيق
الحِمل الضئيل للتسليم انضباط: على الكوميت أن يشرح نفسه. لكنه يعني أيضًا أن الفهم المشترك للسرب يعيش بالكامل في المواصفات والكود. إن كانت قاعدة كودك لا تشرح نفسها أصلًا، فلن يصلح السرب ذلك لك.
الأدوار مطالبات لا ضمانات
مطالبة تقول استخدم TDD دفعة قوية لا آلية إلزام. ما يثبت فعلًا قابل للتشغيل: تشغيل الاختبارات، تشغيل التطفير، سكربت ضمان الجودة. أبقِ هذه في التكامل المستمر لا في السرب وحده.
لا يزال أحدهم يعتمد النتيجة
مُخرَج السرب اقتراح تغيير لا قرار إصدار. المسؤولية لا تتوزع على نوافذ tmux، وعمل المراجع يصبح أصعب لا أسهل عندما يزيد حجم الكود المعقول ظاهريًا.
سير العمل هو الإسهام
إذا نزعت tmux وBabashka والتثبيت من أرشيف tar، يبقى SwarmForge دعوى عن هندسة البرمجيات: التخصصات التي تُبقي الكود قابلًا للسكنى قابلة للفصل، وكل واحد منها يستحق دوره الخاص بتعليماته الخاصة. كانت هذه الدعوى صحيحة قبل الوكلاء، ولهذا بالضبط تنتقل.
اقرأه كتنفيذ مرجعي لا كمنصة. تبنَّ تقسيم الأدوار وعزل شجرة العمل والتسليم المُتحقَّق منه، وستحصل على معظم القيمة سواء أدّى العمل ستة وكلاء أو مهندسان أو واحد من كل نوع.
مقالات هندسية ذات صلة
دور التصليب ودور cleaner يشيران معًا إلى ممارستين تستحقان الفهم بحد ذاتهما.
اختبارات التطفير سلبية. واختبارات TDD إيجابية.
تشغيل التطفير لا يبلّغ إلا بما لا تلاحظه المجموعة، بينما يقرر اختبار TDD ما يجب أن يفعله النظام. وكيف تستخدم كلًّا منهما تبعًا لذلك.
مقياس CRAP: التعقيد والتغطية في رقم واحد
كيف تجمع صيغة CRAP بين التعقيد والتغطية، وما تطلبه كل درجة، وكيف تجعلها بوابة دون إطلاق حملة تنظيف.
الأسئلة الشائعة
ما الذي يلزم لتشغيل SwarmForge؟
zsh وgit وtmux وBabashka، بالإضافة إلى واجهة سطر أوامر مُهيّأة لوكيل مثل Claude أو Codex أو Copilot أو Grok. لا خدمة سحابية ولا طبقة تنسيق يجب إقامتها: السرب نوافذ tmux يمكنك مراقبتها، مع شجرة عمل لكل دور على القرص.
من أي فرع يبدأ الفريق؟
two-pack. دوران يكفيان لتحسّ ما إذا كان انضباط التسليم يناسب عملك، ومن الصعب تبرير تكلفة حلقة كاملة من ستة أدوار قبل معرفة ذلك.
هل يُلغي سرب الوكلاء الحاجة إلى ضمان الجودة؟
لا. إنه ينقل ضمان الجودة إلى دور مُسمّى بسكربتات قابلة للتشغيل، وهذا أفضل من تركه ضمنيًا، لكن التحقق نفسه يجب أن يكتبه من يفهم ما يدين به المنتج لمستخدميه.
هل هذا تنسيق جاهز للإنتاج؟
تعامل معه كمرجع لسير العمل لا كمنصة مُدارة. القيمة الباقية هي تقسيم الاهتمامات الهندسية وبروتوكول التسليم الضيق، ويمكن تبنّي كليهما بمعزل عن سكربتات الـ shell.