← الرؤى

SLATEMOTH / تحليل

حتى الوكيل الذي يعمل باستمرار يحتاج إلى شرط للتوقف

يطرح إطلاق dots من OpenAI سؤالًا عمليًا: كيف ينبغي للوكلاء الذين يواصلون العمل التعامل مع الأهداف التي انتهت صلاحيتها، والأحداث المكررة، والأذونات المسحوبة؟

أُعدّ هذا المقال بمساعدة الذكاء الاصطناعي، ودُقّق بالرجوع إلى المصادر العامة المذكورة في 30 سبتمبر 2026. وهو تحليل تحريري، وليس تقييمًا عمليًا لـ dots ولا ادعاءً بأن منتجات SlateMoth تطبق هذه الضوابط.

يستمر العمل بعد انتهاء المحادثة

في 29 سبتمبر، قدّمت OpenAI خدمة dots: وكلاء يواصلون العمل ولدى كل منهم حاسوب سحابي خاص به. يبرز هذا الإعلان سؤالًا مهمًا في التصميم: إذا استطاع الوكيل مواصلة العمل بعد انتهاء المحادثة، فما الذي ينبّهه إلى أن المهمة لم تعد صالحة؟ [1]

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

رصد التغيير لا يمنح إذنًا بالتصرف

تفصل OpenAI بين البحث الاستباقي الذي يجريه dots والإجراءات اللاحقة. يوضح شرحها للسلامة أن البحث في الخلفية يستخدم أدوات للقراءة فقط؛ أما الإجراءات اللاحقة فتظل خاضعة للقواعد والفحوص المعتادة. ولا ينبغي الخلط بين هذا النمط المحدد من البحث وكل مهمة مصرّح بها تستمر في الخلفية. [2]

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

لا ينبغي أن يولّد تكرار الإشارة عملًا مكررًا

تصف وثائق MCP Events من OpenAI المعالجة غير المتزامنة، وإعادة المحاولة، واحتمال وصول الأحداث بغير ترتيبها. وتطلب إبقاء معرّف الحدث ثابتًا عبر المحاولات، وأن تكون أدوات الكتابة بحيث لا تكرر التغيير عند إعادة استخدامها. لذا فإن الإقرار باستلام التبليغ مرحلة مختلفة عن إتمام العمل المطلوب. هذه قواعد تكامل موثقة، وليست دليلًا على أننا اختبرنا إضافة بعينها. [3]

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

ضع آلية لإنهاء التكليف

يشترط دليل MCP Events نفسه التعامل مع انتهاء الاشتراكات المحددة المدة، ووقف تسليم الأحداث عند سحب صلاحية الوصول. مدة الاشتراك تحكم تسليم الأحداث؛ ولا تحدد بمفردها متى تنتهي صلاحية هدف العمل. ويجب تصميم الحد الثاني على حدة. [3]

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

إيقاف العمل وسحب الوصول ومحو السياق أمور مختلفة

تذكر الأسئلة الشائعة لدى OpenAI عن dots أن فصل إضافة يوقف الوصول الجديد، لكنه لا يمحو السياق المحفوظ بالفعل. كما تميّز بين حذف dot وحذف الملفات أو المحادثات المخزنة في أماكن منفصلة. هذه حقائق تخص المنتج؛ والدرس التشغيلي الأوسع هو تسمية الحالة التي تتغير. [4]

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

اختبر تغيّر الظروف قبل إسناد مسؤولية مستمرة

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

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

المصادر والتحقق

  1. OpenAI · Introducing dots، 29 سبتمبر 2026
  2. OpenAI · How we build safety, security, and privacy into dots، 29 سبتمبر 2026
  3. OpenAI Developers · MCP Events؛ اطّلعنا عليه في 30 سبتمبر 2026
  4. OpenAI Help Center · Dots privacy, security, and safety FAQs؛ اطّلعنا عليه في 30 سبتمبر 2026