في العرض العريض، يقع زر البحث على يمين حقل الإدخال. أما على الشاشة الضيقة فيقع أسفله. لذلك قد يخطئ الهدفَ وكيلٌ يكرر ببساطة موضع النقرة الأول، مع أن المهمة الفعلية لم تتغير. لم تكن الإحداثية خاطئة، بل إن إطارها المرجعي قد تقادم.
يصف المستودع الأصلي لـ UI-TARS التشغيل المرئي لواجهات المستخدم الرسومية، ويؤرّخ UI-TARS-2 بتاريخ 4 سبتمبر 2025. مضى على هذا الإصدار أكثر من عام، وهو يُستخدم هنا أساسًا تقنيًا. ولا نستنتج منه مكانة رائدة حالية ولا معيار أداء خاصًا بنا. السؤال المثير للاهتمام هو: ما الملاحظة التي يحتاجها الفعل كي يمكن الحكم على نتيجته أصلًا؟
لقطة الشاشة تصف موقفًا
تُظهر الصورة واجهةً في لحظة بعينها. وينتمي عرض النافذة وموضع التمرير والأقسام المفتوحة إلى ذلك الموقف. ولا يمكن فصل موضع زرٍّ فصلًا تامًا عن هذه الظروف. فالموضع لا يكتسب معناه إلا من خلال الصورة المقابلة والمهمة الحالية.
يستخدم مثالنا صفحة مكتبة خيالية. يريد الشخص العثور على كتاب. تعرض الشاشة البحث وتسجيل الدخول وإشعارًا عن الفعاليات. وقد تكون هناك ثلاثة أزرار متشابهة التصميم. وليس الزر الأكبر أو الأكثر ألوانًا هو الصحيح تلقائيًا. فالمهمة هي التي تحدد الهدف ذا الصلة.
يُظهر هذا حدًا أول للتشغيل المرئي: التعرّف واتخاذ القرار مترابطان. فلا يكفي أن يحدد الوكيل موقع العنصر، بل عليه أيضًا أن يطابقه مع الفعل المقصود. ولا يفيد زر تسجيل دخول جرى التعرف عليه بدقة في البحث عن كتاب.
حجم الصورة وموضع الهدف متلازمان
إذا جرى تغيير مقياس الصورة لأغراض المعالجة، فيجب أن تتطابق الإحداثيات مع الإطار المرجعي المستخدم فعليًا. فالزوج نفسه من الأرقام قد يدل على أماكن مختلفة في صور ذات أحجام مختلفة. وحتى ثبات حجم الشاشة لا يفيد إذا دفع إشعارٌ موسَّع المحتوى إلى الأسفل.
لذا تربط ملاحظة الرصد الواضحة بين أهم التفاصيل. المخطط التالي من إعدادنا؛ ولا يتضمن أي مخرجات حقيقية من UI-TARS، وليس صيغة وكيل قابلة للتنفيذ:
Observation: search page, narrow view
Goal: trigger a search for the entered book title
Action: press the visible search button
Expectation: results or an understandable result state
Afterwards: assess the new viewالبند الأخير هو الحاسم. فهو يمنع أن يُعدّ إدخالٌ نُفّذ تقنيًا فحسب مهمةً مكتملة بالفعل. فالنقرة في البداية لا تُنتج سوى انتقال لا يزال أثره بحاجة إلى الفحص.
أربع استجابات محتملة للفعل نفسه
بعد تشغيل البحث، قد تظهر النتائج، أو قد يظل مؤشر التحميل ظاهرًا، أو قد يظهر تحذير بشأن الإدخال، أو قد يُبلَّغ عن خطأ تقني. وتستدعي هذه الحالات خطوات تالية مختلفة. ولن يكون النقر مجددًا منطقيًا في كل الحالات.
يجب أيضًا أن تتلاءم النتائج مع مهمة البحث. فربما اقتُرح عنوان مشابه، أو ربما لا تزال القائمة تعود إلى الإدخال السابق. لذا تحتاج الملاحظة الجديدة مرة أخرى إلى التعليمات الأصلية مرجعًا لها. فالدورة ليست مجرد صورة ثم نقرة ثم صورة، بل فهمٌ ثم فعلٌ ثم قياس الأثر في ضوء الهدف.
لتمرين غير ضار خاص بك، يمكنك إعداد الحالات الأربع على هيئة بطاقات ترسمها بنفسك. وخصّص لكل بطاقة فعلًا تاليًا مبرَّرًا. يشرح التمرين التفكير بالحالات دون الادعاء بتشغيل حقيقي لنموذج أو باتصال فعّال بنظام مكتبة.
الواجهات الجيدة تساعد البشر والوكلاء
تقلل التغذية الراجعة الواضحة من عدم اليقين لدى البشر أيضًا. فعبارة «لا توجد نتائج» تجيب عن سؤال مختلف عن عبارة «تعذّر تحميل البحث». أما تأثير التحميل الزخرفي الذي لا تُعرف له نهاية، فلا يقدم إلا قليلًا من التوجيه. ويمكن للتصميم أن يدعم دورة الرصد بالتمييز الواضح بين الحالات ذات الصلة.
تشغيل وكيل محليًا لا يجيب وحده عن كل الأسئلة المتعلقة بتدفقات البيانات. وبالمثل، فإن نجاح سلسلة من النقرات لا يثبت بعدُ موثوقية التشغيل عمومًا. وكلا الأمرين يتعيّن فحصه على النظام الفعلي.
الفكرة القابلة للتعميم أبسط من ذلك: الموضع القديم ليس معنىً دائمًا. فبمجرد أن يكون بوسع فعلٍ ما تغيير الواجهة، يحتاج القرار التالي إلى مرجع حالي. ولا يربط الخطوةَ المنفَّذة بالنتيجة المقصود تحقيقها فعلًا سوى رصدٍ جديد.
المصادر والحالة
البحث والتوثيق حتى تاريخ 25 أكتوبر 2026. مستودع UI-TARS: تحديث UI-TARS-2 ومعالجة الإحداثيات.
