ما هو Open Responses؟

Open Responses هي مواصفة مفتوحة، تُنشر كمستند OpenAPI 3.1، تصف شكل طلب واستجابة واحد لاستدعاء نماذج اللغة عبر مختلف المزوّدين. وهي مبنية على OpenAI Responses API: حيث ترسل model وinput وtools الاختيارية إلى POST /v1/responses، فتحصل على عناصر مُصنّفة وأحداث بث دلالية بدلاً من صيغة خاصة بمزوّد معيّن. أطلقت OpenAI مواصفة Open Responses في 2026-01-15، وهي مرخّصة بموجب Apache 2.0، وفي 2026-10-22 ساهمت OpenAI بها إلى Agentic AI Foundation (AAIF)، وهي هيئة تابعة لمؤسسة Linux تستضيف أيضاً MCP.

الخطوة الأخيرة هي الخبر: أصبح للمواصفة الآن ميثاق تقني ولجنة توجيهية وموطن محايد. يغطي هذا المقال ما تحدده المواصفة، ومن يطبّقها، وما الذي يغيّره انتقالها إلى AAIF، وكيف تتحقق مما إذا كانت نقطة النهاية التي تعتمد عليها متوافقة. إذا كنت جديداً على الـ API الأساسي، فابدأ بـ كيفية استخدام OpenAI Responses API.

ما الذي تحدده Open Responses

تصف المواصفة المشكلة بوضوح: لقد توافق المزوّدون على نفس المكوّنات الأساسية (الرسائل، استدعاءات الأدوات، البث، المدخلات متعددة الوسائط) لكن كل واحد يرمّزها بطريقة مختلفة. تختار Open Responses ترميزاً واحداً وتكتبه.

مستند OpenAPI الحالي هو الإصدار 2026-04-24 ويغطي سطحاً صغيراً:

يقبل جسم الطلب الحقول التي تتوقعها إذا كنت قد استخدمت API الخاص بـ OpenAI: model، input، instructions، tools، tool_choice، stream، store، previous_response_id، reasoning، text، truncation، temperature، top_p، max_output_tokens، prompt_cache_key وغيرها القليل. يحمل كائن الاستجابة (ResponseResource) الحقول id، status، output، usage، error وصدى للإعدادات التي أرسلتها. يحدد المستند 108 مخططات إجمالاً، معظمها أنواع عناصر وأحداث بث.

ثلاث أفكار تحمل التصميم.

العناصر هي وحدة السياق

كل ما يقرأه النموذج أو ينتجه هو عنصر: message، function_call، function_call_output، عنصر reasoning. العناصر ثنائية الاتجاه، لذا يمكن تغذية مخرجات دور واحد مباشرة كمدخلات للدور التالي. يتم تمييز كل نوع عنصر بواسطة حقل type الخاص به وله مخططه الخاص.

العناصر أيضاً آلات حالة: ينتقل كل منها من in_progress إلى completed أو incomplete (نفدت ميزانية الرموز)، ويجب أن يكون العنصر incomplete هو الأخير المُصدَر، مع تمييز الاستجابة بأكملها كغير مكتملة. لا تقول الحالة شيئاً عن ما إذا كان الخادم قد خزّن العنصر؛ الاستمرارية مسألة منفصلة.

البث هو أحداث دلالية، وليس فروقات خام

عند تعيين stream: true، يجب أن يستجيب الخادم بـ Content-Type: text/event-stream وتسلسل أحداث محدد. يفتح عنصر الإخراج بـ response.output_item.added؛ يصل النص داخله كـ response.content_part.added، ثم أحداث response.output_text.delta المتكررة، ثم response.output_text.done وresponse.content_part.done؛ يُغلق العنصر بـ response.output_item.done. يجب أن ينتهي البث بحدث نهائي: response.completed، response.failed أو response.incomplete. علامة [DONE] اللاحقة اختيارية، ويجب على العملاء التعامل مع بث ينتهي بدونها.

هذا مهم أكثر لكود العميل: إذا أصدر مزوّدان نفس الأحداث بنفس الترتيب، فإن محلل SSE واحد يعمل لكليهما. يوضح دليل اختبار SSE الخاص بنا كيفية فحص هذه التدفقات حدثاً بحدث.

نواة مستقرة مع امتدادات ذات مساحات أسماء

يمكن للمزوّدين إضافة أنواع عناصر وأدوات وأحداث بث خاصة بهم، لكن يجب أن يسبقوها بمعرّف المزوّد. مثال المواصفة نفسه هو openai:web_search_call. يمكن للعميل الذي لا يتعرف على نوع مسبوق أن يتخطاه دون أن ينكسر. هكذا تبقى المواصفة قابلة للنقل بينما تظل الأدوات المستضافة مثل البحث على الويب أو البحث في الملفات ميزات خاصة بالمزوّد.

بقية العقد

هناك بعض القواعد الإضافية التي تستحق المعرفة قبل البناء على المواصفة:

• نوعان من الأدوات. الأدوات المستضافة خارجياً (الدوال، خوادم MCP) تعمل خارج المزوّد؛ بالنسبة للدوال، يصدر النموذج function_call، وتقوم أنت بتشغيله، وترسل مرة أخرى function_call_output مع call_id المطابق. الأدوات المستضافة داخلياً (البحث في ملفات OpenAI، على سبيل المثال) تعمل داخل المزوّد دون إعادة التحكم.
• tool_choice وallowed_tools. يأخذ tool_choice القيم auto (الافتراضي)، required، none، أو كائن يسمّي دالة واحدة. يقيّد allowed_tools الأدوات التي يجوز للنموذج استدعاؤها مع الاستمرار في عرضها جميعاً، حتى لا تُبطل مطالبة مخزّنة مؤقتاً عن طريق تعديل مصفوفة tools. يجب على الخوادم فرضه كحد صارم.
• previous_response_id. يجب أن يعامل الخادم الطلب الجديد كـ previous_response.input + previous_response.output + input، بهذا الترتيب، حتى لا تعيد إرسال النص الكامل.
• عناصر التفكير قد تحمل content خام، أو كتلة encrypted_content غير شفافة، أو summary آمن للمستخدم، أو أي مزيج.
• الأخطاء تحمل type (server_error، invalid_request، not_found، model_error، too_many_requests)، بالإضافة إلى code، param وmessage؛ في منتصف البث، يتبع الخطأ response.failed.

أضاف مراجعة 2026-04-24 (سجل التغييرات) نقل WebSocket: يبدأ كل دور برسالة response.create، ويعالج اتصال واحد استجابة واحدة في كل مرة، ويُحدّ الاتصال بـ 60 دقيقة (رمز الخطأ websocket_connection_limit_reached)، وتعيش استمرارات store: false في ذاكرة محلية للاتصال، وتفشل بـ previous_response_not_found بمجرد زوال تلك الحالة. أضافت نفس المراجعة /responses/compact، وحقل phase اختياري على رسائل المساعد (commentary أو final_answer)، وجعلت logprobs اختيارياً.

Open Responses مقابل Chat Completions

لا يزال Chat Completions هو واجهة LLM الأكثر نسخاً على نطاق واسع. الفرق في الشكل: يعيد Chat Completions خيارات تحتوي على رسالة، مع استدعاءات أدوات مخبأة داخلها، بينما يعيد نموذج Responses قائمة مسطحة من العناصر المصنفة. تصبح خطوة التفكير وثلاثة استدعاءات أدوات ورسالة نهائية كائنات منفصلة ومرتبة بحالتها الخاصة، وهو ما يناسب حلقات الوكيل بشكل أفضل.

قارنّا التنسيقات الثلاثة السائدة جنباً إلى جنب، مع طلبات حقيقية، في Chat Completions مقابل Anthropic Messages مقابل Responses API. إذا كنت تختار بين واجهات OpenAI نفسها، فإن تفصيل Agents API مقابل Responses API مقابل Agents SDK يغطي أين يقع Responses.

من يطبّقها

تشمل قائمة الداعمين AWS Bedrock وDatabricks وHugging Face وLM Studio وNvidia وOllama وOpenRouter وRed Hat وVercel وvLLM، إلى جانب OpenAI. Anthropic وGoogle ليستا بين الداعمين المذكورين؛ كلاهما لا يزال يوفّر تنسيقاته الأصلية.

كلمة "يدعم" تغطي نطاقاً واسعاً، لذا تحقق من التفاصيل لبيئة التشغيل التي تستخدمها:

• Ollama أضاف POST /v1/responses في الإصدار v0.13.3. تقول وثائق التوافق الخاصة به "يُدعم فقط النوع غير الحافظ للحالة": البث وأدوات الدوال وملخصات التفكير تعمل، لكن previous_response_id وconversation وtruncation لا تعمل. أنت تعيد إرسال السجل بنفسك.
• LM Studio جعل نقطة النهاية http://localhost:1234/v1/responses الخاصة به متوافقة في الإصدار 0.3.39، بما في ذلك previous_response_id وعناوين URL للصور البعيدة لنماذج الرؤية وlogprobs. راجع دليل LM Studio للإعداد.

لإدراك الحجم، أخذ API Evangelist خط أساس في 13 سبتمبر: من بين 120 مزوّداً يدّعون التوافق مع OpenAI وينشرون مستند OpenAPI قابلاً للقراءة، يعلن 26 منهم عن POST /responses، مقابل 105 يعلنون عن POST /chat/completions. الهدف من خط الأساس هو قياس ما إذا كانت الحوكمة المحايدة تحرّك هذا الرقم.

ما الذي يغيّره الانتقال إلى Agentic AI Foundation

أعلنت AAIF عن Open Responses في 2026-10-22 في AGNTCon + MCPCon أمريكا الشمالية في سان خوسيه، إلى جانب ثلاثة مشاريع جديدة أخرى: Agent Skills (من Anthropic)، OpenEnv (من Hugging Face) وOpenSandbox (من Alibaba). هذا يرفع AAIF إلى 10 مشاريع مستضافة في عامها الأول، بجانب MCP وبروتوكول Agent2Agent وAGENTS.md وgoose وagentgateway وAgent Router. إذا كنت تحاول ترتيب كيفية ترابط هذه، فإن شرح MCP مقابل A2A الخاص بنا هو بداية جيدة.

ما الذي يتغير:

• الحوكمة. المشروع الآن "Open Responses a Series of LF Projects, LLC"، مع ميثاق تقني تم تبنيه في 2026-10-21. لجنة توجيه تقنية، في البداية هم مشرفو المشروع، تمتلك القرارات التقنية، والمشاركة مفتوحة لأي شخص يتبع الميثاق.
• المصداقية للمزوّدين الآخرين. المواصفة المملوكة لشركة واحدة هي منتج. المواصفة تحت مؤسسة أسهل على المنافس لتبنيها دون أن يبدو وكأنه يتبع منافساً.

ما الذي لا يتغير:

• API الخاص بـ OpenAI. يحتفظ Responses API على api.openai.com بميزاته وجدول إصداراته الخاصة. تصف Open Responses النواة القابلة للنقل؛ تبقى الأدوات الخاصة بـ OpenAI خلف البادئة openai:.
• تنسيق النقل. لم يأتِ إصدار مواصفة جديد مع الانتقال. لا يزال أحدث إصدار هو 2026-04-24، والإصدارات المؤرخة غير قابلة للتغيير.
• المطابقة. كونك على قائمة الداعمين لا يعني أن نقطة النهاية تجتاز الاختبارات. لا أحد ينشر فهرس نجاح/فشل بعد، لذا تتحقق من نقاط النهاية التي تعتمد عليها بنفسك.

تحقق من نقطة نهاية باستخدام اختبارات القبول

يشحن المشروع اختبارات القبول الخاصة به. تشغّل صفحة الامتثال 10 اختبارات في المتصفح مقابل أي عنوان URL أساسي ونموذج ومفتاح: استجابة نصية أساسية، البث، موجه النظام، استدعاء الأدوات، إدخال الصور، سجل متعدد الأدوار، تسميات phase للمساعد، نقطة نهاية الضغط، واختبار سلبي لطلب مضغوط يفتقد model. سبعة اختبارات WebSocket إضافية (أدوار متتالية، استمرار store: false، استرداد إعادة الاتصال، إخلاء ذاكرة التخزين المؤقت بعد استمرار فاشل) تعمل فقط من سطر الأوامر:

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

يحصل كل طلب HTTP وكل دور WebSocket على مهلة 30 ثانية، وفشل المهلة يفشل ذلك الاختبار فقط. توقع أن تفشل بيئة تشغيل غير حافظة للحالة مثل Ollama في اختبارات الاستمرار بحكم التصميم.

دع وكيل البرمجة الخاص بك يختبره باستخدام Apidog CLI

تخبرك اختبارات القبول ما إذا كان الخادم يتبع المواصفة اليوم. إنها لا تراقب نقطة النهاية التي يستدعيها تطبيقك في كل مرة تنشر فيها أو ترقّي Ollama أو تبدّل مزوّداً. لذلك، استورد المواصفة إلى مشروع Apidog ودع وكيل البرمجة الخاص بك يكتب ويشغّل اختبارات الانحدار مقابلها باستخدام Apidog CLI.

ثبّت CLI ومهارة الوكيل مرة واحدة:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

ثم أعطِ Claude Code أو Codex أو Cursor مطالبة واحدة:

Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project <id>. Create an environment "local-ollama" with base URL
http://localhost:11434/v1. Add test cases for POST /responses: one that expects 200,
status "completed" and an output item of type "message"; one with stream: true that
expects text/event-stream ending in response.completed; one without "model" that
expects a 4xx error with an error.type field. Run them and summarize any failures.

يقرأ الوكيل المخططات، ويتحقق من صحة حمولاته قبل كتابة أي شيء، ويشغّل الحالات:

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

يشير إدخال servers في المواصفة إلى https://api.openai.com/v1، لذا أضف بيئة واحدة لكل مزوّد وشغّل نفس الحالات مقابل كل منها: هذا هو ادعاء قابلية النقل، مُختبَراً. ضع سطر apidog run ... -r junit في خط أنابيبك حتى يفشل البناء عند ترقية بيئة تشغيل تُسقط حقلاً (دليل CI/CD)؛ يغطي Apidog CLI في Claude Code إعداد الوكيل بالتفصيل.

الأسئلة الشائعة

هل Open Responses هي نفسها OpenAI Responses API؟ لا. Open Responses هي مواصفة مشتقة منها. Responses API الخاص بـ OpenAI هو تطبيق واحد بميزات إضافية خاصة بـ OpenAI؛ Ollama وLM Studio وvLLM تطبيقات أخرى.

من يملك Open Responses الآن؟ منذ 2026-10-22 أصبحت مشروعاً تابعاً لـ Agentic AI Foundation تحت مؤسسة Linux، يُدار كسلسلة LF Projects مع لجنة توجيه تقنية. وهي مرخّصة بموجب Apache 2.0.

هل تدعم Anthropic مواصفة Open Responses؟ Anthropic ليست بين الداعمين المذكورين. لقد ساهمت بـ Agent Skills إلى AAIF في نفس اليوم، لكن الواجهة الأصلية لـ Claude لا تزال هي Messages API.

أين ملف المواصفة؟ على https://www.openresponses.org/openapi/openapi.json، مع إصدارات مؤرخة في مستودع GitHub.

الخطوة التالية

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