فهم الشاشة لوكيل ذكاء اصطناعي على أندرويد: شجرة الواجهة أم لقطة الشاشة؟

متى نختار شجرة الواجهة أو لقطة الشاشة؟

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

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

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

إذا كان هدفك فهم حلقة التحكم العامة بعد اختيار الدليل، فدليل تحكم وكيل الذكاء الاصطناعي في هاتف Android: من النية إلى التنفيذ الموثوق يشرح الانتقال من النية إلى الاقتراح والتنفيذ والتحقق. هذه الصفحة تركز على سؤال أسبق: أي دليل شاشة نستخدم قبل أن نقرر الفعل؟

ما الذي تكشفه شجرة إمكانية الوصول؟

توفر Android عبر خدمات إمكانية الوصول تمثيلاً هرمياً لمحتوى النافذة عندما يفعّل المستخدم الخدمة وتطلب التهيئة استرجاع محتوى النافذة. تصف وثائق Android حول خدمات إمكانية الوصول هذه الخدمات كتقنية موجهة لمساعدة المستخدمين على التفاعل مع الجهاز، وليست اختصاراً عاماً لتشغيل كل تطبيق بلا حدود. هذا الحد مهم: وكيل الهاتف الجيد يستخدم الدليل المسموح والمناسب ولا يتعامل مع إمكانية الوصول كقناة مخفية.

العقد التي تمثلها AccessibilityNodeInfo قد تكشف النص الظاهر، content description، الحالة مثل قابل للنقر أو محدد أو مفعل، التركيز، الإجراءات الممكنة، حدود العنصر، والعلاقات الهرمية. توضح مرجعية Android لـAccessibilityNodeInfo أن العقد تمثل محتوى نافذة إمكانية الوصول وتعرض معلومات دلالية وحالة وتسلسلاً حيث توفرها التطبيقات. لهذا تكون شجرة الواجهة مفيدة جداً لاختيار زر محدد أو قراءة حالة مفتاح أو تمييز حقل إدخال.

قوتها الأساسية أنها مضغوطة وقريبة من معنى الإجراء. إذا قالت العقدة إن العنصر زر وله وصف «إرسال» وحدود واضحة، فهذا أفضل من محاولة تفسير شكل أيقونة من البكسلات فقط. وإذا كان المفتاح checked=false، فالوكيل يعرف الحالة الحالية قبل أن يقترح تغييرها. كما أن الشجرة تساعد في تقليل الخصوصية المعروضة عندما لا نحتاج صورة كاملة للشاشة.

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

متى تصبح البكسلات دليلاً ضرورياً؟

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

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

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

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

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

مقارنة جودة الإسناد بين العقد والبكسلات

الإسناد الجيد يعني أن الوكيل يعرف لماذا يعتقد أن هذا العنصر هو الهدف، وما الدليل الذي يؤيد ذلك، وما الذي بقي غير مؤكد. شجرة الواجهة ولقطة الشاشة تقدمان نوعين مختلفين من الأدلة، ولا ينبغي دمجهما بلا سبب. المصفوفة التالية تساعد على اختيار المسار قبل تنفيذ أي فعل.

توضح إرشادات Android لاختبار UI Automator قيمة المحددات المستقرة والانتظار الصريح لحالة الواجهة عند الاختبار. نحن لا نقول إن FoneClaw يستخدم UI Automator داخلياً؛ الفائدة هنا هي الدرس الهندسي: التفاعل الموثوق مع الشاشة يحتاج دليلاً ثابتاً وحالة حديثة، لا تخميناً من لقطة أو عقدة واحدة.

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

سير هجين يجمع الدلالة والرؤية

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

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

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

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

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

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

تطبيق القرار داخل FoneClaw

نحن نبني FoneClaw كوقت تشغيل لوكيل هاتف Android: نموذج مهيأ يفهم ويخطط، وFoneClaw توفر أدوات مدعومة ومحكومة داخل الهاتف. عند طلب يتعلق بالشاشة الحالية، نبدأ من الدليل المنظم عندما يكفي. أدوات مثل get_screen_info وcross_app_read_screen تساعد في معرفة ما هو ظاهر وما الذي يمكن قراءته من الشاشة. وعندما يكون السؤال بصرياً، نستعمل screenshot_take أو screenshot_open كي يصبح الدليل البكسلي جزءاً من الطلب.

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

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

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

للبدء، يمكن للمستخدم مراجعة ميزات FoneClaw لفهم نطاق 100+ أداة مدمجة، ثم الانتقال إلى تنزيل FoneClaw. الاختبار الأفضل ليس مهمة عالية الخطر؛ ابدأ بسؤال عن شاشة بسيطة، ثم مهمة قابلة للتراجع، ثم راقب كيف يجمع FoneClaw بين الدلالة والبكسلات والنتيجة النهائية.

اختبار آمن لفهم الشاشة

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

1. اختر شاشة لا تحتوي بيانات حساسة قدر الإمكان، وسجل الهدف المتوقع قبل تشغيل الوكيل.
2. ابدأ بطلب يعتمد على الشجرة فقط: اقرأ الأزرار أو تحقق من حالة مفتاح.
3. أضف لقطة شاشة فقط عندما تبقى حقيقة بصرية غير محلولة، مثل رسم أو لون أو موضع.
4. غيّر الاتجاه أو افتح نافذة صغيرة لترى هل يعيد الوكيل الفحص بدلاً من استخدام حالة قديمة.
5. قاطع المهمة مرة، ثم راقب هل يوضح ما اكتمل وما لم يكتمل.
6. نفذ فعلاً قابلاً للتراجع، ثم تحقق بحالة جديدة أو ألغِ النتيجة يدوياً.

إذا أردت قياساً أوسع عبر مهام متعددة، فدليل معيار تقييم وكيل هاتف Android: كيف نختبر الوكلاء في 2026؟ ينقل الاختبار من تجربة فردية إلى منهج تقييم. أما هنا فالقاعدة العملية هي: الدلالة أولاً عند كفايتها، البكسلات عند الحاجة، والهجين عندما لا يكفي أحدهما وحده.