Gemini 4 Argon في OpenCode: الإعداد والقيود الحالية

يمكن إعداد Gemini 4 Argon في OpenCode عبر موفّر Google الأصلي فيه. السؤال المفيد هو ما يحدث بعد الإجابة الأولى: هل يحتفظ العميل بالأجزاء الموقّعة، ويعيد نتائج الأدوات بصورة صحيحة، ويتعرّف على استجابة المتابعة؟ أظهر اختبارنا دون اتصال لإصدار OpenCode v1.19.0 معالجة صحيحة للنص ورسائل الأدوات، مع وجود قصور في متابعة الإخراج الطويل والتعامل مع انقطاع البث.

يقدّم هذا الدليل إعداداً أولياً ويحدّد بدقة ما تثبته نتائج الاختبار. وهو لا يثبت وجود تكامل كامل لوكيل برمجي مع SeedRouter تم اختباره عبر استدعاءات فعلية. إذا أردت عميلاً أبسط يرسل طلباً واحداً بقرار منك في كل دور، فاستخدم دليل المحادثة باستخدام Python.

إعداد Gemini 4 Argon في OpenCode

تحقق من الإصدار المثبّت باستخدام opencode --version. تنطبق النتائج أدناه على الإصدار المنشور v1.19.0، الذي اختُبر في 14 أكتوبر 2026. يحتاج الإصدار الأحدث إلى تحقق مستقل؛ فوجود ميزة في فرع تطوير لا يثبت أن الإصدار المثبّت يدعمها.^[1]

أنشئ مجلد مشروع فارغاً للاختبار الأول. نزّل ملف إعداد OpenCode فيه. قسم الاتصال فيه هو:

{
  "provider": {
    "google": {
      "npm": "@ai-sdk/google",
      "options": {
        "apiKey": "{env:SEEDROUTER_API_KEY}",
        "baseURL": "https://api.seedrouter.ai/v1beta"
      },
      "models": {
        "gemini-4-argon": {
          "name": "Gemini 4 Argon",
          "reasoning": true,
          "tool_call": true,
          "limit": { "context": 1048576, "output": 4096 },
          "options": {
            "thinkingConfig": { "thinkingLevel": "low", "includeThoughts": true }
          }
        }
      }
    }
  }
}

يدعم OpenCode استبدال متغيرات البيئة بقيمها في ملفات الإعداد.^[2] اضبط SEEDROUTER_API_KEY في صدفة الأوامر من دون إدراج المفتاح في عمليات commit للمشروع. يختار الملف القابل للتنزيل أيضاً google/gemini-4-argon، ويعطّل المشاركة والتحديثات التلقائية، ولا يسمح إلا بأداة read. راجع هذه الصلاحيات قبل استخدام مستودع موجود. يصف الخياران reasoning وtool_call سلوك العميل؛ ولا يثبتان أن جميع العمليات مدعومة في حساب أو خدمة بعينها.

قيمة الإخراج 4096 ميزانية أولية اختيرت عمداً لهذا الإعداد، وليست الحد الأقصى الرسمي لنموذج Argon. يستهلك التفكير هذه الميزانية أيضاً. راجع مرجع API لقواعد السياق والإخراج والمتابعة.

البدء بطلب قصير واحد

بعد مراجعة الإعداد والأسعار الحالية، شغّل:

OPENCODE_CONFIG="$PWD/gemini-4-argon-opencode.json" \
OPENCODE_DISABLE_MODELS_FETCH=1 \
OPENCODE_DISABLE_AUTOCOMPACT=1 \
opencode run --model google/gemini-4-argon \
  "Explain a mutex in one sentence. Do not use tools."

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

ينبغي أن ينتهي مسار الطلب بالتنسيق الأصلي بـgemini-4-argon:streamGenerateContent?alt=sse. في الإصدار المختبَر، أرسل موفّر Google بيانات المصادقة في x-goog-api-key. يختلف هذا عن أمثلة cURL التي تستخدم ترويسة Bearer في دليل API العام؛ فاختيار موفّر OpenAI عام لا ينتج الطلب نفسه بالتنسيق الأصلي.

ما الذي أثبتته الاختبارات دون اتصال

استخدم الاختبار نسخة CLI المنشورة وواجهة API محلية تحاكي الخدمة وبيانات مصادقة وهمية. أرسل 17 طلباً عبر واجهة loopback المحلية ضمن ثمانية سيناريوهات. لم يولّد أي نموذج الإجابات، وكانت قيم التوكنات المبلّغ عنها مصطنعة. تصف هذه الملاحظات العميل، لا جودة النموذج أو الفوترة الفعلية.

السيناريو	السلوك المرصود في v1.19.0
بث النص بالتنسيق الأصلي	جمع أحداث النص المنفصلة في الإجابة المتوقعة
الدور الثاني من المحادثة	احتفظ بتوقيعات التفكير والنص المستخدمة في الاختبار داخل أجزاء النموذج
استدعاء أداة القراءة وإرجاع نتيجتها	قرأ ملف اختبار مؤقتاً وأعاد محتواه في `functionResponse`
`MAX_TOKENS`	أبلغ عن التوقف بسبب حد الطول من دون إرسال طلب آخر في تلك الحالة الاختبارية
HTTP 400	أنهى التنفيذ بخطأ من دون إعادة المحاولة في تلك الحالة الاختبارية
HTTP 429	أعاد المحاولة مرة واحدة وتلقى استجابة ناجحة من خدمة المحاكاة

يؤكد الاختبار إرسال thinkingConfig. لكنه لا يثبت أن خدمة فعلية طبّقت هذا الإعداد. وبالمثل، فإن تمرير توقيع مصطنع عبر السجل لا يثبت قبول توقيع حقيقي في طلب لاحق.

لماذا يحتاج الإخراج الطويل إلى تحقق إضافي

تتطلب استجابة CONTINUATION من Argon الطلب الأصلي مع أحدث قيمة لحقل المستوى الأعلى continuationToken. لا ينبغي إلحاق الإخراج الجزئي بسجل المحادثة العادي عند استئناف ذلك التوليد.^[3]

في حالتنا الاختبارية، صنّف OpenCode v1.19.0 قيمة CONTINUATION على أنها غير معروفة. أغفل الطلب التالي التوكن وأضاف الإجابة الجزئية إلى السجل. وعندما انتهى البث بعد إخراج جزئي من دون حدث ختامي، أرسل العميل أيضاً طلبات عادية إضافية. أوقفت خدمة المحاكاة ذلك السيناريو بعد ستة استدعاءات؛ وهذا لا يثبت أن حد إعادة المحاولة لدى العميل هو ست مرات.

لذلك، ليس هذا الإعداد حلاً تم التحقق منه لميزة long decode في Argon. نجاح إجابة قصيرة لا يحل هذه الحالات. قبل الاعتماد عليه في جلسات برمجة طويلة، أعد الاختبارات ذات الصلة باستخدام إصدار العميل نفسه الذي تنوي تشغيله.

أسئلة حول إعداد OpenCode

هل يشمل ذلك اختبار الأدوات والفوترة عبر استدعاءات فعلية؟

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

هل يمكن استخدام إعداد متوافق مع OpenAI بدلاً من ذلك؟

هذا بروتوكول مختلف وله نطاق توافق مختلف. يفحص هذا الدليل محتوى Gemini بالتنسيق الأصلي وتوقيعاته. تستثني وثائق Google الخاصة بميزة long decode نقطة نهايتها المتوافقة مع OpenAI من دعم هذه الإمكانية.^[3]

هل يؤدي تعطيل ضغط السياق التلقائي إلى تعطيل إعادة المحاولة؟

لا. ضغط السياق وإعادة محاولة الطلبات سلوكان منفصلان. لا يضمن خيار البيئة في المثال حداً صارماً لعدد الطلبات أو التكلفة.

تحديد ما ينبغي التحقق منه لاحقاً

عند استخدام Gemini 4 Argon في OpenCode، ابدأ بتبادل نصي قصير، ثم تحقق من سلوك الأدوات والسجل الذي يحتاج إليه عملك تحديداً. تعامل مع المتابعة وانقطاع البث بوصفهما حالتي اختبار قبول منفصلتين. أبقِ صفحة النموذج ومرجع API الأصلي إلى جانب إعداد العميل لتسهيل مراجعة تفاصيل البروتوكول والأسعار الحالية.