يضيف GPT‑6 ميزتين تغيّران طريقة عمل الوكيل التفاعلي: تسمح الأدوات غير المتزامنة للنموذج بمتابعة عمل مستقل بينما تنفذ المنظومة أداة بطيئة، ويتيح التوجيه أثناء التنفيذ للمستخدم إضافة قيد أو تغيير الهدف عبر WebSocket في Responses API قبل انتهاء المهمة. قد تقللان وقت الانتظار وتسمحان بتصحيح المسار مبكرًا، لكنهما لا تقدمان Workflow Engine، ولا تلغيان أثرًا حدث، ولا تستبدلان التفويض والحالة الدائمة والتعافي. لذلك يجب أن يكون النموذج طرفًا داخل State Machine صريحة، لا مالك العملية كاملة.
قدمت OpenAI هذه الضوابط مع GPT‑6 في 3 سبتمبر 2026، وتم التحقق من الوثائق الرسمية في 5 أكتوبر 2026. السلوك المدعوم المنسوب إلى API حقيقة موثقة من OpenAI، أما نموذج الحالة والميزانيات وقواعد الإطلاق والمراقبة فهي توصيات هندسية.
ما الذي أضافته OpenAI فعليًا؟
يسجل سجل تغييرات OpenAI API الأدوات غير المتزامنة والتوجيه أثناء التنفيذ ضمن قدرات GPT‑6 في Responses API. توضح وثيقة Async Tool Calling أن إضافة `async: true` إلى Function أو Custom Tool تنفذها المنظومة تسمح للنموذج بمتابعة العمل بعد إصدار الاستدعاء. يظل التطبيق مسؤولًا عن التنفيذ، ثم يعيد النتيجة لاحقًا باستخدام `call_id` الأصلي. وهذا مختلف عن Background Mode الذي يجعل توليد الاستجابة نفسه غير متزامن.
توثق وثيقة Mid-turn Steering حدث `response.steer` فوق WebSocket. يضع مدخل المستخدم الجديد في طابور مرتبط باستجابة تعمل، وقد ينشئ متابعة تلقائية. قبول الحدث يعني أنه دخل الطابور، لا أن النموذج طبقه. كما لا يعيد التوجيه كتابة ما ظهر، ولا يلغي أثرًا حدث، ولا يوقف أداة بدأت أصلًا.
لهذا قد توجد عدة حالات صحيحة في اللحظة نفسها: الاستجابة تبث نصًا، وأداتان معلقتان، والمستخدم غيّر الهدف، وأثر خارجي اكتمل. متغير واحد مثل `isRunning` لا يمثل ذلك بأمان.
افصل ثلاث آلات حالة تتعاون معًا
افصل حالة الاستجابة عن حالة الأدوات وعن حالة المنتج. حالة الاستجابة تشمل created وstreaming وsteered وcompleted وincomplete وfailed. حالة الأداة تشمل proposed وauthorized وdispatched وsucceeded وfailed وtimed-out وreconciled. أما حالة المنتج فتسجل الحقيقة التجارية: تم حجز الطلب، حُفظت المسودة، أو أُرسل طلب النشر.
احفظ المعرفات والعلاقات بينها. يتضمن سجل التنفيذ المفيد `conversation_id` و`response_id` و`call_id` و`task_handle` من التطبيق واسم الأداة والعميل والفاعل وقرار التفويض وIdempotency Key والمهلة والمحاولة والحالة ومرجع النتيجة. يفيد Response ID في متابعة النموذج، لكنه ليس معرف المعاملة التجارية.
{
"execution_id": "exec_42",
"response_id": "resp_1",
"call_id": "call_inventory",
"task_handle": "inventory_7",
"tool": "check_inventory",
"status": "running",
"deadline_at": "2026-10-05T20:05:00Z",
"idempotency_key": "tenant:7:inventory:sku-91:v1"
}هذا سجل تطبيقي مقترح وليس Schema من OpenAI. اجعله دائمًا بما يكفي لتجاوز إعادة تشغيل الخدمة أو انقطاع Socket أو إعادة محاولة Worker.
استخدم Async عندما يكون العمل مستقلًا فعلًا
تحويل كل أداة إلى Async يصنع تزامنًا بلا قيمة. الحالات المناسبة هي عمليات القراءة البطيئة، واستدعاءات الاسترجاع المستقلة، وتحليل الملفات، وطلب معلومة من المستخدم، والحسابات التي تحتاج نتيجتها في مرحلة لاحقة. يستطيع النموذج كتابة الجزء الثابت أو إطلاق أكثر من Lookup أو شرح التقدم بينما تعمل المهام.
أبقِ الأداة متزامنة عندما يعتمد القرار التالي فورًا على نتيجتها، أو عندما يكون الترتيب ثابتًا تجاريًا، أو عندما يغير التنفيذ الصلاحية. يجب أن يكتمل Payment Authorization عادة قبل Capture، ولا ينبغي أن يسبق Migration الفحص الذي يقرر السماح بها. العمل المتوازي آمن فقط عندما تكون التبعيات معلنة.
تقول الوثائق إن Async ينطبق على Functions وCustom Tools التي ينفذها التطبيق، لا Built-in Tools المستضافة، وإنه مدعوم في GPT‑6 Astra والنماذج اللاحقة. كما تحذر من جمع Async Tools مع Parallel Tool Calls في Multi-agent Mode. افحص التوافق في بيئة النشر بدل افتراضه من نموذج أو أداة أخرى.
ابنِ سجلًا للأعمال المعلقة وأداة انتظار حقيقية
يعيد المزود `call_id`، لكن التطبيق يحتاج Registry خاصًا للمهام والنتائج والمحاولات. تقترح وثيقة OpenAI `task_handle` فريدًا لكل استدعاء غير متزامن، وFunction عادية متزامنة باسم مثل `wait_for_tasks`. هذه Pattern يملكها التطبيق وليست أداة مدمجة في OpenAI. تسمح للنموذج بالانتظار فقط عندما تعتمد خطوته التالية على نتائج بعينها.
سجّل كل مهمة قبل تلبية انتظار يعتمد عليها، واربط Handle بالـCall ID الأصلي، وارفض إعادة استخدامه خلال المحادثة. عند اكتمال المهام، أعد كل `function_call_output` إلى `call_id` الأصلي قبل حالة أداة الانتظار. احفظ الاكتمال قبل إرساله للنموذج كي لا يؤدي انقطاع الاتصال إلى إعادة الأثر الخارجي.
لا تجعل سياق النموذج طابورك. يجب أن تملك قاعدة بيانات أو Workflow Engine الـleases والـheartbeats والمهل وطلبات الإلغاء والنتائج النهائية. يأخذ النموذج Projection مختصرة من تلك الحالة.
عامل Steering كمتطلب جديد لا كزر إلغاء
قد يقول المستخدم أثناء التنفيذ: «اجعل الخطة مناسبة لمهندس واحد» أو «لا تتواصل مع المورد». قد تنتهي الاستجابة المقاطعة كـincomplete بسبب `steered`، أو تكتمل ثم تتبعها استجابة جديدة. ترث المتابعة إعدادات الطلب الأصلي، لكن حدود التوكنات واستدعاءات الأدوات تطبق لكل Response على حدة.
على التطبيق تصنيف التحديث. تفضيل في شكل العرض يؤثر على النص اللاحق فورًا. تقليل النطاق قد يلغي أعمال قراءة لم تبدأ. قيد أمني جديد يجب أن يمنع أي أثر لم يُرسل. أما الأثر المكتمل فيحتاج Reconciliation؛ النص لا يمحوه. يجب أن تقول الواجهة بصدق: «طبقت القيد على العمل المتبقي، لكن الحجز السابق كان قد أُنشئ وبدأت عملية عكسه».
لا تحول Steering مباشرة إلى Kill للعملية. سجّل نية الإلغاء، واجعل كل Worker يتوقف عند نقطة آمنة، واحتفظ بما اكتمل. في الإجراءات غير القابلة للعكس أو مرتفعة التكلفة استخدم Approval Token مرتبطًا بالفعل والحجج والعميل والفاعل والانتهاء. يستطيع توجيه لاحق سحب إذن مستقبلي، لكنه لا يعيد كتابة موافقة استهلكت.
طابق المخرجات مع الآثار الحقيقية
قد تترك الاستجابة المقاطعة خلفها عمل أدوات مفيدًا. قبل المتابعة، اقرأ سجل التنفيذ وقسم الاستدعاءات إلى: لم تبدأ، تعمل، اكتملت، فشلت، أو حالتها غير مؤكدة. مرر النتائج المتحققة للأعمال المكتملة. أبقِ الجاري أو ألغِه بحسب التبعية والسياسة. وفي الحالة غير المؤكدة، اسأل النظام الرسمي عبر Idempotency Key قبل إعادة المحاولة.
ينبغي لأدوات الآثار الجانبية إعادة معرف مورد وإصدار وحالة، لا نص فقط. نتيجة `create_shipment` مثلًا تعيد Shipment ID والحالة وSource Version، ثم تستند الإجابة النهائية إلى حقيقة قابلة للتحقق. إذا تعذر التحقق يمتنع الوكيل أو يطلب مراجعة بدل إعلان نجاح غير مؤكد.
اجعل التعويض عملية صريحة. Refund عملية جديدة بتفويضها وفشلها المحتمل، وليست مسحًا سحريًا لعملية Charge. صمّم Saga وفق معنى العمل، ودع Steering يختار انتقالًا مسموحًا بدل اختراع Rollback غير موجود.
صمّم مسارات WebSocket والتعافي
يتطلب Mid-turn Steering وضع WebSocket. توثق OpenAI ترتيب FIFO للطلبات التي تحمل `stream_id` نفسه، وتشغيل المسارات المختلفة بالتوازي، وحد اتصال أقصى يبلغ 60 دقيقة. Socket تحسين للنقل وليس مخزن حالة. أعد الاتصال قبل الحد أو عنده، واستأنف كل Lane من حالة التطبيق الدائمة.
إذا أمكن حل Response محفوظ فتابع باستخدام `previous_response_id`. وإذا عاد `previous_response_not_found` فابدأ Response جديدة مع السياق الضروري أو Context مضغوط. لا تعِد الآثار لأن متابعة النموذج تغيرت؛ أعد تحميل نتائج الأدوات المكتملة من Registry واحتفظ بمعرفاتها التجارية الأصلية.
استخدم Lane واحدة للمهمة الأساسية، وافتح Lanes منفصلة فقط لعمل يمكنه التداخل حقًا. ضع حدًا لعدد المسارات لكل مستخدم وعميل، وإلا سيحول التزامن اعتمادًا خارجيًا بطيئًا إلى تراكم ضخم من الأعمال المعلقة.
افرض المهل وتصنيفات Retry والميزانيات
تحتاج كل Response وأداة وانتظار مستخدم إلى Deadline. مرر الميزانية المتبقية للـWorkers وتوقف عن بدء ما لا يستطيع الانتهاء ضمنها. تميز وثيقة أخطاء OpenAI بين `429 slow_down` الناتج عن زيادة الحركة بسرعة و`503 server_is_overloaded` الناتج عن نقص مؤقت في السعة؛ وقد يتضمن كلاهما `Retry-After`. احترم الترويسة، واستخدم Backoff محدودًا مع Jitter عند غيابها، واحتفظ بمهلة المهمة الأصلية.
أعد محاولة أعطال النقل فقط عندما تكون العملية Idempotent أو قابلة للمطابقة. لا تعد تلقائيًا الحجج غير الصالحة أو الموافقات المرفوضة أو حدود الإنفاق أو رفضًا تجاريًا حتميًا. احسب محاولات SDK والتطبيق معًا، فقد تستمر Retry Storm مخفية بعد أن يوجه المستخدم المهمة إلى مسار آخر.
ضع ميزانية للتوكنات واستدعاءات الأدوات والمهام المعلقة والوقت والإنفاق الخارجي. ينشئ Steering Response جديدة بحدودها الخاصة، لذلك أضف سقفًا على مستوى Execution كاملة.
أبقِ التفويض خارج النموذج
قد يقترح النموذج استدعاء أداة Async، لكن الكود الموثوق يوثق الفاعل، ويشتق نطاق العميل، ويتحقق من الحجج، ويقرر الحاجة إلى موافقة. خزّن قرار التفويض بجانب الاستدعاء، وأعد فحص الحقائق المتغيرة قبل Dispatch، خصوصًا بعد انتظار طويل للمستخدم.
لا تضع Credentials في Tool Output أو أحداث WebSocket. يحصل Worker على وصول ضيق وقصير للمورد المطلوب. يستطيع Steering تضييق النطاق المستقبلي، ولا يجوز أن يوسعه دون قرار Policy موثوق جديد. طبق القاعدة نفسها على Retry والتعويضات.
تعامل مع وصف الأداة كإشارة للجدولة لا كسياسة. يجب ألا يغير Prompt Injection داخل محتوى مسترجع الأدوات المسموحة أو العميل المستهدف أو اشتراط الموافقة على فعل لا رجعة فيه.
راقب المسار كاملًا وقيّمه
اربط Response IDs وSteering IDs وCall IDs وTask Handles بمعرف Execution واحد. سجّل تأخير الطابور ومدة الأداة ووقت أول مخرج مفيد وعدد التوجيهات والعمل المهدر وزمن الإلغاء والمحاولات والمطابقة والتكلفة ونتيجة المهمة المتحققة. تجنب تسجيل Prompts أو Credentials أو Payloads حساسة.
يجب أن تشمل التقييمات تصحيحًا متأخرًا من المستخدم، وأداتين تنتهيان بترتيب مختلف، وإعادة اتصال، وتسليمًا مكررًا، وTimeout، وأداة تنجح بعد طلب الإلغاء، وResponse سابقة مفقودة، وموافقة سحبت قبل Dispatch. قيّم هل تعكس الإجابة الحالة الرسمية، وهل حدث كل أثر مرة واحدة، وهل أثر تحديث المستخدم في كل العمل المتبقي المؤهل.
قارن التصميم غير المتزامن بخط أساس متزامن. لا يصبح التوازي مفيدًا إلا إذا قلل زمن الإنجاز أو حسن التجربة دون زيادة الأفعال الخاطئة أو العمل المهدر أو التعقيد التشغيلي أكثر من فائدته.
متى لا تستخدم هذه القدرات؟
استخدم Function Calling العادي لمسار خطي قصير بأدوات سريعة وترتيب صارم. استخدم Background Job أو Workflow Engine عندما لا يحتاج المستخدم إلى Stream تفاعلي. واستخدم خدمة حتمية أو SQL عندما لا يتطلب المسار استدلالًا. لا تحتاج عملية Extraction ثابتة المدخلات إلى Mid-turn Steering.
تجنب Async عندما لا تقدم الأنظمة الخارجية Idempotency أو استعلام حالة، أو عندما تفرض السياسة موافقات متسلسلة، أو عندما لا يستطيع الفريق رؤية العمل المعلق. وتجنب Steering في عملية تعرضها الواجهة كذرية إن لم يستطع المنتج شرح الاكتمال الجزئي بصدق.
قائمة إطلاق للإنتاج
ابدأ بأدوات قراءة فقط وراقب قرارات المجدول دون تغيير السلوك. أضف جدول Pending Work دائمًا ومهلًا وIdempotency قبل الآثار الجانبية. اختبر إعادة اتصال WebSocket و`previous_response_not_found`. ثم فعّل Steering لتفضيلات المخرجات وتقليل النطاق قبل اقترابه من عمليات التعديل.
أطلق لشريحة صغيرة مع Control Group متزامنة. حدد مسبقًا حدود التراجع لتكرار الآثار والنتائج غير المؤكدة والمهام المهجورة وتراجع الكمون وتضخم Retry والكلفة لكل إنجاز متحقق وفشل تصحيح المستخدم. احتفظ بـKill Switch يعيد الأدوات إلى الوضع المتزامن دون تغيير التفويض أو Schemas.
القاعدة الأساسية: يغير التزامن والتوجيه جدول التنفيذ، لا مصدر الحقيقة. تملك حالة التطبيق الدائمة المهام والآثار التجارية، وتملك السياسة الموثوقة الصلاحيات، بينما يخطط النموذج ويشرح داخل تلك الحدود. اربط هذا التشغيل مع توجيه GPT‑6.1 Sol، وتقييم مسار وكلاء MCP، وتنفيذ وكلاء AI الدائم.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
