Causal Past Logic for Runtime Verification of Distributed LLM Agent Workflows
تقدم هذه الورقة "منطق الماضي السببي" (CPL)، وهو منطق زمني على مستوى المصدر مدمج في إطار عمل "ZiZiGen"، والذي يُمكّن وكلاء النماذج اللغوية الكبيرة (LLMs) الموزعين من إجراء التحقق من صحة وقت التشغيل لتدفق التحكم بناءً على الأحداث المرئية سببيًا بدلاً من السجلات التسلسلية، وذلك باستخدام مراقب ساعة المتجهات لضمان الصحة الدلالية.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل فريقاً من الوكلاء البرمجيين المتخصصين (AI agents) يعملون معاً على مشروع ضخم، مثل مراجعة قطعة من الكود البرمجي قبل دمجها في نظام برمجيات. في الطريقة القديمة للتفكير، قد نتخيل هؤلاء الوكلاء وهم يتحدثون مع بعضهم البعض في خط محادثة واحد مثالي، مثل نص مكالمة هاتفية حيث يسمع الجميع كل شيء بنفس الترتيب تماماً.
لكن في الواقع، هؤلاء الوكلاء يشبهون أشخاصاً يعملون في مناطق زمنية مختلفة بشكل غير متزامن. فهم يرسلون الرسائل، ويقومون بعملهم الخاص، ويتخذون القرارات بسرعات متفاوتة. أحياناً، يتخذ الوكيل (أ) قراراً بناءً على رسالة تلقاها، دون أن يدرك أن الوكيل (ب) قد اكتشف بالفعل خطأً حرجاً وأرسل رسالة جديدة لم تصل بعد إلى مكتب الوكيل (أ).
تقدم هذه الورقة البحثية طريقة جديدة للتعامل مع هذه القرارات حتى لا يرتكب الفريق أخطاءً بناءً على معلومات ناقصة أو قديمة. إليك تفصيل ذلك باستخدام تشبيهات بسيطة:
المشكلة: صندوق البريد "خارج الترتيب"
تخيل أنك مدير (الـ "Committer") تنتظر تقارير من مفتشين: "مشغل الاختبارات" (Test Runner) و"حارس الأمن" (Security Guard).
- الفخ: تتلقى تقريراً يقول "اجتازت الاختبارات". أنت على وشك الموافقة على المشروع.
- الواقع: حارس الأمن وجد بالفعل ثغرة كبيرة بعد اجتياز الاختبار، لكن تقريره الجديد لا يزال عالقاً في البريد.
- الخطأ: إذا نظرت فقط إلى قائمة بسيطة من الرسائل حسب ترتيب وصولها، فقد تعتقد أن كل شيء على ما يرام. ولكن إذا نظرت إلى الواقع "السببي" (ما تعرفه بالفعل في هذه اللحظة تحديداً)، فأنت لا تعرف بوجود الثغرة بعد.
تجادل الورقة بأنه لا ينبغي لنا الحكم على قرارات الفريق بناءً على "سجل عالمي مثالي" لكل ما حدث. بدلاً من ذلك، يجب أن نحكم عليهم بناءً على ما هو مرئي سببياً للشخص الذي يتخذ القرار في هذه اللحظة.
الحل: "منطق الماضي السببي" (CPL)
ابتكر المؤلفون "لغة" جديدة يستخدمها الوكلاء عند اتخاذ القرارات. فكر في هذا كأنه قائمة مراجعة ذكية يمكن للوكيل قراءتها قبل الضغط على زر "موافقة".
بدلاً من مجرد السؤال: "هل تلقيت رسالة 'نجاح'؟"، يسأل الوكيل:
"هل رأى مشغل الاختبارات سببياً أن الاختبارات قد نجحت، وهل رأيتُ أنا سببياً أي رسالة تقول إنها فشلت منذ ذلك الحين؟"
يسمح هذا المنطق للوكيل بأن يقول: "أرى رسالة 'النجاح'، ولم أرَ رسالة 'الفشل' بعد، لذا يمكنني المضي قدماً". كما يسمح لهم بالتحقق من تفاصيل محددة، مثل: "هل رسالة 'النجاح' هذه تتعلق بنفس نسخة الكود التي أنظر إليها الآن؟"
كيف يعمل الأمر: حقيبة ظهر "الساعة المتجهة" (Vector Clock)
لجعل هذا يعمل دون الحاجة إلى مدير مركزي يراقب الجميع، يحمل كل وكيل حقيبة ظهر (تسمى "الساعة المتجهة" أو Vector Clock).
- في كل مرة يقوم فيها الوكيل بشيء ما أو يستقبل رسالة، يقوم بتحديث حقيبة ظهره.
- عندما يرسل رسالة إلى صديق، فإنه يضع حقيبة ظهره داخل الظرف.
- عندما يستلم الصديق الظرف، يقوم بفتح الحقيبة ودمج حقيبة المرسل مع حقيبته الخاصة.
تخبر هذه الحقيبة الوكيل بالضبط: "أنا أعرف عن 3 أشياء قام بها مشغل الاختبارات، وعن شيئين قام بهما حارس الأمن". لا يهم إذا وصلت الرسائل متأخرة؛ فالحقيبة تضمن للوكيل معرفة المعلومات المتاحة له في هذه اللحظة المحددة.
آلية "الحارس" (The Guard)
في هذا النظام، "الحارس" ليس حارس أمن يقف خارجاً يتحقق من سجل الأحداث بعد وقوعه. الحارس هو قاعدة مكتوبة مباشرة في سير العمل.
- الطريقة القديمة: يعمل سير العمل، ينتهي، ثم يقوم مراقب بالتحقق من: "مهلاً، لقد ارتكبت خطأ لأنك فاتتك رسالة!" (فات الأوان للإصلاح).
- الط maneira الجديدة (CPL): يتوقف سير العمل عند نقطة اتخاذ القرار. يتحقق الوكيل من قاعدة "المنطق الماضي السببي" الخاصة به. إذا قالت القاعدة: "لم أرَ الفشل الأخير"، فإن سير العمل يتوقف تلقائياً ويطلب إعادة التحقق. هذا يمنع الخطأ قبل وقوعه.
مثال من الواقع: مراجعة الكود
تستخدم الورقة سيناريو مراجعة الكود لإثبات نجاح هذا الأسلوب:
- الإعداد: ينتظر الـ "Committer" كلاً من "مشغل الاختبارات" و"وكيل الأمن".
- السيناريو: يقول مشغل الاختبارات "نجاح". الـ "Committer" مستعد لدمج الكود.
- التحول المفاجئ: يكتشف مشغل الاختبارات لاحقاً حالة فشل، لكن هذه الرسالة لم تصل بعد إلى الـ "Committer".
- النتيجة: لأن الـ "Committer" يستخدم CPL، فإنه ينظر إلى "ماضيه السببي". يرى رسالة "النجاح"، ولا يرى رسالة "الفشل" (لأنها لم تصل بعد). لذا، يمضي قدماً.
- أليس هذا خطيراً؟ تقول الورقة: لا. السياسة هي "ادمج إذا لم تكن قد رأيت فشلاً". لو كانت رسالة الفشل قد وصلت، لكان "الحارس" قد منع عملية الدمج. وإذا وصلت رسالة الفشل لاحقاً، فقد صُمم النظام للتعامل مع ذلك (ربما عبر إعادة التحقق لاحقاً)، ولكن لا ينبغي لوم الـ "Committer" على عدم معرفة المستقبل.
الملخص
تقدم هذه الورقة للوكلاء البرمجيين الموزعين طريقة لاتخاذ قرارات ذكية وآمنة بناءً على ما يعرفونه فعلياً في هذه اللحظة، بدلاً من ما سيعرفه مراقب مثالي لاحقاً. وهي تستخدم نظام "حقيبة الظهر" لتتبع تدفق المعلومات ولغة منطقية خاصة لضمان أن الوكلاء لا يتحركون للأمام إلا عندما يدعمهم الدليل السببي. هذا يحول مراقبة وقت التشغيل من "تشريح للجثة" (النظر في الجثة بعد وقوع الجريمة) إلى "إشارة مرور" (إيقاف السيارة قبل وقوع التصادم).
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.