إيقاف Assistants API: خطة ترحيل عملية إلى Responses API دون فقدان المحادثات أو التحكم

ياسر نجيب
•
•
آخر مراجعة:
•
6 دقائق قراءة

تحدد وثائق OpenAI الرسمية يوم 26 أغسطس 2026 لإيقاف Assistants API. في تاريخ مراجعة هذا المقال، هذا هو موعد الإيقاف المعلن، وليس دليلاً مني على أن كل endpoint توقف بالفعل في كل منطقة وفي هذه الساعة. لكن الانتظار لم يعد خطة تشغيل: أي منتج ما زال ينشئ Assistants أو Threads أو Runs يحتاج مسار انتقال فوري ومختبر إلى Responses API.

تقول OpenAI إن Responses وصلت إلى التكافؤ المطلوب وتقدم نموذجاً أبسط: تتحول Assistants إلى إعدادات وتعليمات، وThreads إلى Conversations، وRuns إلى Responses، وRun Steps إلى Items. كما تتوفر أدوات أحدث مثل البحث والملفات وMCP واستخدام الكمبيوتر. هذا ليس تغيير اسماء فقط، لأن ملكية الحالة ودورة الأدوات والتخزين والمراقبة تتغير.

دليل الترحيل الرسمي من OpenAI والصفحة القديمة التي توضح تاريخ الإيقاف

ابدأ بجرد حقيقي لا بالبحث والاستبدال

ابحث في الكود واللوحات وقاعدة البيانات عن:

  • مفاتيح assistant_id وthread_id وrun_id.
  • استدعاءات /v1/assistants و/v1/threads و/v1/runs.
  • polling لحالات Run مثل requires_action وcompleted.
  • File Search وVector Stores وCode Interpreter.
  • التعليمات والأدوات المخزنة في Assistant دائم.
  • webhooks، مهام background، dashboards وتنبيهات التكلفة.

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

صمم طبقة توافق مؤقتة

أفضل ترحيل ليس commit يبدل SDK في كل مكان. أنشئ واجهة داخلية مثل generateReply, searchFiles وexecuteToolLoop، ثم ضع خلفها adapter للقديم وآخر لـ Responses. احتفظ بعقد ثابت يصف المدخلات والمخرجات والأخطاء والاستخدام.

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

من Assistant إلى إعداد قابل للنسخ والمراجعة

كان Assistant يجمع النموذج والتعليمات والأدوات في جسم دائم. يقترح دليل OpenAI استخدام prompts قابلة للإصدار، لكنه ينبه أيضاً إلى أن reusable prompt objects نفسها لها timeline إيقاف معلن. لذلك راجع صفحة deprecations قبل اعتمادها كطبقة دائمة.

في كثير من الأنظمة، الخيار الأكثر وضوحاً هو تخزين مواصفة التعليمات والأدوات وإصدارها في مستودع آمن، ثم تمرير النسخة أو معرفاً مُداراً مع كل Response. افصل secret عن prompt، واجعل كل تغيير قابلاً للمراجعة والرجوع. سجل prompt_version وmodel وtool schema version مع النتيجة حتى تستطيع تفسير اختلاف السلوك.

من Threads إلى Conversations

تخزن Conversations عناصر أوسع من الرسائل، ومنها tool calls وoutputs. لا توفر OpenAI ترحيلاً آلياً لكل Threads إلى Conversations. تقترح نقل المحادثات الجديدة أولاً، وترحيل القديمة عند الحاجة. هذا يقلل التكلفة والمخاطر مقارنة بنسخ تاريخ لا يفتحه أحد.

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

من Runs إلى Responses ودورة أدوات صريحة

كانت Run تحمل حالات متعددة وتطلب إرسال tool outputs عند requires_action. في Responses تصبح المخرجات Items، وقد تحتاج خدمة التطبيق إلى إدارة الحلقة بوضوح. ضع سقفاً لعدد الأدوات والوقت والتكلفة، وحقق arguments قبل التنفيذ، وأعد output منظماً.

اختبر على الأقل:

  1. رد بلا أداة.
  2. أداة قراءة ناجحة.
  3. عدة أدوات متتابعة.
  4. timeout ثم retry بلا تنفيذ مكرر.
  5. أداة كتابة تتطلب موافقة المستخدم.
  6. output ناقص أو schema غير صالح.
  7. stream ينقطع بعد tool call.

لا تسمح للنموذج بتنفيذ الدفع أو الحذف أو النشر لمجرد أنه أنتج arguments صحيحة. authorization وidempotency والتأكيد مسؤولية التطبيق.

البيانات والاحتفاظ ليستا متطابقتين

توضح صفحة ضوابط البيانات أن Responses تُخزن application state افتراضياً لمدة 30 يوماً عندما يكون store مفعلاً، بينما Conversations وعناصرها لها سلوك مختلف، وبعض الأدوات أو background mode لها قيود Zero Data Retention. كذلك تخضع MCP servers الخارجية لسياسة مزودها.

قبل الترحيل، اكتب مصفوفة لكل endpoint وأداة: ما الذي يرسل، أين يخزن، مدة الاحتفاظ، المنطقة، ومن يستطيع الوصول. اختبر store: false عندما يلزم، ولا تفترض أن إعداد Assistants القديم انتقل تلقائياً. افصل المشاريع والعملاء، واحتفظ بالتحقق من صلاحية المستخدم أمام كل Conversation وملف.

ضوابط البيانات الرسمية لمنصة OpenAI

التكلفة قد تتغير حتى لو بقي النموذج نفسه

لا توجد رسوم ترحيل منفصلة معلنة. الفاتورة تأتي من النموذج والتوكنات والأدوات والتخزين ونمط المعالجة. قد تتغير التكلفة لأن Responses تحفظ reasoning بين الخطوات، أو لأن الحلقة تستدعي أدوات أكثر، أو لأنك استبدلت polling بـ streaming، أو نقلت ملفات وvector stores.

في 26 أغسطس 2026 راجعت صفحة الأسعار الحالية، ومنها اختلاف Standard وBatch وFlex وFast، ورسوم بعض الأدوات والمعالجة الإقليمية. لا أنسخ رقماً واحداً باعتباره تكلفة المنتج. سجل input وcached input وoutput وtool usage لكل مهمة، ثم قارن تكلفة النتيجة المقبولة قبل وبعد على نفس حالات الاختبار.

تسعير OpenAI API الحالي

بوابة إطلاق لا تتسامح مع النجاح الشكلي

أنشئ corpus من محادثات منزوعة الحساسية تشمل العربية والإنجليزية والأدوات والملفات والأخطاء. قارن:

  • صحة الإجابة والاستشهادات.
  • اكتمال structured output.
  • عدد استدعاءات الأدوات وإعادة المحاولة.
  • latency ووقت أول token.
  • التكلفة لكل نتيجة مقبولة.
  • refusal والأخطاء الأمنية.
  • استكمال المحادثة بعد انقطاع.

شغّل المسار الجديد في shadow إن أمكن، ثم 1% و10% و50% مع stop conditions. أوقف التوسع عند فقدان سياق أو مضاعفة عملية أو زيادة تكلفة غير مفسرة. راقب provider errors منفصلة عن أخطاء التطبيق.

قائمة الترحيل

  1. جمّد أي تطوير جديد على Assistants API.
  2. اجرد IDs والمسارات والأدوات والملفات والمالكين.
  3. أنشئ adapter داخلياً بعقد واحد.
  4. انقل المحادثات الجديدة إلى Responses أولاً.
  5. رحّل التاريخ عند الطلب مع تحقق الملكية.
  6. اختبر tool loops وstreaming والوقت والتكرار.
  7. راجع التخزين وZDR والمنطقة والصلاحيات.
  8. قارن الجودة والتكلفة على corpus ثابت.
  9. راقب النشر وأوقفه عند شروط الفشل.
  10. احتفظ بنسخة بيانات قابلة للاسترجاع وفق سياسة المنتج، ثم أزل الكود القديم بعد إثبات عدم استخدامه.

توصية عملية

إذا كان منتجك لا يزال على Assistants اليوم، اجعل الترحيل incident-level work لا تحسيناً في backlog. لكن لا تتجاوز الاختبارات لتلحق التاريخ. انقل المسارات الجديدة أولاً، أغلق إنشاء Threads القديمة، ثم عالج التاريخ والملفات حسب الاستخدام الحقيقي.

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

المصادر وتاريخ المراجعة

اقرأ أيضاً