Buzz من شركة مؤسس تويتر: مساحة عمل للبشر ووكلاء AI

مشروع Buzz ليس تطبيق مراسلة آخر يضيف روبوت ذكاء اصطناعي إلى قناة عمل، بل محاولة من شركة Block لإعادة بناء مساحة العمل نفسها بحيث يعمل البشر ووكلاء الذكاء الاصطناعي داخل المكان ذاته، بهويات مستقلة وسجل أحداث واحد. المشروع مفتوح المصدر ويمكن استضافته ذاتيًا، ويأتي من الشركة التي شارك في تأسيسها جاك دورسي، أحد مؤسسي تويتر والرئيس التنفيذي السابق للمنصة.
الإجابة السريعة
Buzz مساحة عمل مفتوحة المصدر تجمع المحادثات والمشروعات ومستودعات Git وسير العمل ووكلاء الذكاء الاصطناعي في نظام واحد مبني على Nostr. الوكلاء ليسوا Bots خارجية ترسل الرسائل فقط؛ يمكن إضافتهم إلى القنوات مثل أعضاء الفريق، ومنحهم مفاتيح وهوية وصلاحيات مستقلة، ليبحثوا في تاريخ المشروع ويكتبوا تعديلات ويراجعوا الكود ويشغّلوا Workflows ويتعاونوا مع البشر. المشروع من Block ومتاح حاليًا كتطبيق سطح مكتب مع Relay يمكن استضافته ذاتيًا.
من يقف خلف Buzz؟
المستودع موجود تحت حساب Block الرسمي على GitHub، وهي الشركة المعروفة سابقًا باسم Square. شارك جاك دورسي في تأسيس Block عام 2009، وما زال يقودها بصفة Block Head ورئيس مجلس الإدارة. ودورسي نفسه أحد مؤسسي Twitter، وتؤكد ملفات Twitter الرسمية القديمة أنه شغل منصب الرئيس التنفيذي في فترتين مختلفتين.
هذه الخلفية مهمة، لكن يجب الفصل بين أمرين: Buzz مشروع تبنيه Block وفريقها المفتوح المصدر، ولا يوجد في المستودع ما يبرر وصفه بأنه «برمجه جاك دورسي بنفسه». الأدق أنه مشروع صادر عن الشركة التي شارك دورسي في تأسيسها ويقودها، ضمن توجه أوسع لدى Block نحو المصادر المفتوحة ووكلاء الذكاء الاصطناعي.
الفكرة: قناة العمل نفسها تصبح ذاكرة المشروع
المشكلة التي يحاول المشروع حلها مألوفة لأي فريق تطوير: المحادثات في Slack أو Discord، والكود في GitHub، والاختبارات في خدمة CI، والوثائق في مكان آخر، بينما يعمل وكيل الذكاء الاصطناعي في نافذة منفصلة لا يرى بالضرورة كل ما حدث. النتيجة أن المعرفة موزعة بين عدد كبير من الأدوات.
في Buzz كل رسالة ورد فعل وخطوة Workflow وموافقة وحدث متعلق بـGit يمكن أن يسجل كحدث موقّع داخل Relay واحد. لذلك تصبح المحادثة والتغيير البرمجي ونتيجة الاختبار والقرار النهائي أجزاء من سجل واحد يمكن البحث فيه وتتبع صاحبه.
رؤية المشروع تذهب أبعد من تطبيق دردشة. المجتمع الواحد يمكن أن يصبح مساحة العمل كاملة، بهوية مشتركة ومحرك بحث وسجل أحداث، بينما يمتلك الفريق الـRelay الذي يستضيفه بدل الاعتماد بالضرورة على منصة مركزية خارجية.
وكلاء الذكاء الاصطناعي أعضاء في الفريق وليسوا إضافات جانبية
أكثر ما يميز المشروع هو الطريقة التي يعامل بها وكلاء الذكاء الاصطناعي. يمكن إضافة Agent إلى قناة كما تضيف زميلًا بشريًا، ويكون له مفتاح وهوية وسجل نشاط خاص. هذا الوكيل يستطيع قراءة ما تسمح به عضويته، والبحث في تاريخ القناة، وتشغيل أدوات، وتقديم Patch ومراجعة كود وتشغيل Workflow.
يدعم المشروع أدوات ووكلاء مثل Goose وCodex وClaude Code عبر طبقة ACP، إلى جانب buzz-cli المصمم أساسًا لكي تتعامل معه النماذج عبر JSON. هنا لا يعيش الوكيل خارج مساحة العمل ثم يتم نسخ إجابته إليها؛ بل يصبح جزءًا فعليًا من المساحة نفسها.
مثال عملي: عطل في الثانية صباحًا
يقدم التوثيق مثالًا جيدًا لفهم الفكرة. مهندس يواجه عطلًا في الإنتاج ويسأل داخل قناة الحادث: هل رأينا هذا الخطأ من قبل؟ يستطيع وكيل يراقب القناة البحث في ستة أشهر من تاريخ الحوادث، ثم إحضار النقاشات السابقة وأسباب المشكلة والحلول التي نجحت.
الفائدة هنا ليست أن النموذج يتذكر المشكلة من تدريبه، بل أن Buzz يمنحه ذاكرة المشروع الحقيقية. يعود الوكيل بالمحادثات والقرارات السابقة نفسها، ما يسمح للإنسان بمراجعة الأدلة بدل الاعتماد على إجابة تبدو مقنعة فقط.
فرع Git يمكن أن يتحول إلى غرفة عمل
من السيناريوهات التي يطرحها المشروع أن يتحول Feature Branch إلى غرفة خاصة به. عندما يبدأ العمل على ميزة، يمكن أن تعيش التعديلات ونتائج CI ومراجعة الوكيل ومناقشة الفريق وقرار الدمج داخل المكان نفسه.
لاحقًا، عندما يسأل مطور لماذا كُتب جزء من الكود بطريقة معينة، يستطيع الرجوع إلى السجل الكامل بدل البحث بين Pull Request ورسائل دردشة ونتائج CI موزعة في ثلاث خدمات.
هذه الفكرة قريبة من الموضوع الذي تناولناه في سوالف عن أنظمة الوكلاء المتعددة وإدارة المشاريع، لكن الاختلاف أن هذا المشروع لا يقدم فقط طريقة لتنسيق عدة وكلاء، بل مساحة العمل والبنية التي يعيش فيها البشر والوكلاء معًا.
ماذا يعمل الآن وماذا ما زال قيد البناء؟
المستودع يفصل بوضوح نسبيًا بين الوظائف الموجودة والأفكار التي لم تكتمل. المتاح حاليًا يشمل Relay والقنوات وThreads والرسائل الخاصة وCanvases والوسائط والبحث وسجل التدقيق، إضافة إلى تطبيق سطح مكتب وأداة CLI للوكلاء وWorkflows بصيغة YAML وأحداث Git واستضافة المستودعات.
في المقابل، تطبيقات الهاتف لـiOS وAndroid ما زالت قيد الربط والتطوير، وكذلك بعض بوابات الموافقة على سير العمل ودورة حياة Huddles. كما توجد أفكار أبعد مثل Web-of-Trust بين Relays وإشعارات Push وميزات اجتماعية إضافية، لكن المشروع نفسه ينبه إلى أنها ليست وظائف مكتملة بعد.
ليس Blockchain رغم استخدام Nostr
اعتماد Buzz على Nostr قد يجعل البعض يربطه تلقائيًا بالعملات الرقمية أو Blockchain، لكن المستودع ينفي ذلك صراحة. الأحداث الموقعة تستخدم هنا للهوية وإثبات مصدر الحدث وسجل التدقيق، وليس لإنشاء شبكة تعدين أو عملة رقمية.
كل فعل أساسي تقريبًا يأخذ شكل Event له نوع وهوية وتوقيع. بذلك يمكن أن تصدر الرسالة من إنسان أو وكيل أو Workflow مع الاحتفاظ بطريقة موحدة لمعرفة من فعل ماذا ومتى.
الاستضافة الذاتية جزء أساسي من المشروع
يستطيع الفريق تشغيل Relay الخاص به، وهي نقطة مهمة في فلسفة المشروع. المسار المحلي للمطور يعتمد على Docker وأدوات البناء، بينما يقدم المستودع إعدادًا للإنتاج باستخدام Docker Compose مع Postgres وRedis وMinIO وإمكانية استخدام Caddy وTLS.
ويمكن أيضًا نشر Relay على Railway. هذا يسمح للمؤسسة بالاحتفاظ ببيانات المحادثات والكود والهوية وسجل الوكلاء في بنية تسيطر عليها، بدل إرسال كامل ذاكرة المشروع إلى مزود واحد.
تطبيق سطح المكتب موجود بالفعل
يوفر Buzz حزمًا جاهزة لـmacOS بمعالجات Apple Silicon وIntel، وLinux بصيغ AppImage وDEB، وWindows x64. وينبه المشروع إلى أن نسخة Windows الحالية غير موقعة، ولذلك قد يعرض SmartScreen رسالة تحذير عند التشغيل للمرة الأولى.
أحدث إصدار سطح مكتب ظاهر وقت الفحص هو Buzz Desktop v0.5.25 الصادر في 24 سبتمبر 2026. رقم الإصدار نفسه يوضح أن المشروع ما زال في مرحلة ما قبل 1.0، كما أن سياسة الأمان توصي باستخدام أحدث نسخة لأن المشروع لا يحتفظ حاليًا بفروع دعم طويلة المدى للإصدارات القديمة.
34 ألف نجمة وآلاف المساهمات
وقت إعداد هذه المراجعة، يعرض المستودع الرسمي نحو 34.8 ألف نجمة وأكثر من 4.6 آلاف Fork وما يزيد على 2700 Commit. هذه الأرقام لا تعني أن المشروع أصبح مستقرًا أو جاهزًا لكل شركة، لكنها تكشف حجم الاهتمام الذي جذبته فكرة مساحة عمل صممت من البداية لوجود وكلاء الذكاء الاصطناعي.
النشاط الكبير يظهر أيضًا في Issues وPull Requests والتحديثات المتقاربة. هذا جيد لمن يريد مشروعًا يتحرك بسرعة، لكنه يعني في الوقت نفسه أن الشركات التي ستستخدمه إنتاجيًا تحتاج إلى اختبار التحديثات وعدم افتراض ثبات جميع الواجهات قبل الوصول إلى الإصدار 1.0.
كيف يختلف Buzz عن Slack مع Bot ذكي؟
الفرق لا يتوقف عند وجود الذكاء الاصطناعي داخل القنوات. في الأدوات التقليدية تكون الدردشة نظامًا، ومستودع الكود نظامًا ثانيًا، والوكيل نظامًا ثالثًا، ثم تحتاج إلى Integrations لكي تتبادل هذه الأنظمة البيانات.
أما Buzz فيحاول جعل Relay المصدر المركزي للحقيقة، بحيث تتحدث الرسائل وأحداث Git والـWorkflows والوكلاء البروتوكول نفسه. الوكيل نفسه يمتلك هوية وMembership وسجل نشاط، ولا يعمل بالضرورة كخدمة غامضة خلف مفتاح API واسع الصلاحيات.
سجل واحد للمحادثة والكود والقرار
هذه ربما أهم فكرة تقنية في المشروع. عندما يرسل مطور Patch، ويراجعه وكيل، ثم يعمل CI، ثم يوافق شخص على الدمج، لا تصبح لدينا أربع قصص منفصلة في أربع أدوات. جميعها أحداث مرتبطة داخل بنية يمكن البحث فيها.
هذا يفتح بابًا مهمًا لوكلاء المستقبل: عندما تسأل الوكيل بعد ستة أشهر «لماذا اتخذنا هذا القرار؟» لا يحتاج إلى تخمين الإجابة من الكود فقط. يستطيع نظريًا الوصول إلى المناقشة والتعديل والاختبار والموافقة التي صاحبت القرار.
الوكلاء يمكنهم تشغيل مساحة العمل وليس فقط الحديث
التوثيق يؤكد أن Agents يستطيعون التعامل مع القنوات وCanvases وWorkflows وHuddles ومستودعات المشروع. ولذلك رؤية Buzz أقرب إلى إعطاء الوكيل نفس سطح العمل المتاح لزميل بشري، مع مفتاح وسجل نشاط منفصلين.
يمكن لوكيل مثلًا فتح مستودع، إنشاء Patch، تشغيل مسار عمل، طلب مراجعة وكيل آخر، ثم نشر النتيجة في القناة التي يعمل فيها الفريق. هذه النقلة من «مساعد يجيب» إلى «عضو ينفذ» هي جوهر المشروع.
لكن البشر لا يزالون داخل الحلقة
رغم هذا التركيز على الوكلاء، يقول المستودع بوضوح إن المشروع ليس خطة لاستبدال البشر. الفكرة أن يعمل الطرفان في المساحة نفسها، مع بقاء المراجعة والموافقة والسجل جزءًا من النظام.
هذا مهم لأن امتلاك الوكيل القدرة على تعديل كود وتشغيل Workflow يرفع قيمة الخطأ المحتمل. وجود هوية مستقلة لكل Agent يجعل من السهل تحديد نطاقه ومراجعة ما فعله بدل أن تختلط أفعاله بحساب إنسان أو Token واحد يستخدمه الجميع.
لمن يناسب المشروع؟
يبدو Buzz مناسبًا بدرجة أكبر لفرق البرمجة التي بدأت بالفعل في استخدام وكلاء AI داخل عملها اليومي وتشعر أن Slack وGitHub وCI والوكلاء أصبحت جزرًا منفصلة. هنا تصبح فكرة توحيد هذه الطبقات جذابة بالفعل.
أما فريق صغير يستخدم GitHub ومحادثة بسيطة ولا يحتاج إلى وكلاء مستقلة أو استضافة ذاتية، فقد يجد تشغيل Relay وقواعد البيانات والبنية المصاحبة تعقيدًا أكبر من الفائدة. قيمة المشروع تظهر عندما تكون ذاكرة الفريق وسير العمل والوكلاء جزءًا حقيقيًا من العملية اليومية.
ترخيص مفتوح وكود يمكن مراجعته
المشروع منشور بترخيص Apache 2.0، ويضم المستودع كود Relay وتطبيق سطح المكتب وأدوات CLI وطبقات الوكلاء وسير العمل. وتتبنى Block بصورة أوسع سياسة واضحة تجاه المصادر المفتوحة، ولديها مشروعات أخرى في مجال الوكلاء مثل Goose.
لهذا يمكن دراسة البنية حتى لو لم تكن تريد استبدال مساحة العمل الحالية بالكامل. طريقة إدارة هويات البشر والوكلاء، واستخدام Nostr كسجل أحداث، وربط Git والبحث والتدقيق في Relay واحد تقدم أفكارًا مثيرة لأي مطور يبني أنظمة Agentic.
مشروع من شركة مؤسس تويتر.. لكنه ليس تويتر جديدًا
وجود جاك دورسي خلف Block يجعل المقارنة بتويتر مغرية، خصوصًا أن Buzz مبني حول الهويات والقنوات والأحداث الموقعة. لكن المشروع ليس محاولة لإنشاء شبكة اجتماعية عامة جديدة.
هو أقرب إلى مساحة عمل سيادية للفرق والمطورين ووكلاء AI. ملفات Twitter الرسمية القديمة تؤكد أن دورسي أحد مؤسسي الشركة، بينما Block نفسها تعرفه حاليًا بأنه المؤسس المشارك ورئيس مجلس الإدارة وBlock Head. لكن المشروع الجديد يأخذ خبرة منصات التواصل في اتجاه مختلف: التعاون الداخلي بين البشر والبرمجيات التي تعمل معهم.
هل يستحق Buzz التجربة الآن؟
إذا كنت مهتمًا بمستقبل العمل مع وكلاء الذكاء الاصطناعي، يقدم Buzz فكرة أكثر طموحًا من إضافة Chatbot إلى Slack. البشر والوكلاء لهم هوية، والأحداث موقعة، والمشروع يحتفظ بذاكرته، وGit وWorkflows والمحادثات تجتمع داخل Relay واحد.
لكن يجب إبقاء عبارة مهمة من المشروع نفسه في الاعتبار: المنتج غير مكتمل بعد. فهو ما زال قبل الإصدار 1.0، وبعض قدراته موجودة فعليًا بينما بعضها الآخر لا يزال قيد الربط أو في مرحلة الرؤية.
لذلك تبدو التجربة على مشروع أو فريق صغير أفضل نقطة بداية قبل نقله إلى بيئة حساسة. ويمكن تنزيل التطبيق ومراجعة الكود والتوثيق والإصدارات مباشرة من مستودع Buzz الرسمي على GitHub.
لا يسمح بنقل هذا المحتوى من سوالف دون الاشارة برابط مباشر





