Computer Use عبر Screenshot يشبه طريقة الإنسان: يرى الشاشة ويختار مكان النقر. هذا يجعله قادرًا على التعامل مع تطبيقات لا تملك API أو DOM واضحًا، لكنه يدفع ثمنًا في الدقة والسرعة والثبات. في المقابل، DOM locators و Tools الدلالية تعرف العنصر أو الفعل مباشرة، لكنها تحتاج تكاملًا تقنيًا. التصميم الأقوى لا يختار أحد الطرفين دائمًا؛ يستخدم أعلى مستوى من الدلالة المتاح وينزل للرؤية فقط عندما لا توجد قناة أفضل.
Screenshots ممتازة للواجهات غير المنظمة
لو تتعامل مع remote desktop أو canvas أو تطبيق رسومي لا يتيح accessibility tree أو DOM، الرؤية قد تكون الخيار الوحيد. النموذج يحدد زرًا أو نصًا ويعيد coordinate أو منطقة. لكن أي تغيير في scale أو window size أو overlay قد يحرك الهدف. لذلك يجب أخذ screenshot حديثة قبل الفعل وتثبيت viewport قدر الإمكان.
DOM و Accessibility يعطيان Targets أكثر ثباتًا
عندما تكون الصفحة Web عادية، locator بال role أو label أو text أو attribute غالبًا أفضل من pixel. تستطيع انتظار العنصر والتحقق من enabled/visible وقراءة قيمة الحقل. لكن selectors الهشة مثل nth-child طويل قد تتكسر أيضًا؛ استخدم semantic locators أو IDs مستقرة عندما تملك الصفحة.
خطوات عملية
- ابحث أولًا عن Tool دلالية مباشرة.
- إن لم توجد، استخدم DOM/accessibility locator.
- إن لم تتوفر قناة بنيوية، استخدم vision.
- بعد الفعل تحقق من النتيجة بأقوى قناة متاحة.
- احتفظ ب ـfallback ولا تستخدمه إذا كانت القناة الأعلى تعمل.
Tools أعلى من DOM عندما تملك المنتج
إذا كان المطلوب تغيير Proxy أو فتح Profile أو تنزيل ملف داخل متصفحك نفسه، Tool مثل `set_profile_proxy(profileId,proxyId)` أفضل من فتح Settings والنقر. هي أسرع، أقل عرضة لتغير التصميم، وتعيد نتيجة واضحة. احتفظ ب ـUI للمستخدم وب ـTool للوكيل، على أن يمر الاثنان من نفس domain service حتى تكون التأثيرات متطابقة.
قائمة مراجعة
- الأداة تستخدم نفس backend action الخاصة بالواجهة.
- الصلاحيات مفحوصة.
- النتيجة منظمة ويمكن التحقق منها.
- لا يوجد مسار خفي يتجاوز audit أو side effects.
- الفعل البصري ليس مطلوبًا فقط لتقليد الإنسان بلا سبب.
النظام الهجين يحتاج Router قرار
قبل كل خطوة اسأل: هل هناك Tool رسمية؟ هل يوجد DOM target موثوق؟ هل accessibility كافية؟ وإلا استخدم vision. يمكن لل ـAgent اتخاذ هذا القرار ضمن policy بسيطة. لو فشل locator بسبب تغير الصفحة، لا تنتقل مباشرة إلى random clicking؛ التقط الحالة من جديد وحاول قناة بديلة مع حد للمحاولات.
قِس النجاح حسب نوع الواجهة
اختبر 100 تنفيذ لكل strategy على نفس السيناريو، وسجل success rate و time و retries و wrong-action rate. قد يكون vision أفضل في واجهة dynamic معينة و DOM أفضل في معظم النماذج. لا تجعل الاختيار أيديولوجيًا؛ اجعله قائمًا على بيانات لكل فئة مهمة.
قائمة مراجعة
- success rate مسجل.
- زمن التنفيذ مقاس.
- الأفعال الخاطئة محسوبة منفصلة عن failures.
- التكلفة الحسابية معروفة.
- fallback لا يسبب تنفيذ الفعل مرتين.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…