لماذا يخدعك الشاشة
تخيّل أن وكيلًا يعمل مع تطبيق سطح مكتب. يرى نافذة تحتوي على عدة حقول وزر «حفظ». من منظور لقطة الشاشة، هذه هي نفس الشاشة، لكن في الواقع قد يكون النموذج فارغًا، أو مملوءًا جزئيًا، أو قد تم إرساله بالفعل — ولا يعرف المنطق الخفي لنظام التشغيل أي سيناريو يُنفَّذ حاليًا. هذا الموقف يُسمى الملاحظة الجزئية: الوكيل لا يطّلع إلا على المظاهر الخارجية، وليس على الحالة الحقيقية للنظام.
الخطر يكمن في أن الإجراء المعقول محليًا — مثل النقر على زر — قد يُكمل السيناريو في حالة، ويُسبب خطأ تحقق في أخرى، ويُتجاهل ببساطة في ثالثة. الشاشات المتشابهة بصريًا قد تنتمي إلى فروع مختلفة من سير العمل، وهذا يؤدي إلى نتائج مختلفة جوهريًا. لذلك، يتطلب السلوك الفعّال ليس فقط التعرف على عناصر الواجهة، بل أيضًا استكشافًا نشطًا: يجب تحديد الحالات التي يمكن الوصول إليها أصلًا، وإزالة الغموض قبل اتخاذ القرار.
هذه هي المهمة التي تكرّس لها ورقة «ScreenSearch: Uncertainty-Aware OS Exploration» (arXiv:2605.16024)، التي كتبها مايكل سولودكو وجاستن ويجل. يصوغون المشكلة كاستكشاف لحالات الحاسوب: يجب على الوكيل أن يوازن بين توسيع الجبهة القابلة للوصول وتقليل عدم اليقين.
المنهج: رسم بياني للحالات ووكيل متعدد الأذرع
بدلًا من الاعتماد على لقطات شاشة منفردة، يبني النظام المقترح ScreenSearch رسمًا بيانيًا موحّدًا للحالات المكررة. للقيام بذلك، يستخدم بحثًا هيكليًا: تتحول أشجار UIA إلى ميزات مع مراعاة موضع العناصر، وتُفهرس الشاشات المرتبطة عبر بحث رمزي متناثر وفلاتر بيانات وصفية. يُحافظ على الرسم البياني للحالات عبر عدة أجهزة افتراضية، مما يتيح توسيع نطاق الاستكشاف.
استراتيجية اختيار الإجراء التالي يحددها وكيل متعدد الأذرع قائم على PUCT، يراعي غموض الحالات. هذا يعني أن الوكيل يفضّل ليس فقط الانتقالات الواعدة من حيث الجدة، بل أيضًا تلك التي تقلل عدم اليقين. في جوهره، يستكشف النظام فضاء الحالات ويصقل معرفته به في الوقت نفسه.
كيفية قياس الغموض
المساهمة الرئيسية للورقة هي إشارة غموض قابلة للتوسع. تعتمد على ملاحظة بسيطة: إذا كانت الشاشات المتشابهة بصريًا، مع نفس توقيع الإجراء، تؤدي إلى حالات تالية مختلفة، فهذا يعني أن الحالة الحالية غير مدروسة بما يكفي. يصبح تباين النتائج مؤشرًا على أن الوكيل لم يفهم بعد كيفية عمل هذا الجزء من سير العمل.
تُدمج هذه الإشارة مع مكافآت توسيع جبهة الاستكشاف. ونتيجة لذلك، يصبح من الممكن تقييم السياسات على الرسم البياني الموحّد عبر إعادة تشغيل البداية: تُشغَّل السياسة من مجموعة ثابتة من حالات البداية ويُلاحظ كيف تتعامل مع المهام. المهم أن بعض السياسات قد تقلل الغموض بسرعة، لكنها لا تفتح حالات جديدة تقريبًا، بينما تستكشف أخرى بنشاط، لكنها لا تنجح في «إنهاء» المواقف غير الواضحة. لذلك يؤكد المؤلفون: مجرد تقليل الغموض ليس هدفًا كافيًا.
التجارب: التنوع والمقايضات
للتحقق من المنهج، استُخدمت 11 تطبيق سطح مكتب. خلال التجارب، جُمع أكثر من مليون لقطة شاشة وأكثر من 30 ألف حالة فريدة. تتميز المجموعات الناتجة بتنوع كبير سواء بين التطبيقات أو داخل كل منها — وهذا يتيح اختبار الوكلاء في ظروف واقعية.
على شريحة إعادة تشغيل البداية الثابتة، تظهر المقايضة بين الجدة والغموض بوضوح. بعض الاستراتيجيات تقلل مستوى عدم اليقين تقريبًا فورًا، لكنها نادرًا ما تجد حالات جديدة. أخرى، على العكس، توسع حدود المعروف بسرعة، لكنها تترك الكثير من «المناطق الرمادية». يستنتج المؤلفون أن هدف الاستكشاف يجب أن يكون شاملًا.
أظهرت عمليات الإزالة الإضافية تأثيرًا مثيرًا للاهتمام: تعزيز اقتراحات الأولويات (proposal priors) يحسّن بشكل ملحوظ اكتشاف الحالات الفريدة عند بناء المجموعة. بعبارة أخرى، تعتمد اكتمالية الرسم البياني للحالات المجمَّع بشكل مباشر على جودة خيارات الإجراءات المقترحة للوكيل.
الخلاصة
يؤكد بحث ScreenSearch أنه لكي يعمل الوكيل بشكل موثوق في نظام تشغيل، لا يكفي التعرف الجيد على عناصر الواجهة. الأهم هو فهم هوية الحالة، وتوليد اقتراحات إجراءات عالية الجودة، والقدرة على البحث مع مراعاة الغموض. هذه العوامل الثلاثة هي التي تحدد متى يجب مواصلة الاستكشاف ومتى يمكن تثبيت النتيجة.
قدّم المؤلفون ورقة من 22 صفحة تحتوي على 8 أشكال و21 جدولًا، حيث وُصفت بالتفصيل كل من الطريقة نفسها والتجارب. هذا أساس جيد للأعمال المستقبلية في مجال وكلاء الواجهات الرسومية الموثوقين.
