🤖 AI

LACUNA: Safe Agents as Recursive Program Holes

تُعدُّ LACUNA نموذج برمجة آمنًا لوكلاء النماذج اللغوية الكبيرة (LLMs)، حيث تعامل الأفعال كفجوات برمجية ذات أنواع محددة يملؤها النموذج ويتم التحقق منها عبر فحص الأنواع الساكن قبل التنفيذ، مما يوحد تدفق التحكم الخاص بالوكيل مع الكود المُولَّد مع منع حالات الفشل عند التشغيل وتقييد الوصول إلى الأدوات.

المؤلفون الأصليون: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

نُشر 2026-05-28

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك المدير التنفيذي لشركة، وقد وظفت مساعداً عبقرياً ولكنه غير موثوق به قليلاً (الذكاء الاصطناعي) للقيام بعملك.

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

المشكلة:
أحياناً، يرتبك المساعد بسبب ملاحظة مخادعة كتبتها أنت ("حقن الأوامر" أو prompt injection)، أو قد يرتكب خطأً في منتصف المهمة، مما يترك المكتب في حالة فوضوية وغير متسقة. ولأن المساعد مسموح له فقط بضغط الأزرار، فقد لا يستطيع تدمير المبنى، لكنه لا يزال قادراً على إحداث الكثير من الفوضى داخل الغرفة التي يتواجد فيها.

الطريقة الجديدة (LACUNA):
تقدم ورقة البحث LACUNA، التي تغير هذه العلاقة. بدلاً من إعطاء المساعد زراً واحداً ليضغطه، أنت تعطيه مساحة فارغة في عقد ("ثغرة نمطية" أو typed hole) وتقول له: "املأ هذه المساحة بأي كود تحتاه لحل هذه المشكلة، ولكن يجب أن يتناسب تماماً مع عقدنا القانوني".

إليك كيف يعمل ذلك، باستخدام تشبيهات بسيطة:

1. "العقد السحري" (الثغرات النمطية - Typed Holes)

تخيل أن لديك عقداً يقول: "يجب أن تكون النتيجة النهائية لهذا القسم عبارة عن قائمة من الأرقام".

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

2. قاعدة "الكل أو لا شيء"

في الطريقة القديمة، إذا حاول الذكاء الاصطناعي "حذف ملف" ثم "حساب مجموع"، وفشل الحساب، فقد يكون الملف قد حُذف بالفعل.
في LACUNA، الأمر يشبه كتلة واحدة غير قابلة للتجزئة من الطين.

ينحت الذكاء الاصطناعي الكتلة بأكملها.
يقوم المفتش بفحص الكتلة بأكملها دفعة واحدة.
إذا كان أي جزء من المنحوتة خاطئاً (الشكل خاطئ، أو المادة خاطئة)، يتم رمي الكتلة بأكملها. لا يحدث شيء. يظل المكتب تماماً كما كان قبل بدء الذكاء الاصطناعي. هذا يمنع الكوارث "نصف المكتملة".

3. "حلقة المفاتيح" (القدرات - Capabilities)

تتحدث الورقة أيضاً عن القدرات. تخيل أن الذكاء الاصطناعي مُنح مجموعة محددة من المفاتيح (حلقة مفاتيح) للوظيفة.

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

4. "الدمى الروسية المتداخلة" (التكرار - Recursion)

يمكن للذكاء الاصطناعي كتابة كود يتضمن مزيداً من التعليمات لنفسه.

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

ما وجده البحث فعلياً

اختبر الباحثون هذا النظام (LACUNA) باستخدام لغة برمجة تسمى Scala 3.

السلامة: وجدوا أن "المفتش" كشف حوالي 8.6% من محاولات الذكاء الاصطناعي قبل تشغيلها. كانت هذه المحاولات إما ذات شكل خاطئ أو حاولت استخدام أدوات لم يكن للذكاء الاصطناعي إذن باستخدامها.
إعادة المحاولة: عندما يرتكب الذكاء الاصطناعي خطأً، يطلب منه النظام المحاولة مرة أخرى. في المتوسط، استغرق الأمر 0.7 محاولة فقط للحصول على إجابة صالحة.
الأداء: حل النظام حوالي 27% من المهام البحثية الصعبة و 76% من مهام خدمة العملاء. كان هذا مساوياً تقريباً للوكلاء التقليديين الآخرين، مما أثبت أن إضافة هذا الفحص الصارم للسلامة لم يجعل الذكاء الاصطناعي "أغبى"، بل جعله أكثر أماناً فحسب.
الأمن: اختبروا النظام ضد المخترقين الذين يحاولون خداع الذكاء الاصطناعي (حقن الأوامر). وبسبب محدودية الذكاء الاصطناعي بـ "حلقة المفاتيح" (القدرات)، لم يتمكن المخترقون من جعل الذكاء الاصطناعي يقوم بأشياء خارج نطاق المسموح به، حتى لو نجحوا في خداع الذكاء الاصطناعي لمحاولة القيام بذلك.

العقبات (القيود)

تعترف الورقة ببعض النقاط:

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

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

ملخص تقني: LACUNA: وكلاء آمنون كفجوات برمجية تكرارية

بيان المشكلة

تواجه وكلاء النماذج اللغوية الكبيرة (LLMs) الحالية انقساماً معمارياً جوهرياً بين وقت التشغيل (runtime) الذي يقود حلقة الوكيل، وبين الكود الذي يكتبه النموذج. في النهج السائدة مثل ReAct، يمتلك وقت التشغيل التحكم في تدفق السيطرة، وإدارة السياق، وتوزيع الأدوات، بينما يكتفي النموذج بإصدار استدعاءات أدوات فردية أو خطوات استدلالية. وفي الوكلاء الذين يعتمدون نهج "الكود كفعل" (code-as-action)، يكتب النموذج كوداً لتركيب الأدوات والمنطق، لكن هذا الكود يظل منفصلاً عن وقت التشغيل.

يخلق هذا الانفصال معضلة أمان؛ فإذا سيطر وقت التشغيل بصرامة على الحلقة، يفتقر الوكيل إلى القدرة التعبيرية. أما إذا قام النموذج بتشكيل وقت التشغيل نفسه لزيادة القدرة التعبيرية، فإن مخاطر الأمان تتصاعد: فالنموذج الذي يتم حرف مساره بواسطة حقن الأوامر (prompt injection)، أو خطأ في استدعاء أداة، أو فشل جزئي، يمكن أن يترك البيئة في حالة غير متسقة أو يعرض وقت التشغيل للخطر. إن الدفاعات الحالية (مثل الصناديق الرملية، أو المترجمات المقيدة، أو لغات السياسات) غالباً ما تكون مجزأة، وتعمل عند وقت التشغيل أو على المدخلات، ولا يوجد منها ما يتحقق من "فعل كامل" مولد مقابل سياق البرنامج المحيط قبل بدء التنفيذ.

المنهجية: LACUNA

يقترح المؤلفون LACUNA، وهو نموذج برمجي يغلق الفجوة بين وقت تشغيل الوكيل والكود الذي يكتبه النموذج مع الحفاظ على الأمان من خلال النوعية الثابتة (static typing). البدائية الأساسية هي "فجوة" (hole) محددة النوع داخل البرنامج المضيف:

def agent[T](task: String): T

الآلية الجوهرية

الفجوات المحددة النوع (Typed Holes): يعمل استدعاء الوكيل كفراغ يتوقع البرنامج المحيط منه قيمة من النوع T. يُطلب من النموذج اللغوي الكبير توليد كود Scala ينتج هذه القيمة.
الترجمة الواعية للسياق (Context-Aware Compilation): عندما يصل التنفيذ إلى استدعاء agent ، يقوم النموذج بتوليد كود بناءً على المهمة باللغة الطبيعية task والنوع المتوقع T والنطاق المعجمي الحي (المتغيرات، الدوال، الأدوات، والواردات المتاحة في تلك النقطة تحديداً).
التحقق ما قبل التنفيذ: يتم ترجمة الكود المولد بواسطة المترجم المضيف (Scala 3) في سياق البرنامج المحيط قبل تشغيله.
- التحقق من النوع (Type Checking): يجب أن ينتج الكود قيمة من النوع T.
- التحقق من النطاق (Scope Checking): يجب أن تكون جميع الأسماء المستخدمة ضمن النطاق.
- التحقق من القدرات (Capability Checking): إذا تم تفعيله، يضمن فحص الالتقاط (capture checking) أن الكود لا يصل إلا إلى الموارد (الملفات، الشبكة، الأدوات) الممنوحة صراحة في النطاق المعجمي.
التنفيذ "الكل أو لا شيء": إذا اجتاز الكود جميع الفحوصات، يتم تنفيذه. إذا فشل (على سبيل المثال: عدم تطابق النوع، أداة مفقودة، وصول غير مصرح به)، يُرفض المقطع البرمجي بالكامل. لا يحدث تنفيذ جزئي، مما يمنع الحالات غير المتسقة. تُغذى تشخيصات المترجم مرة أخرى إلى النموذج اللغوي لدفع حلقة إعادة المحاولة.

التنفيذ

تم بناء النموذج الأولي باستخدام Scala 3، بالاستفادة من ميزتين محددتين:

إعادة الترجمة داخل العملية (In-process recompilation): القدرة على استدعاء المترجم داخل برنامج يعمل لدمج وترجمة سلسلة من الكود المصدري مقابل السياق الحالي.
فحص الالتقاط (Capture Checking): آلية لتتبع التأثيرات والموارد التي يُسمح لمقطع الكود باستخدامها، مما يفرض أماناً قائماً على القدرات.

تعد البدائية agent غلافاً رقيقاً حول عملية eval منخفضة المستوى. فهي تدير بناء المطالبة (بما في ذلك المصدر المحيط والارتباطات المتاحة)، وتستدعي النموذج اللغوي الكبير، وتمرر النتيجة إلى eval، وتتعامل مع حلقة إعادة المحاولة عند فشل الترجمة.

المساهمات الرئيسية

نموذج "الكود كفعل" مع ضمانات ثابتة: نموذج حيث يكتب الوكيل أفعاله ككود يعمل كجزء من وقت تشغيله الخاص، ويتم التحقق منه عند موقع الاستدعاء قبل التنفيذ.
تحليل الأمان: يثبت أن الرفض المسبق للأسماء غير المتوفرة وعدم تطابق الأنواع، جنباً إلى جنب مع التنفيذ الذري (لا توجد عمليات تشغيل جزئية)، يوفر ضمانات أمان قوية. كما يوضح كيف يحد نطاق القدرات من سلطة الوكيل وتدفق المعلومات.
القدرة التعبيرية عبر تدفق السيطرة العادي: يوضح أن استدعاءات الوكيل المتداخلة وبنى الكود القياسية يمكن أن تعبر عن أنماط الوكلاء المعقدة (حلقات ReAct، الوكلاء الفرعيين، المهارات، التفكيك المتوازي، التخطيط متعدد النماذج) دون الحاجة إلى بروتوكول وكيل منفصل.
التقييم التجريبي: تطبيق واقعي بلغة Scala 3 تم تقييمه باستخدام حالات اختبار التحقق، و BrowseComp-Plus (البحث عن المعلومات الصعبة)، و $\tau^2$ -bench (المحادثات متعددة الخطوات باستخدام الأدوات).

النتائج

يسلط التقييم الضوء على المقايضة بين الأمان، والقدرة التعبيرية، وقدرة النموذج:

الأمان ومعدلات الرفض: في BrowseComp-Plus، تم رفض 8.6% من العمليات المولدة قبل التنفيذ بسبب أخطاء في النوع أو النطاق. بلغ متوسط عدد محاولات إعادة المحاولة 0.7 لكل استعلام، مع معدل نجاح ترجمة نهائي بنسبة 91.4%. وهذا يؤكد أن المترجم يحجب بفعالية الأفعال غير الصحيحة النوع أو الخارجة عن النطاق.
الأداء في المهام المعقدة:
- BrowseComp-Plus: باستخدام نموذج deepseek-flash ، حقق LACUNA دقة بنسبة 27.1%، وهي مقاربة للوكلاء الأساسيين، مع دفع بحث حقيقي متعدد الخطوات (متوسط 5.9 جولة، و15.5 عملية بحث).
- $\tau^2$ -bench: عبر 392 مهمة في أربعة مجالات (التجزئة، الطيران، الاتصالات، والاتصالات اللاسلكية)، حلَّ LACUNA 76.0% من المهام باستخدام نموذج كفء، مما جعله على قدم المساواة مع وكيل استدعاء الأدوات المرجعي.
الاعتماد على النموذج: يعتمد نجاح النظام بشكل كبير على قدرة النموذج على البرمجة. فالنماذج الأضعف (مثل gemini-3.1-flash-lite) واجهت صعوبات في المجالات المعقدة (معدل رفض بنسبة 89% في مجال الاتصالات)، مما أدى إلى انخفاض معدلات الحل. تظل ضمانة الأمان قائمة بغض النظر عن كفاءة النموذج (المحاولات المكسورة لا تعمل أبداً)، ولكن التقدم يتوقف إذا لم يستطع النموذج توليد كود صالح.
المتانة ضد الهجمات (Adversarial Robustness): في اختبارات حقن الأوامر (AgentDojo)، نجحت طبقة القدرات في حصر أفعال الوكيل ضمن نطاقه الممنوح. حتى عند التأثر بالمحتوى المحقون، لم يستطع الوكيل الوصول إلى الموارد خارج نطاقه المعجمي.

الأهمية والادعاءات

تضع الورقة البحثية LACUNA ليس كبديل لهياكل الوكلاء الحالية، بل كـ أساس أكثر أماناً ومرونة.

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

باختصار، يقترح LACUNA أن معاملة أفعال الوكيل كـ فجوات محددة النوع في لغة مضيفة ذات نوع ثابت يسمح بتصميم وكيل تكراري وتعبيري، حيث يتم ضمان الأمان من خلال سلامة المترجم بدلاً من الاستدلالات في وقت التشغيل.