إطار العمل zymi يقترح بناء وكلاء AI مثل مشروع dbt باستخدام YAML وevent sourcing

على Habr ظهر تحليل لـ zymi — إطار عمل تجريبي لبناء أنظمة متعددة الوكلاء بروح dbt. بدلاً من التنسيق اليدوي والحالة القابلة للتغيير المشتركة، يقترح المؤلف تكوينات YAML إعلانية و ناقل event-sourced، حيث يتم تسجيل كل خطوة من خطوات الوكيل كحدث منفصل.

كيفية عمل zymi

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

في zymi، ينقسم المشروع الأساسي إلى كيانات مألوفة: وكلاء وأدوات وذاكرة وأنابيب وملف project.yml مشترك. في مثال العرض التوضيحي، هناك وكيلان — باحث وكاتب، والأنابيب نفسها مهيكلة كـ DAG: يمكن لزوج من الخطوات أن يبدأ بالتوازي، والخطوات اللاحقة تعتمد على depends_on. يتم أيضاً وصف الأدوات بشكل إعلاني، على سبيل المثال كاستدعاءات HTTP مع معاملات ومفاتيح من متغيرات البيئة. يؤكد المؤلف أن هذا بالضبط ما يجعل النظام أكثر ملاءمة لنماذج اللغة: النماذج أبسط بكثير في توليد YAML وفقاً لمخطط صارم من كتابة كود تنسيق هش.

• يتم وصف الوكلاء بملفات YAML
• يمكن توصيل الأدوات كاستدعاءات HTTP
• يتم تجميع الأنابيب في DAG مع خطوات متوازية
• يتم التنفيذ والمراقبة عبر CLI

"توليد yaml وفقاً لمخطط json-schema صارم للنماذج أسهل بأوامر من حيث الحجم".

لماذا يكون Event Sourcing ضروري

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

النتيجة ليست مجرد سجل، بل سجل تنفيذ قابل للإعادة: يمكنك رؤية الخطوة التي بدأت وأي أداة تم استدعاؤها وما حاول الوكيل كتابته في الذاكرة والمكان الذي طلب فيه النظام الموافقة من بشر. يعتمد هذا النهج على الورقة الحديثة ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering، التي يعتبرها المؤلف أحد المصادر الرئيسية للإلهام. المنطق كالتالي: لا يغير الوكيل الحالة مباشرة، بل يعبر أولاً عن نية للقيام بشيء ما.

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

ما القادم للمشروع

يقول المؤلف بشكل مباشر أن zymi حالياً في مرحلة ألفا ويُنظر إليه كأداة للنماذج الأولية والتجارب. في الوقت نفسه، لدى المشروع بالفعل قائمة انتظار كبيرة: الانتقال إلى libsql مع الذاكرة المتجهة والنسخ المتماثلة على الحافة، ودعم PostgreSQL كناقل بيانات، والاتصال الإعلاني لأدوات Python، وتحسين إسقاطات الحوار لإعادة التشغيل القابلة للدعة، والبث المباشر لاستجابات نماذج اللغة. بشكل منفصل، يريد المؤلف مقارنة نفس خط أنابيب الوكيل على LangGraph و zymi للتحقق من حيث ستحتاج عدد أقل من التكرارات والرموز.

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

ماذا يعني هذا

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