عندما يصبح الوكلاء زملاء عمل: الفكرة وراء Buzz

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

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

هنا بالضبط يأتي دور Buzz. المشروع مفتوح المصدر ينتمي إلى Block، الشركة التي يقودها مؤسس تويتر المشارك جاك دورسي والتي تقف خلف Square. لا يريد المشروع بناء مساعد ذكاء اصطناعي آخر. Buzz ينشئ مساحة عمل مشتركة يستخدم فيها البشر والوكلاء نفس القنوات والمواضيع والمشاريع والبروتوكولات. يمكن لوكيل Codex إنشاء خطة، ويمكن لـ Claude Code انتقادها، ويمكن لإنسان اتخاذ القرار، ويمكن للوكيل التالي تحويل ذلك إلى تعديل في المستودع. تبقى السلسلة بأكملها مرئية في نفس المساحة.

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

المشكلة الحقيقية ليست في النموذج

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

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

لوحات التحكم من نوع “Mission Control” تحل هذه المشكلة جزئياً فقط. قد تُظهر أن خمسة وكلاء نشطون. لكنها لا تخلق بعد مكاناً مفهوماً بشكل مشترك تبقى فيه المهمة والنقاش والحالة الوسيطة والمراجعة والقرار مجتمعة معاً. لهذا لا يبدأ Buzz بقائمة وكلاء أجمل، بل بمساحة العمل نفسها.

الوكلاء أعضاء وليسوا برامج آلية ملصقة

للوهلة الأولى، يبدو Buzz مألوفاً. توجد مجتمعات وقنوات عامة وخاصة ومواضيع ورسائل مباشرة ومنتديات وبحث ومكالمات جماعية وتطبيق للهاتف المحمول. الفرق الحاسم عن تكامل Slack العادي يكمن تحت السطح.

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

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

Buzz لا يجلب معه تلقائياً الذكاء الكامل. مساحة العمل تربط ما يُسمى Harnesses ونماذج تعمل بالفعل محلياً أو على خادم أو عبر مزود. وفقاً لحالة المشروع الحالية، يشمل ذلك من بين أمور أخرى Codex و Claude Code و Goose. يمكن ربط وكلاء إضافيين عبر واجهات مفتوحة. هذا نموذج “أحضر وكيلك الخاص”: Buzz ينسق، والوكيل المعني يفكر ويتصرف بأدواته ومهاراته وصلاحياته وتكاليف نموذجه الخاصة.

الـ Relay هو حالة العمل المشتركة

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

يستخدم Buzz بروتوكول Nostr. يوقّع البشر والوكلاء الأحداث بمفاتيحهم الخاصة. يتحقق الـ Relay من الهوية والعضوية، ويخزن الأحداث، ويوزعها على العملاء المخولين. لكن هذا لا يجعل Buzz شبكة نظير إلى نظير سحرية. الـ Relay هو المصدر المركزي لمجتمع معين. لا يوجد تكرار تلقائي بين الـ Relays، وتبقى الرسائل على الـ Relay الذي أُرسلت منه.

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

تستخدم بنية الخادم الحالية مكونات معروفة: PostgreSQL للأحداث والبحث النصي الكامل، وRedis للنشر والاشتراك (Pub/Sub)، وتخزين متوافق مع S3 للوسائط. هذه ليست خدمة صغيرة يمكن نسيانها بعد التثبيت. الـ Relay الذي يُشغَّل ذاتياً يحتاج إلى TLS وتحديثات ونسخ احتياطي ومراقبة وإدارة نظيفة للمفاتيح.

لماذا السياق المشترك ذو قيمة كبيرة

أقوى فكرة في Buzz هي السياق الدائم والمرئي بشكل مشترك. لم يعد المشروع يتكون من رسالة دردشة في Slack، وتشغيل وكيل منفصل، وطلب سحب (Pull Request) على GitHub، وقرار في مكالمة فيديو. يحاول Buzz جمع هذه الآثار في مساحة أحداث واحدة.

هذا مفيد بشكل خاص عندما يكون لدى وكلاء مختلفين نقاط قوة مختلفة. يمكن أن يبدو سير عمل واقعي كالتالي:

1. يصف إنسان في قناة المشروع الهدف والحدود.
2. وكيل بحث يجمع المعلومات ويوثق مصادره.
3. وكيل ثانٍ يهاجم نقاط الضعف ويبحث عن حجج مضادة.
4. Codex أو Claude Code يضع خطة ملموسة.
5. وكيل آخر يفحص الخطة من ناحية الأمان أو الاختبارات المفقودة أو الافتراضات غير الواضحة.
6. بعد الموافقة البشرية، يُنفَّذ التعديل في Worktree منفصل.
7. يبقى الـ Diff ونتائج الاختبار والمراجعة والقرار قابلة للعثور عليها في القناة المعنية.

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

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

هذه هي النقطة التي يصبح فيها Buzz أكثر من مجرد دردشة جماعية. القناة ليست فقط مكاناً للتواصل. تصبح سجل عمل قابلاً للتتبع.

Buzz يريد استبدال GitHub أيضاً

يدمج Buzz مستودعات Git والتصحيحات (Patches) والمراجعات وأحداث الحالة في نفس مساحة العمل. يمكن للـ Relay استضافة المستودعات بنفسه. يمكن للوكلاء استخدام Worktrees، والعمل بشكل منفصل على المتغيرات، وتقديم التعديلات كتصحيحات، ومناقشة المراجعات في سياق المشروع.

الرؤية وراء ذلك قوية: فرع الميزة (Feature Branch) يصبح مساحة. هناك لا توجد فقط الالتزامات (Commits)، بل أيضاً النقاش حول سبب ضرورة التعديل، والبدائل التي تم رفضها، وما أبلغ عنه التكامل المستمر (CI)، ومن وافق على الدمج. غالباً ما تفتقد هذه القصة التأسيسية اليوم، خصوصاً في الكود المُنشأ بواسطة الوكلاء.

مع ذلك، لا أريد استبعاد GitHub بسرعة. GitHub ليس مجرد مخزن Git، بل نظام بيئي نما على مدى سنوات للصلاحيات والمراجعات وCI/CD وفحوصات الأمان والإصدارات والتكاملات والتعاون الخارجي. لدى Buzz أساسيات Git تعمل ونهج مثير للاهتمام كـ Forge. لكن حالة المشروع الخاصة به تميّز بوضوح بين الأجزاء التي تعمل بالفعل والوظائف التي ما زالت قيد الربط والرؤية المستقبلية. بالنسبة للمستودعات الحرجة، الاستخدام التدريجي أكثر منطقية من الهجرة الفورية.

اختباري الأول مع Buzz

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

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

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

بالنسبة لتطوير البرمجيات المكثف، بقي العمل المباشر في Codex أو Claude Code أسرع مع ذلك. Buzz يضيف اتصالاً وتوثيقاً وسياقاً مشتركاً. هذه الطبقة تكلف وقتاً ورموزاً (Tokens). كل وكيل إضافي يمتلك جلسة خاصة به، ويمكن معالجة سجل قناة واسع عدة مرات عند وجود عدة نماذج. لهذا سأستمر في استخدام الـ Harness الأصلي لعملية برمجة طويلة، وأستخدم Buzz بالأحرى للتخطيط والتسليم والمراجعات.

لم أختبر بعد بعمق كافٍ سير العمل (Workflows) ومكالمات Huddle الأطول والنماذج المحلية وعدة وكلاء عن بُعد يعملون باستمرار. هنا بالضبط يجب على Buzz أن يثبت في الحياة اليومية أن المهام ليست مرئية بشكل جميل فقط، بل تُنجَز أيضاً بشكل موثوق. البرنامج ما زال قبل الإصدار 1.0 ويشعر المرء في بعض المواضع بحداثته المتوقعة. للتجارب هذا مقبول. لكن العمليات المركزية ما زالت تحتاج إلى تحكم ومنطق إعادة محاولة وطريق عودة يدوية واضحة.

السياق المشترك هو أيضاً حد أمني

ما يجعل Buzz مفيداً يوسّع في نفس الوقت سطح الهجوم. وكيل مرتبط مثل Codex أو Claude Code أو Hermes قد يجلب معه وصولاً إلى الملفات، وShell، ومتصفح، وخوادم MCP، وبريد إلكتروني، وتقويم، أو أدوات داخلية أخرى. إذا كان بإمكان عضو فريق مخاطبة هذا الوكيل، فإن الصلاحية تمتد أبعد بكثير من مجرد كتابة رد في دردشة.

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

مع ذلك، التوقيعات التشفيرية لا تحل كل مشكلة تدقيق. يحتفظ Buzz بسجل تدقيق مسلسل (chained) قابل لكشف التلاعب. لكن مهاجماً يملك وصول كتابة إلى قاعدة البيانات يمكنه إعادة حساب السلسلة بعد التلاعب. السجل إذن قابل لكشف التلاعب (tamper-evident) وليس مقاوماً للتلاعب (tamper-resistant). يجعل التغييرات قابلة للكشف طالما لم تنهر قاعدة الثقة في التخزين بالكامل.

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

الاستضافة الذاتية تغيّر سيادة البيانات، لكنها لا تغيّر تلقائياً تدفق البيانات بأكمله. الـ Relay الخاص يحتفظ بالرسائل والملفات على البنية التحتية الخاصة. إذا استمر الوكيل في استخدام نموذج سحابي، فإن البيانات المطلوبة للمهمة تترك الـ Relay رغم ذلك. التشغيل المحلي الحقيقي يتطلب إذن Relay خاص ونماذج محلية وأدوات محلية في آن واحد. كتبت بالفعل بشكل منفصل عن إمكانيات وحدود Buzz Shared Compute.

كيف أستخدم Buzz حالياً

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

لم يكن إعدادي الأول شركة مستقلة بمئة وكيل، بل مراجعة محدودة:

• وكيل يضع خطة تقنية من مشكلة (Issue) موجودة.
• وكيل ثانٍ يبحث عن ثغرات أمنية وافتراضات مفقودة وتعقيد غير ضروري.
• يجب على كليهما ذكر المصادر والملفات والأسئلة المفتوحة.
• بعد جولتي نقاش على الأكثر، ينتظر الفريق موافقة بشرية.
• فقط بعد ذلك يُسمح لوكيل بإعداد تعديلات في Worktree معزول.

بهذا استطعت اختبار القوة الحقيقية لـ Buzz دون إعادة بناء عمليتي بأكملها فوراً. في نفس الوقت أصبح استهلاك الرموز (Tokens) والتأخير (Latency) والصلاحيات وإمكانية التتبع مرئية بوضوح.

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

بالنسبة لشركة أكبر، سأكون أكثر تحفظاً. قبل الإصدار 1.0، وبدون خط دعم طويل الأمد، وبسير عمل ما زال فتياً، لن أجعل Buzz المكان الوحيد للاتصال الحرج أو الكود المصدري. المشروع التجريبي (Pilot) قد يكون منطقياً. الاستبدال الكامل لـ Slack و GitHub سيكون حالياً رهاناً على سرعة تطور المشروع.

الفكرة وراء Buzz أكبر من العميل الحالي

الجزء الأكثر إثارة في Buzz بالنسبة لي ليس ميزة واحدة. القنوات والمنتديات ومكالمات Huddle واستضافة Git والنماذج المحلية موجودة في أماكن أخرى أيضاً. الجديد هو الافتراض المتسق بأن الوكلاء لم يعودوا مجرد أدوات خاصة بمستخدمين فرديين. إنهم يصبحون مشاركين مرئيين في عملية عمل مشتركة.

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

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

ربما يستبدل Buzz Slack و GitHub في يوم ما. لكن لليوم، تكفي عبارة أصغر لكنها أهم: Buzz تصميم مقنع لكيف يمكن أن تبدو مساحة العمل عندما لا يعمل فيها البشر فقط بعد الآن. الحوسبة المشتركة (Shared Compute) هي ما لفت انتباهي إلى المشروع. مساحة العمل المشتركة هي السبب في أنني سأستمر في اختبار Buzz.

خلاصتي بعد الاختبار الأول

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

ما أقنعني هو السياق المشترك، وهويات الوكلاء المنفصلة بوضوح، وإمكانية جعل نموذج ثانٍ يهاجم نتيجة ما مباشرة. ما لم يقنعني بنفس القدر هو العبء الإضافي. بالنسبة لمهمة برمجية واحدة، الطريق المباشر عبر Codex أو Claude Code ما زال أسرع. بمجرد مشاركة عدة وكلاء أو بشر، يبدأ Buzz بإظهار قوته.

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

إلى اللقاء في المرة القادمة،
Joe

الأسئلة الشائعة