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

نشر موقع Habr تحليلًا لإطار zymi، وهو إطار تجريبي لبناء أنظمة متعددة الوكلاء على غرار dbt. وبدلًا من التنسيق اليدوي والحالة المتغيرة المشتركة (mutable state)، يقترح المؤلف ملفات YAML تصريحية وناقل بيانات قائمًا على event sourcing، حيث تُسجَّل كل خطوة يقوم بها الوكيل كحدث مستقل.

كيف يعمل zymi

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

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

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

«توليد yaml وفق مخطط json صارم أسهل بمراحل بالنسبة للنماذج».

لماذا event sourcing

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

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

ما الذي ينتظر المشروع

يذكر المؤلف صراحةً أن zymi ما يزال في مرحلة ألفا، وأنه يُنظر إليه كأداة للنمذجة الأولية والتجارب. ومع ذلك، حدّد المشروع بالفعل قائمة مهام (backlog) كبيرة: الانتقال إلى libsql مع ذاكرة متجهية ونسخ متماثلة على الحافة (edge replicas)، ودعم PostgreSQL كناقل بيانات، وربط أدوات Python بشكل تصريحي، وتحسين إسقاطات الحوارات (projections) لإعادة التشغيل المتكافئ (idempotent)، وبثّ ردود LLM بشكل متدفق (streaming). كما يريد المؤلف مقارنة خط وكلاء واحد بعينه على LangGraph وzymi، للتحقق من أيهما يحتاج إلى تكرارات ورموز (tokens) أقل.

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

ماذا يعني ذلك

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