ملخص تقني: التجميع عند التشغيل (JIT) للوكلاء: لتحسين زمن الاستجابة في تخطيط وجدولة وكلاء الويب

بيان المشكلة

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

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

لا تزال المحاولات الحالية لتحسين الأداء، مثل تصفية DOM الشرسة أو التعلم التعزيزي للنماذج الأصغر، تعتمد على مجموعات أدوات ثابتة وتنفيذ متسلسل، مما يفشل في استكشاف كامل مساحة جداول التنفيذ (بما في ذلك التوازي وتحوط الطلبات/request hedging) أو القضاء على استدعاءات الـ LLM غير الحتمية بين استدعاءات الأدوات.

المنهجية: التجميع عند التشغيل للوكيل (Agent JIT Compilation)

يقترح المؤلفون التجميع عند التشغيل للوكيل (Agent Just-In-Time Compilation)، وهو نظام يترجم التعليمات ذات اللغة الطبيعية عالية المستوى إلى كود قابل للتنفيذ ومحسن وقت تخليق الخطة. بخلاف الوكلاء القياسيين الذين ينفذون حلقة "لاحظ-فكر-تحرك"، يقوم هذا النظام بتجميع المهمة إلى رسم بياني لكود ثابت يدير استدعاءات الأدوات والاستدلال، مع اختيار الترجمة ذات التكلفة التقديرية الأدنى. تتكون البنية من ثلاثة مكونات أساسية:

1. بروتوكول الأدوات لفرض الثوابت (Invariant-Enforcing Tool Protocol)

لضمان صحة خطط الكود المولدة، يقدم النظام بروتوكولاً حيث تحدد كل أداة الشروط المسبقة والشروط اللاحقة (ثوابت الحالة).

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

2. المخطط المحسن للتكلفة (JIT-Planner)

يقوم المخطط بتوليد خطط كود مرشحة متعددة بالتوازي، ويتحقق منها مقابل بروتوكول الأداة، ويختار المرشح ذو التكلفة الأدنى.

• التوليد المتوازي: يقوم عدة عمال (workers) بأخذ عينات من خطط الكود من LLM في وقت واحد.
• التحقق القائم على الرسم البياني للتدفق التحكمي (CFG): يتم تحويل كل خطة إلى رسم بياني للتدفق التحكمي (CFG). يتتبع النظام الرسم البياني للتحقق من تدفق الحالة (التأكد من أن post للخطوة $i$ يستوفي pre للخطوة $i+1$) وتقدير التكلفة.
• نموذج التكلفة: يتم تجميع التكاليف بناءً على استدعاءات الأدوات واستدعاءات التقييم بالذكاء الاصطناğu (ai_eval). يتم تطبيق عقوبة التداخل ($\gamma$) لتجنب الحلقات المتداخلة التي تتضمن استدعاءات LLM مكلفة.
• النتيجة: يختار المخطط الخطة الصالحة ذات التكلفة الأقل، وغالباً ما يستبدل استدعاءات LLM غير الضرورية بمنطق برمجي بحت (على سبيل المثال، حساب الحد الأدنى للسعر في الكود بدلاً من سؤال الـ LLM).

3. المجدول الواعي بالتكلفة (JIT-Scheduler)

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

• المتسلسل (Serial): تنفيذ متتابع.
• المتوازي (Parallel): توازي المهام عبر $n$ من العمال.
• التحوط (Hedge): تنفيذ متوازٍ تخيلي حيث يقوم $n$ من العمال الفائضين بتشغيل نفس المهمة، ويتم إرجاع أول نتيجة صالحة.
• الآلية: باستخدام تقدير تكلفة مونت كارلو، يأخذ المجدل عينات من توزيعات زمن الاستجابة المتعلمة لعناصر DOM محددة (التي تم جمعها دون اتصال بالإنترنت). يتنبأ بالعناصر التي ستتفاعل معها الخطة ويقدر زمن الاستجابة المتوقع لكل استراتيجية، مختاراً الاستراتيجية ذات متوسط زمن الاستجابة الأدنى.

التخزين المؤقت دون الاتصال بالإنترنت (Offline Caching)

يعتمد النظام على عملية دون اتصال بالإنترنت لملء مستودعين:

1. مخزن المخطط المؤقت (Planner Cache): يربط الإجراءات عالية المستوى بكود أدوات قابل لإعادة الاستخدام ومتوافق مع البروتوكول (تم تخليقه من آثار التنفيذ).
2. مخزن المجدول المؤقت (Scheduler Cache): يربط عناصر مخطط الصفحة بتوزيعات زمن الاستجلة (التي تم ضبطها من آثار التنفيذ التاريخية).

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

1. بروتوكول الأدوات لفرض الثوابت: يوسع واجهات الأدوات القياسية لتشمل ثوابت الحالة، مما يتيح التحقق الساكن من تسلسلات الأدوات وتقليل أخطاء التوليد.
2. التخطيط المحسن للتكلفة: يقدم مخططاً يولد مرشحين متوازيين، ويتحقق منها عبر تتبع الرسم البياني للتدفق التحكمي (CFG)، ويختار مسار التنفيذ الأقل تكلفة، مما يلغي بفعالية استدعاءات LLM الزائدة.
3. الجدولة الواعية بالتكلفة: ينفذ مجدولاً يختار ديناميكياً بين استراتيجيات التسلسل، والتوازي، والتحوط بناءً على محاكاة مونت كارلو لتوزيعات زمن الاستجابة المتعلمة.
4. نظام متكامل (End-to-End): يدمج هذه المكونات في مجمع JIT يحول مهام اللغة الطبيعية إلى كود قابل للتنفيذ ومحسن، متجاوزاً حلقة الوكيل القياسية.

النتائج

تم تقييم النظام عبر 37 مهمة في خمسة تطبيقات ويب (Dashdish, GitLab, Gomail, Omnizon, Reddit) باستخدام نماذج لغوية كبيرة رائدة متنوعة.

• أداء JIT-Planner:

  • حقق تسريعاً بمقدار 10.4 ضعفاً مقارنة بأساس Browser-Use.
  • حسن الدقة بمقدار +28% مقارنة بـ Browser-Use.
  • أثبت أن تقدير التكلفة يصنف الخطط بفعالية: كان الفرق بين أفضل مرشح من حيث التكلفة وأسوأ مرشح هو تباين قدره 5.3 ضعفاً في زمن الاستجلة.
  • قلل بروتوكول الثوابت من معدل فشل توليد الخطط من 80% إلى 43% ونقل نمط الفشل المهيمن من انتهاكات ترتيب الأدوات إلى أنواع أخرى.

• أداء JIT-Scheduler:

  • حقق تسريعاً بمقدار 2.4 ضعفاً وتحسيناً في الدقة بنسبة +9% مقارنة بـ OpenAI's CUA.
  • تفوق على استراتيجيات الجدولة الثابتة (المتسلسل، المتوازي، التحوط) من خلال الاختيار التكيفي للاستراتيجية المثلى لكل مهمة. على سبيل المثال، حدد بشكل صحيح أن المهام ذات عناصر واجهة المستخدم عالية التباين (مثل البحث عن زر معين) تستفيد من التحوط، بينما تستفيد عمليات البحث البسيطة من التنفيذ المتسلسل.

• تحليل التعقيد:

  • كانت التسريعات متسقة عبر عدد المهام (منخفض، متوسط، عالٍ) وطولها، مما يشير إلى أن الفوائد تنبع أساساً من إلغاء استدلال LLM لكل خطوة بدلاً من الاستدلالات الخاصة بالمهمة.
  • التطبيقات ذات أنماط التنقل المعقدة (مثل Reddit) شهدت أعلى تسريعات (تصل إلى 18.9 ضعفاً)، بينما شهدت التطبيقات ذات التدفقات الأبسط مكاسب أقل ولكنها لا تزال كبيرة.

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

يزعم البحث أن تجميع الوكيل عند التشغيل (Agent JIT Compilation) يمثل اتجاهاً واعداً لتحسين كفاءة وموثوقية وكلاء استخدام الكمبيوتر. من خلال معاملة تخطيط الوكيل كمسألة تجميع، يقوم النظام بـ:

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

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