OpenAI Dots تحتاج إشرافًا دائمًا على الوكلاء

قدّمت OpenAI في 30 سبتمبر 2026 منتج Dots بوصفه وكلاء دائمين يعملون بـGPT-6 Astra. وتقول الشركة إن لكل Dot حاسوبًا سحابيًا خاصًا، وإنه يستطيع العمل عبر الأدوات المتصلة والاستمرار عندما يكون جهاز المستخدم مغلقًا والتعلم من الملاحظات مع الوقت. هذه قدرات موثقة وادعاءات منتج، وليست دليلًا مستقلًا على أن كل Workflow سيكتمل بصورة صحيحة.

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

يتعامل هذا المقال مع Dots كتحديث منتج حقيقي، ثم يستخرج دروسًا معمارية للفرق التي تبني وكلاء طويلة التشغيل. ولا يفترض أن Dots نفسها API عامة للمطورين؛ توثق OpenAI كلًا من Agents API وAgents SDK وResponses API كمسارات منفصلة.

إطلاق المنتج يغيّر حدود الزمن

تصف صفحة إطلاق OpenAI Dots كوكلاء سحابيين دائمين يمكنهم الاتصال بالأدوات والوصول إليهم عبر ChatGPT أوSlack أوTeams. وتضيف وثيقة Meet Dots أن الوكيل يملك حاسوبًا ومتصفحًا سحابيين ويمكنه متابعة العمل وجهاز المستخدم مغلق.

لهذا تصبح “Agent Run” وحدة ملكية ضعيفة. قد تعيش العملية أطول من Model Call واحدة، وجلسة متصفح واحدة، وقناة رسائل واحدة، وبيئة حوسبة واحدة. تصبح المهمة الدائمة هي الوحدة: Outcome مسماة، ومصادر مصرح بها، وحالة حالية، ودليل، وموافقات، ومخرجات، وشرط إكمال صريح.

لا تستنتج API Contract من المنتج الموجه للمستخدم. تميّز وثائق OpenAI للوكلاء بين Agents API المدارة وAgents SDK وResponses API. تدير الأولى Codex Harness وتحفظ التقدم، وتعطي SDK التطبيق تحكمًا أكبر في Runtime والتخزين والموافقات، بينما توفر Responses مستوى أدنى للنماذج والأدوات. اختر بناء على الجهة التي يجب أن تملك الحالة والتعافي.

الدرس المعماري قابل للتعميم: إذا كان الوكيل يستطيع الاستيقاظ لاحقًا، فيجب أن تعني “Continue” إعادة تحميل حالة مهمة متحقق منها، لا مطالبة النموذج بإعادة بناء الواقع من محادثة طويلة.

ضع كل مسؤولية في سجل مهام دائم

تقول وثائق Tasks and Memory إن Dot يستطيع تتبع مسؤوليات متعددة والتوقف والاستيقاظ وإنشاء أعمال خلفية والاستجابة لوقت أوحدث مدعوم والاستمرار عبر المحادثات. كما تحذر من أن اكتمال Run لا يثبت وحده تحقق النتيجة المطلوبة أوتسليمها.

مثّل المهمة كـState Machine محفوظة خارج Model Context. تشمل الحالات المفيدة `planned` و`ready` و`running` و`waiting_for_tool` و`waiting_for_approval` و`paused` و`verifying` و`succeeded` و`failed` و`cancel_requested` و`cancelled`. يجب أن تكون الانتقالات Conditional Writes مع Version Checks، لا نص حالة حرًا. Worker يستأنف Lease قديمة لا يجوز أن يكتب فوق قرار أحدث.

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

task_id: task_01J...
intent_version: 3
state: waiting_for_approval
step: send_customer_message
permission_snapshot: perm_94
input_evidence: [artifact_17, event_203]
idempotency_key: task_01J:send_customer_message:v3
lease_owner: worker_8
lease_expires_at: 2026-10-02T06:07:00+03:00
definition_of_done: message_delivered_and_logged

أضف Task Events بدل تحديث JSON مبهم. يجب أن يوضح Event Stream من طلب التغيير، وأي دليل استخدمه Planner، ولماذا توقف التنفيذ، وأي Postcondition جرى التحقق منه. هذا سجل Audit وتعافٍ، وليس Chain-of-thought مخفية.

افصل Context المحادثة عن الذاكرة والحقيقة التشغيلية

تميز وثائق Dots بين Conversation Context وChatGPT Memory وملاحظات Dot المحفوظة. وتذكر أن المهمة المفوضة تستلم تعليمات وسياقًا مناسبين، لا كل المحادثات تلقائيًا. هذه Boundary مفيدة: الذاكرة الأكبر ليست دائمًا أكثر أمانًا أوصحة.

أنشئ ثلاثة مخازن بقواعد مختلفة. Conversation Context مدخل قصير العمر للتفاعل الحالي. وPreference Memory تحتوي حقائق مراجعة مثل أسلوب الكتابة وحد الإشعار المعتاد واسم مشروع مستمر. أما Operational Truth فتحتوي حالة المهمة والصلاحيات ومعرفات الموارد الخارجية والموافقات والنتائج الموثقة. المخزن الأخير وحده يقرر هل يمكن استمرار Mutation.

تحتاج كل Memory دائمة إلى Provenance وScope وOwner ودرجة حساسية ووقت إنشاء ومراجعة وانتهاء. ملاحظة مستنتجة من محادثة خاصة لا يجوز كشفها في قناة فريق لأن القناتين تصلان إلى الوكيل نفسه. تذكر OpenAI صراحة أن الاستمرارية بين القنوات لا تمنح صلاحية كشف معلومات خاصة لجمهور آخر.

نفّذ Retrieval حسب Task وAudience، لا Query عامة اسمها “Relevant Memory”. قبل إرسال رسالة إلى Slack، احسم الجمهور المستهدف وصفِّ Context. وقبل استئناف Worker، حمّل Intent غير القابلة للتغيير وPermission Snapshot الحالية والArtifacts الموثقة؛ واعتبر الملخصات السردية مجرد إشارات.

يجب أن يكون تصحيح الذاكرة First-class. تغيير المستخدم لتفضيل ينشئ سجلًا جديدًا يلغي ما قبله ويعيد تقييم الخطط المستقبلية المتأثرة، من دون تعديل Audit History للأعمال المكتملة.

اربط الصلاحية بالفعل والبيئة واللحظة

تفصل وثيقة Computers and Apps بين متصفح Dot السحابي والحاسوب الشخصي المتصل والPlugins. جلسات Cloud وLocal ليست قابلة للتبديل، وصلاحيات التطبيقات منفصلة عن قنوات الرسائل. وتشرح وثيقة Controls قواعد للفعل التلقائي أوالفعل بعد طلب صريح أوطلب موافقة أوتسليم الفعل للمستخدم.

في نظامك، اجمع هذه المدخلات في Permission Snapshot غير قابلة للتعديل عند تخطيط خطوة خطرة. ضع فيها Principal وTenant والبيئة والأداة وفئة الفعل ونطاق المورد ونوع البيانات ونمط الموافقة وتاريخ الانتهاء وPolicy Version. ثم افحصها مباشرة قبل التنفيذ لأن Tokens وصلاحيات Plugin وسياسة Workspace وIntent المهمة قد تتغير أثناء الانتظار.

لا تخلط Authentication مع Authorization. جلسة متصفح نشطة تثبت أن الجلسة تستطيع الوصول إلى حساب، لا أن المهمة مسموح لها بإرسال رسالة أوحذف ملف أواعتماد دفعة. ضع Policy Enforcement حتمية بين Tool Call المقترحة من النموذج وTool Adapter.

اجعل الأدوات ضيقة حسب Business Effect. `search_mail` و`draft_reply` عقود أكثر أمانًا من متصفح عام. ويجب أن تطلب `send_reply` مستلمًا وContent Digest ونسخة مهمة معتمدة وIdempotency Key. العمليات التدميرية تعيد خطة قابلة للمعاينة وتطلب Approval Token منفصلة ومربوطة بالخطة نفسها.

يجب أن تبقى Credentials خارج Context المرئي للنموذج وسجلات المهام. مرر Credential References إلى Resolver على الخادم، واحذف الأسرار من أخطاء الأدوات، وأنهِ صلاحية البيئة بعد العمل. وإذا انتقل التنفيذ من Cloud إلى حاسوب متصل، فأنشئ Environment Binding جديدة؛ لا تتظاهر أن Browser State الأصلية انتقلت.

عامل الجداول والأحداث كمدخلات قابلة للتكرار

تفصل وثائق Dots بين Recurring Schedules والعمل النشط، وتقول إن توصيل مصدر لا ينشئ Event Monitoring تلقائيًا. هذا يعني وجود Resourceين مختلفين: Trigger Definition وTask Execution. افصلهما حتى لا يلغي إيقاف Run اليوم جدول الغد بصمت، وحتى لا يترك حذف الجدول Mutation نشطة.

افترض أن Time Triggers وEvent Triggers قد تصل مرتين أوتتأخر أوتظهر بعد Restart. امنع التكرار باستخدام Trigger Identity مع Occurrence، ثم أنشئ أواربط Task Operation واحدة. إذا أطلق “تقرير خطأ جديد” حدثًا لرسالة معدلة، فحدد هل يحدث المهمة الحالية أويخلق مهمة جديدة. خزّن Source Event ID ونسخته بدل مقارنة النص الحر.

استخدم Transactional Outbox عندما يجب أن ينتج تغير حالة المهمة إشعارًا أوQueue Job. Commit في قاعدة البيانات ثم فشل نشر Queue يترك Ledger وExecutor غير متسقين. وتحتاج Consumers إلى Idempotent Handlers لأن Retry قد تأتي بعد نجاح الأثر الجانبي وقبل Acknowledgment.

تحتاج Schedules إلى Time Zone وتاريخ نهاية وسياسة للRuns الفائتة وقواعد Concurrency. “كل ساعة” غير كافٍ: هل تتداخل Run بطيئة أم تُتخطى أم تدخل Queue؟ لوكيل قد يغير بيانات، ابدأ بتنفيذ غير متداخل وأعد مطابقة أحدث Source State قبل الفعل.

Event Filters حدود أمنية. Keyword Match في قناة عامة لا تمنح المهمة وصولًا إلى مستودعات خاصة. احسم صلاحيات المصدر والمهمة بصورة مستقلة، ثم استخدم تقاطعهما.

تحقق من النتيجة بدل الثقة بإشارة الاكتمال

عودة Tool بالنجاح تثبت أن Call عادت فقط. وقول Background Agent “Done” يثبت أنه توقف فقط. عرّف Postconditions عند حدود العمل: الملف موجود بالنسخة المطلوبة، والDeployment يعرض Commit المقصودة، والرسالة لها Provider Delivery ID، أوTicket وصلت إلى الحالة المستهدفة.

توثق معمارية Agents API Streaming وWebhooks لحالة التقدم، وتذكر أن فشل Lifecycle أوFunction-tool Handlers قد يقطع التحديث. تعامل مع هذه Events كملاحظات لا كمصدر الحقيقة الوحيد. طابق Task Ledger مع Target System قبل وضع Success.

سجل أربعة أزمنة: Queue Delay وActive Execution ووقت انتظار الإنسان ووقت الوصول إلى Verified Outcome. Duration واحدة تخفي هل الوكيل بطيء أم البيئة Offline أم Approval هي العائق. راقب Retry Count وعمر الموافقات وانتهاء Lease وUnknown-outcome Writes وإزالة تكرار الأحداث وفشل التحقق.

يجب أن تسمي كل نتيجة دليلها. Coding Task تربط Test Output وSource Revision. وResearch Task تربط Source URLs وتواريخ الاسترجاع. وMutation تربط Provider Receipt منزوعة البيانات الحساسة وRead-after-write Check. لا تخزن Secrets أوبيانات شخصية واسعة كدليل.

يجب أن تفرق حالة المستخدم بين Working وWaiting وBlocked وCompleted وVerified. وإذا احتاج الوكيل قرارًا، اعرض الفعل الدقيق والأثر المتوقع والمورد المتأثر وما يحدث عند انتهاء الطلب.

صمّم الإيقاف والإلغاء والتعافي كعمليات منفصلة

إيقاف Worker وإلغاء Task وتعطيل Schedule وسحب صلاحية App وفصل Computer ليست العملية نفسها. تفصل وثائق Dots صراحة بين إيقاف العمل النشط وإلغاء الجدول المتكرر. يجب أن تجعل المعمارية كل Lifecycle مرئية.

يمنع Cancel Request آثارًا جانبية جديدة أولًا، ثم يرسل إشارة إلى Workers النشطة، وينهي Approvals المعلقة، ويحرك المهمة نحو Safe Checkpoint. إذا كانت Remote Write ربما نُفذت، فالحالة ليست `cancelled` بل `reconciliation_required` حتى فحص Target System. Compensation عملية Business وليست Rollback عامة.

يجب أن يمنع سحب Credentials أي Resolution لاحقة فورًا، لكنه لا يلغي عملًا قبله نظام خارجي. سجل آخر أثر متحقق منه، وأظهر Cleanup غير المكتملة. وإذا أصبح حاسوب متصل Offline، فأوقف المهام التي تحتاجه؛ لا تحولها بصمت إلى Cloud Environment بجلسات ووصول مختلفين.

يبدأ Recovery من Ledger ودليل Target System، لا آخر رسالة مولدة. احصل على Lease جديدة، وتحقق من Permission وصحة Environment، وافحص الخطوات غير المحسومة، ثم استمر من Postcondition Boundary. حد المحاولات التلقائية، وارفع الغموض المتكرر إلى إنسان.

اختبر المسارات الصعبة: Duplicate Triggers، وموافقة بعد الإلغاء، وCrash بعد Mutation، وانتهاء Website Session، وإزالة صلاحية Plugin أثناء التنفيذ، وحاسوب متصل Offline، وحذف Schedule بينما Execution نشطة. هذه السيناريوهات تحدد هل النظام Durable فعلًا.

القرار العملي

تجعل OpenAI Dots فئة الوكلاء الدائمين ملموسة: Agent سحابية تستطيع امتلاك مسؤوليات متعددة وتنسيق أعمال خلفية والاستجابة للوقت أوالأحداث واستخدام بيئات متصلة وطلب قرارات من الإنسان. الإطلاق مهم، لكن Marketing Promise ليست Production Guarantee.

للفرق التي تبني أنظمة مشابهة، المعمارية الدائمة أهم من Agent Loop. اجعل Task Ledger مصدر الحقيقة، وافصل Preference Memory عن Operational Truth، واربط Permission بكل فعل وبيئة، وامنع تكرار Triggers، وتحقق من Business Outcomes، وأعطِ Cancellation معنى صريحًا.

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

إعداد: Noor Yasser