Block Buzz: مساحة عمل وكلاء الذكاء الاصطناعي حيث الوكلاء زملاء لا روبوتات

Block Buzz: مساحة عمل وكلاء الذكاء الاصطناعي حيث الوكلاء زملاء لا روبوتات

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

تلك الفكرة هي Buzz، مساحة عمل مفتوحة المصدر من Block, Inc. جذبت بالفعل نحو 18٬000 نجمة على GitHub. في Buzz، يتشارك البشر ووكلاء الذكاء الاصطناعي القنوات نفسها، ويوقّعون إجراءاتهم بنوع المفتاح التشفيري نفسه، وينتهون في السجل القابل للبحث نفسه. مكتوبة بلغة Rust ومرخّصة تحت Apache 2.0. قضيت وقتًا في قراءة وثائق معمارية المستودع حتى لا تضطر أنت لذلك، وخيارات التصميم أكثر إثارة للاهتمام مما يوحي به التسويق.

ما هو Block Buzz؟

Buzz هي مساحة عمل قابلة للاستضافة الذاتية من Block, Inc. حيث يتشارك البشر ووكلاء الذكاء الاصطناعي القنوات نفسها. تعمل على مُرحِّل Nostr، بحيث تكون كل رسالة وتفاعل وتصحيح كود وموافقة وخطوة سير عمل حدثًا موقّعًا واحدًا في سجل واحد قابل للبحث ومقاوم للعبث. إنها مفتوحة المصدر تحت Apache 2.0، مبنية بلغة Rust، وأنت تشغّل المُرحِّل بنفسك.

أبرز النقاط:

• الوكلاء أعضاء من الدرجة الأولى بمفاتيحهم الخاصة وسجل تدقيقهم الخاص، لا روبوتات مثبّتة على الجانب.
• كل شيء (المحادثة، التصحيحات، التكامل المستمر، الموافقات) حدث Nostr موقّع واحد في سجل واحد قابل للبحث.
• يرتبط الوكلاء عبر ACP و MCP، لذا يعمل Goose و Codex و Claude Code مباشرة دون إعداد.
• مستضافة ذاتيًا ومفتوحة المصدر (Apache 2.0)، مع قائمة صادقة وعامة بما لم يُنجز بعد.

العبارة التي يعتمد عليها المشروع هي "a hive mind communication platform". يبدو ذلك ضخمًا، لكن واقع الاستخدام اليومي أبسط: تشعر وكأنها مساحة عمل فريق. قنوات، مواضيع، رسائل مباشرة، لوحة، تجمعات صوتية، بحث. المفاجأة فيما تحتها. كل إجراء هو حدث Nostr موقّع، ومؤلف ذلك الحدث يمكن أن يكون شخصًا أو عملية. الشكل نفسه، ونموذج الهوية نفسه، وسجل التدقيق نفسه في كلتا الحالتين.

إذا كنت تقارن أطر عمل الوكلاء مثل LangGraph و CrewAI و OpenAI Agents SDK، فإن Buzz طبقة مختلفة تمامًا. تلك مكتبات تضمّنها في الكود لتنظيم استدلال الوكيل. Buzz هي الغرفة التي يتحدث فيها الوكيل وفريقك، ويتسلمان العمل، ويتركان سجلًا. إنها متكاملة لا متنافسة.

لماذا يغيّر "الوكلاء كأعضاء" النموذج

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

Buzz تقلب هذا. يحصل الوكيل على زوج مفاتيحه الخاص، وعضويات قنواته الخاصة، وسجل تدقيقه الخاص. تضيف وكيلًا إلى قناة بالطريقة نفسها التي تضيف بها شخصًا. يصف المشروع تحديد النطاق بأنه "by identity, not by permission flags"، وهي الطريقة نفسها التي تحدد بها نطاق زميل بشري. تثق بهم في بعض الغرف ولا تثق في غيرها.

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

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

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

كيف يرتبط الوكلاء فعليًا: ACP و MCP

هنا تصبح الهندسة نظيفة. تشحن Buzz ملفين تنفيذيين صغيرين للوكلاء، وهما لا يعرفان بعضهما عمدًا.

buzz-agent هو وكيل ACP. يتحدث Agent Client Protocol عبر stdio، ويستدعي نموذج لغة كبيرًا، ويستخدم أدوات MCP. يشغّل حتى ثماني جلسات متزامنة، كل منها بخوادم MCP الخاصة بها وسجلها وسياقها. عندما يمتلئ سياق جلسة، تلخّص سجلها الخاص وتستمر. تعمل مع Zed أو JetBrains أو أي شيء آخر يتحدث ACP.

buzz-dev-mcp هو خادم MCP. يمنح أي وكيل غلاف أوامر ومحرر ملفات. العمليات عابرة مع قتل مجموعة العمليات عند كل مسار خروج، والإخراج محدود، وتُحل تعديلات الملفات نسبةً إلى دليل العمل. إذا كنت قد بنيت من قبل باستخدام Model Context Protocol، فسيبدو هذا مألوفًا: إنه النمط القياسي "امنح الوكيل يدين"، بعد تقويته.

تضع مذكرة التصميم في المستودع الأمر بصراحة: "two binaries, two protocols, no coupling between them." لا يعرف الوكيل أي خادم MCP يتحدث إليه، ولا يعرف خادم MCP أي وكيل يستدعيه. يتألفان عبر البروتوكولات لا عبر الاستيرادات. العائد العملي هو أنك تستطيع تشغيل عشرة وكلاء خلف Buzz بإعدادات MCP مختلفة، أو تبديل مزوّد نموذج اللغة الكبير بمتغير بيئة واحد.

لأن buzz-acp يجسر @mentions المُرحِّل إلى العمليات الفرعية للوكلاء، يمكنك توجيهه إلى Goose أو Codex أو Claude Code. إذا كنت تشغّل بالفعل وكلاء ترميز في الخلفية، فإن Buzz تمنحهم غرفة مشتركة للعمل فيها بدلًا من حلقة صامتة بلا واجهة. وإذا أردت إحضار أدواتك الخاصة، فإن بناء خادم MCP هو المسار المدعوم، مع وفرة من خوادم MCP الجاهزة للبدء منها.

تحت الغطاء: البنية المعمارية

Buzz مستودع أحادي بلغة Rust، والحقيقة الأهم هي هذه: المُرحِّل هو مصدر الحقيقة الوحيد. لا يوجد ثرثرة ندّية ولا تكرار. يتصل العملاء بمُرحِّل واحد عبر WebSocket، ويتولى المُرحِّل المصادقة، ويتحقق من التوقيعات، ويخزّن الأحداث، ويوزعها على المشتركين، ويفهرسها للبحث، ويطلق الأتمتة.

كل شيء حدث Nostr NIP-01. لكل حدث ستة حقول: id (‏SHA-256 للحدث المُسلسَل)، وpubkey، وعدد صحيح kind، ووسوم، ومحتوى، وتوقيع Schnorr. العدد الصحيح kind هو مفتاح التوجيه الوحيد. تريد ميزة جديدة؟ عرّف رقم kind جديدًا. العملاء الحاليون لا يرون شيئًا ولا ينكسر شيء. تحدّد قاعدة الكود 81 نوع kind، وتعيش أنواع Buzz المخصصة في النطاق 40000-49999.

المكدس الداعم ممل عمدًا، بأفضل معنى:

يحتفظ Postgres بالأحداث ويشغّل البحث النصي الكامل. يتولى Redis توزيع pub/sub والحضور والكتابة. يحتفظ التخزين الكائني المتوافق مع S3 (‏MinIO محليًا) بالوسائط عبر بروتوكول Blossom.

نموذج الأمان هو المكان الذي توقفت فيه عن التصفح السريع. يُتحقق من توقيع Schnorr ومعرّف SHA-256 لكل حدث قبل التخزين. تستخدم مصادقة NIP-42 تفاوت طابع زمني قدره ±60 ثانية لمنع هجمات إعادة التشغيل، ولا تُخزَّن أحداث المصادقة أو تُدقَّق أبدًا. سجل التدقيق سلسلة تجزئة حقيقية: يغطي SHA-256 لكل قيد كل حقل بما في ذلك التجزئة السابقة، بحيث إن العبث بقيد واحد يكسر كل قيد بعده. تحصل خطافات الويب الصادرة على حماية SSRF تتحقق من نطاقات IP الخاصة. وعضوية القناة هي بوابة الوصول الوحيدة، المطبّقة عند كل عملية، حيث يتحقق معالج الاشتراك من الوصول قبل تسجيل الاشتراك فلا توجد نافذة سباق لتسريبات القنوات الخاصة.

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

ما الذي يعمل اليوم (وما الذي لا يعمل)

المشروع صادق بشكل غير معتاد بشأن حالته، وأعتقد أن هذا الصدق هو أقوى إشارة على قاعدة كود جادة. إليك الحالة الحالية مباشرة من المستودع:

الآن الجزء الذي تتخطاه معظم مقالات المنتج. تسرد وثيقة المعمارية فجوات موثقة لا طموحات:

• لا يُطبَّق أي تحديد للمعدل بعد. سمة RateLimiter موجودة وصُممت أربع فئات (human، agent-standard، agent-elevated، agent-platform)، لكن التنفيذ الوحيد هو stub اختبار.
• بوابات الموافقة غير موصولة من الطرف إلى الطرف. يستطيع المنفّذ تعليق تشغيل، لكن سير العمل الذي يصطدم ببوابة موافقة يُعلَّم حاليًا كفاشل.
• بعض إجراءات سير العمل معطّلة (stub). يعيد send_dm وset_channel_topic القيمة "not implemented"، لذا يفشل التشغيل الذي يصل إلى أحدهما.
• تسجيل التجمعات والنشر لكل مسار غير مبنيين. تعمل الغرف الصوتية ودورة حياة الانضمام/المغادرة؛ للتسجيل أنواع أحداث محجوزة لكن بلا منتج.
• لا توجد ذاكرة استعلامات sqlx بلا اتصال. تعمل الاستعلامات في وقت التشغيل بدل التحقق منها في وقت الترجمة.

لا شيء من هذا مُسقِط لأداة مستضافة ذاتيًا تقيّمها، لكنه يخبرك بالضبط أين الحواف. إذا كنت تحتاج إلى تقييم الوكلاء في الإنتاج بضمانات صارمة، فعامِل عمودي 💭 و🚧 كتحذيرات حاملة.

البدء مع Buzz

هناك ثلاثة مسارات، بحسب من تكون.

تريد تجربته فحسب؟ احصل على نسخة مغلّفة من أحدث إصدار: ‏macOS ‏(.dmg)، ‏Linux ‏(.AppImage أو .deb)، أو Windows ‏(.exe). افتراضيًا يتصل بـ ws://localhost:3000، لذا ستظل تريد مُرحِّلًا يعمل.

تريد البناء من المصدر؟ تحتاج Docker وإما Hermit أو Rust ‏1.88+، ‏Node ‏24+، ‏pnpm ‏10+، وjust. ثم:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build

# every day:
. ./bin/activate-hermit
just dev   # starts the relay + desktop app together

يهبط المُرحِّل على ws://localhost:3000 ويظهر تطبيق سطح المكتب. لنشر VPS أحادي العقدة بدلًا من مكدس التطوير المحلي، توجد حزمة Compose إنتاجية تحت deploy/compose/ مع Postgres و Redis و MinIO و Caddy اختياري لـ TLS.

تحضر وكيلًا؟ اضبط BUZZ_PRIVATE_KEY واستخدم buzz-cli، وهو JSON داخل وJSON خارج، مصمم خصيصًا لاستدعاءات أدوات نماذج اللغة الكبيرة. تلك هي النقطة التي ترتبط بها سير عمل وكلائك.

من الذي ينبغي له تشغيل Buzz؟

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

إنها مناسبة جدًا لـ:

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

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

الإطار الذي أعود إليه باستمرار موجود في README: ‏"Agents are part of the room, not haunted cron jobs." إذا كنت قد صحّحت يومًا خطأ روبوت في الثانية فجرًا دون فكرة عما فعله أو لماذا، فأنت تعرف بالفعل لماذا يهم ذلك.

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

هل Buzz مجاني ومفتوح المصدر؟

نعم. Buzz مفتوحة المصدر تحت رخصة Apache 2.0 وبنيت بواسطة Block, Inc. تستضيف المُرحِّل بنفسك، لذا لا توجد رسوم لكل مقعد للبرنامج. تكاليفك هي بنيتك التحتية الخاصة: خادم للمُرحِّل، وPostgres، وRedis، وتخزين كائني. المصدر والمشكلات وخارطة الطريق كلها عامة على GitHub تحت block/buzz.

كيف يختلف Buzz عن Slack المزوّد بالروبوتات؟

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

ما هما ACP و MCP؟

ACP هو Agent Client Protocol، واجهة stdio التي يستخدمها buzz-agent للتحدث إلى عميل نموذج لغة كبير مثل Zed. MCP هو Model Context Protocol، الواجهة التي يستخدمها buzz-dev-mcp لمنح وكيل غلاف أوامر ومحرر ملفات. لا يعرف الملفان التنفيذيان بعضهما؛ يتألفان عبر البروتوكولات، لذا يمكنك مزج الوكلاء وخوادم الأدوات بحرية.

هل يستخدم Buzz تقنية البلوكتشين؟

لا، وREADME صريح بشأن ذلك: ‏"Not blockchain. Signed events are useful without making everyone buy a commemorative coin." تستخدم Buzz توقيعات Nostr التشفيرية وسجل تدقيق سلسلة تجزئة لإثبات مقاومة العبث، لكن لا يوجد رمز ولا سلسلة ولا آلية إجماع. تحصل على تاريخ قابل للتحقق دون العبء الإضافي.

هل يمكنني استخدام وكلاء الذكاء الاصطناعي الخاصين بي، مثل Goose أو Codex أو Claude Code؟

نعم. يولّد harness ‏buzz-acp عمليات فرعية لوكلاء الذكاء الاصطناعي ويجسر @mentions المُرحِّل إليها عبر ACP. يدعم Goose و Codex و Claude Code مباشرة، ويشغّل مجموعة من واحد إلى 32 عملية وكيل، ويعيد تشغيل الوكيل إذا انهار. للأدوات المخصصة، تربط خادم MCP الخاص بك.

هل Buzz جاهز للإنتاج؟

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

عن الكاتب

Mert Batur هو المؤسس المشارك لـ Techsy.io، حيث يشحن الفريق وكلاء الذكاء الاصطناعي وأنظمة الأتمتة وخطوط الصوت/SDR لعملاء B2B. يكتب عن مكدس أدوات نماذج اللغة الكبيرة الذي يستخدمه فريق Techsy فعليًا في الإنتاج. تواصل معه على LinkedIn.