واجهة موافقة وكيل الذكاء الاصطناعي على الهاتف: الثقة والسبب والاسترداد

حدّد لحظة القرار قبل أن يغيّر الوكيل شيئا

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

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

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

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

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

افصل بين الاقتراح والمعاينة والتطبيق المباشر

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

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

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

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

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

وجّه المراجعة بحسب الثقة من دون تحويلها إلى يقين

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

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

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

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

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

اعرض السبب والهدف والأثر قبل الموافقة

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

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

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

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

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

اربط كل موافقة بالمهمة والمحادثة الصحيحتين

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

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

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

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

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

أنماط موافقة للرسائل والإعدادات والملفات والملاحة

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

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

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

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

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

اجعل الرفض والتعديل والتراجع والاسترداد مسارات واضحة

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

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

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

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

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