عندما يحتاج طلب الذكاء الاصطناعي إلى وقت طويل، قد لا يكون إبقاء اتصال العميل مفتوحًا طوال التنفيذ خيارًا مناسبًا. يتيح وضع الخلفية Background mode في Responses API بدء إنشاء الرد بصورة غير متزامنة، ثم الرجوع إلى الرد نفسه لمعرفة حالته وقراءة النتيجة. هذا دليل تقني للتحضير لعام 2027 وفق الإمكانات التي روجعت في 27 أكتوبر 2026، وليس إعلانًا عن إصدار مستقبلي.
بدء الطلب وحفظ معرفه
أرسل طلب إنشاء الرد إلى POST /v1/responses مع background: true، واختر نموذجًا يدعم هذا الوضع. احفظ قيمة id من الاستجابة، لأنها الرابط بين طلب الإنشاء وعمليات المتابعة والإلغاء. تفعيل الخلفية لا يعني أن الناتج أصبح جاهزًا فور استلام المعرف؛ راقب حقل الحالة بدل عرض الطلب للمستخدم على أنه مكتمل.
الاستعلام حتى الحالة النهائية
استخدم GET /v1/responses/{response_id} لاسترجاع الرد. ما دامت status تساوي queued أو in_progress، يستمر الانتظار والاستعلام على فترات بدل إرسال طلب إنشاء جديد. الخروج من هاتين الحالتين يعني الوصول إلى حالة نهائية، لكنه لا يعني النجاح بالضرورة.
تحقق من أن الحالة completed قبل معاملة النص باعتباره نتيجة مكتملة. وإذا كانت failed فافحص error، وإذا كانت incomplete فافحص incomplete_details. احتفظ بالمعرف والحالة في تطبيقك حتى لا تخلط ردًا متوقفًا بنتيجة نهائية ناجحة.
إلغاء التنفيذ الجاري
لإلغاء رد أنشئ في الخلفية، استخدم POST /v1/responses/{response_id}/cancel. يخص هذا المسار الردود التي أنشئت مع background: true، وليس كل طلب متزامن. وإذا كررت الإلغاء، تعيد الاستدعاءات التالية كائن الرد النهائي بدل إنشاء عملية إلغاء جديدة. اقرأ الحالة المعادة؛ فلا تفترض من مجرد إرسال أمر الإلغاء أن النتيجة كانت ناجحة أو أن كل مخرجاتها مكتملة.
البث واستئنافه بعد انقطاع الاتصال
إن أردت البث وإمكانية استئنافه لاحقًا، أنشئ الرد منذ البداية مع background: true وstream: true. احتفظ بمعرف الرد وآخر sequence_number لحدث مخزن استلمته. أحداث keepalive تستخدم عدادات اتصال، فلا تجعلها مؤشر الاستئناف بدل أحداث الرد المخزنة.
عند الانقطاع، استأنف باسترجاع المعرف نفسه مع stream=true وstarting_after بقيمة المؤشر المحفوظ. لا يمكنك بدء بث جديد من رد خلفية لم تنشئه أصلًا مع stream=true. كما أن زمن وصول أول رمز في وضع الخلفية أعلى حاليًا من الطلب المتزامن؛ فلا تختره لمجرد توقع رد أول أسرع.
انتبه إلى الاحتفاظ بالبيانات
يخزن وضع الخلفية بيانات الرد مؤقتًا على القرص لنحو عشر دقائق لدعم التنفيذ والاستعلام، حتى مع store=false. وتعمل طلبات مشاريع Zero Data Retention بهذا الإعداد، لكن التخزين المؤقت يظل قائمًا. لذلك لا تفسر الاسم على أنه انعدام أي كتابة مؤقتة.
في مشاريع Modified Abuse Monitoring، ومنها النسخة المحسنة، يحتاج الاحتفاظ برد الخلفية بعد فترة الاستعلام إلى إرسال store=true صراحة. إذا حذفت هذا الخيار أو جعلته false، يحذف الرد بعد الفترة المؤقتة. راجع سياسة مشروعك قبل اختيار التخزين، ولا تعتمد على المعرف وحده كأرشيف دائم للنتائج.
