تسليم آمن لمهام وكيل الذكاء الاصطناعي بين الأجهزة: الحالة والموافقة والاسترداد

أربعة أنماط مختلفة لاستمرار مهام الوكيل

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

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

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

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

ما البيانات التي يجب أن تنتقل مع المهمة؟

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

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

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

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

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

قد يكتشف الوكيل أداة أو موردا أثناء المهمة، لكن الاكتشاف لا يضيفه تلقائيا إلى عقد الثقة. يجب تسجيل المصدر والوظيفة والصلاحية قبل التفويض. يقدم دليل Agentic Resource Discovery: اكتشاف موارد الوكلاء من ai-catalog.json إلى تفويض الهاتف تفصيلا إضافيا لكيفية الانتقال من العثور على مورد إلى السماح باستخدامه.

ربط الصلاحيات والموافقات بالفعل وجهاز التنفيذ

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

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

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

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

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

استرداد المهمة بعد السكون أو الانقطاع أو انتهاء الصلاحية

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

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

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

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

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

التحكم البعيد في Copilot CLI كنمط تطبيقي حالي

يقدم GitHub Copilot CLI مثالا واضحا للتحكم البعيد من دون ترحيل المهمة. وفقا لـإعلان GitHub عن التوفر العام للتحكم البعيد في جلسات Copilot CLI، يمكن متابعة جلسة قيد التشغيل من GitHub Mobile أو github.com أو VS Code، مع واجهات في JetBrains أيضا. تظل الجلسة في بيئتها المصدرية ولا تنتقل عملية التنفيذ إلى الهاتف.

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

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

في يوليو 2026، أضافت GitHub إشعارات حية للجلسات البعيدة على iOS وAndroid. يوضح تحديث GitHub Mobile للإشعارات الحية لجلسات Copilot CLI كيف يصل تقدم المهمة إلى الهاتف من دون الحاجة إلى إبقاء شاشة الجلسة مفتوحة. يظل الإشعار امتدادا للحالة، وليس بيئة تنفيذ جديدة.

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

استمرارية FoneClaw بين واجهات الهاتف نفسه

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

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

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

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

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

اختبار عملي لتقييم تسليم المهام بأمان

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

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

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

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

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