وكيل الهاتف ذاتي التحسين: إصدارات المهارات والاختبارات والتراجع

ما وكيل الهاتف ذاتي التحسين وأي جزء يتغير؟

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

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

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

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

كذلك يختلف عن تدريب نموذج هاتف جديد على بيئات محاكاة. يمكن مراجعة PhoneBuddy-4B وتدريب وكلاء الهاتف: لماذا يهم Mock-App RL لوكلاء Android لفهم مسار التدريب. هنا ينصب التركيز على جعل الوكيل المنشور أفضل عبر تغييرات محدودة وقابلة للاختبار والتراجع، مع الحفاظ على أذونات Android والتأكيدات كما صممت.

ماذا يضيف نموذج Self-Harness إلى دورة التحسين؟

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

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

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

ذكر مؤلفو Self-Harness تحسنا في معدل النجاح على مجموعة اختبار محجوبة من Terminal-Bench-2.0 لثلاثة نماذج أساسية ثابتة، مع تعديل بنية التشغيل بدلا من أوزان النماذج. تمثل هذه النتائج ما أبلغ عنه البحث في بيئة التقييم المحددة. وبالنسبة إلى وكيل الهاتف، الدرس هو أن تحسين الأدوات والتحقق والتعافي قد يرفع النجاح حتى من دون تغيير النموذج.

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

كيف يحسن FoneClaw التخطيط والمهارات مع بقاء التنفيذ مضبوطا؟

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

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

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

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

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

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

دورة التغيير من أثر الفشل إلى الإصدار والتراجع

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

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

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

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

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

لماذا قد يجعل الإصلاح السريع الوكيل أسوأ؟

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

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

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

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

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

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

قائمة جاهزية التحسين للاستخدام الحقيقي على Android

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

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

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

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

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