شغّل Goose على نقطة نهاية مخصصة متوافقة مع OpenAI.

إجابة سريعة: أبقِ مزوّد openai، وتجاوز المضيف.

يأتي Goose بمسار نقطة نهاية مخصصة موثّق: أبقِ GOOSE_PROVIDER مضبوطاً على openai وتجاوز إلى أين يشير ذلك المزوّد. OPENAI_HOST يستبدل مضيف api.openai.com الافتراضي، وOPENAI_API_KEY يُصادق، وGOOSE_MODEL يختار النموذج بمعرّف دقيق. مسار الطلب منفصل: OPENAI_BASE_PATH يفترض افتراضياً v1/chat/completions ولا يحتاج عادة أي تغيير. لاحظ الشكل بعناية، لأنه عكس معظم الأدوات في هذه الفئة: OPENAI_HOST يأخذ المضيف العاري، https://api.apisrouter.com، بدون لاحقة /v1. جزء /v1/chat/completions يعيش في OPENAI_BASE_PATH. إلحاق /v1 بالمضيف يكرر المسار وينتج أخطاء 404 تبدو وكأن البوابة معطّلة.

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

كيف يتحدث Goose مع مزوّده.

Goose (block على GitHub، بنحو 51 ألف نجمة) هو وكيل هندسي مستقل من Block يخطط للمهام، ويعدّل الملفات، ويشغّل أوامر shell، ويقود إضافات قائمة على MCP. كل ذلك يقوم على محادثة نموذج واحدة: كل خطوة في الحلقة هي طلب /v1/chat/completions مع تعريفات أدوات مرفقة، لذا إعداد المزوّد يحدد أين يعمل الوكيل بأكمله. الإعداد متعدد الطبقات. المسار التفاعلي هو goose configure، الذي بالنسبة لمزوّد openai يطلب مفتاح API ومضيفاً مخصصاً اختيارياً، ثم يكتب إعدادات غير سرية مثل GOOSE_PROVIDER وGOOSE_MODEL إلى ~/.config/goose/config.yaml؛ يعرض تطبيق سطح المكتب نفس إعدادات المزوّد عبر واجهته. الأسرار تُعالَج بشكل منفصل: المفاتيح تذهب إلى سلسلة مفاتيح النظام أو تأتي من متغيرات بيئة، ومفتاح مُلصق مباشرة في config.yaml يُتجاهَل بدلاً من أن يُقرأ. متغيرات البيئة تتجاوز الملف، وهذا ما يجعل مسار البيئة أعلاه يعمل في كل مكان من shell على حاسوب محمول إلى مُشغِّل CI. بما أن Goose يُمرِّر GOOSE_MODEL كسلسلة نصية عادية، يمكن أن يكون المعرّف أي شيء تخدمه نقطة النهاية خلف OPENAI_HOST: معرّف Claude اليوم، ومعرّف Kimi أو Qwen غداً، بفارق متغيّر واحد.

المسار التصريحي: ملف مزوّد مخصص.

بالإضافة إلى تجاوز البيئة، تصف وثائق Goose الحالية أيضاً مزوّدين مخصصين تصريحيين: ملف JSON يُوضع في ~/.config/goose/custom_providers/ (دليل إعداد خاص بالمنصة على Windows) يسجّل مزوّداً مسمّى إلى جانب المزوّدين المدمجين. الملف يُعرِّف المحرك (engine) (openai لنقاط نهاية chat-completions)، ومتغيّر البيئة الذي يحمل المفتاح، وURL نقطة النهاية، والنماذج التي يقدّمها المزوّد. انتبه لاصطلاح URL هنا، لأنه ينقلب مرة أخرى: على عكس OPENAI_HOST، فإن base_url للمزوّد المخصص هو عنوان URL الكامل للطلب بما في ذلك المسار، https://api.apisrouter.com/v1/chat/completions. كل مدخل models يحمل context_limit حتى يعرف Goose النافذة التي يمكنه حشوها. الملف التصريحي هو الأنسب عندما تريد أن تظهر البوابة كمزوّد مسمّى خاص بها في قائمة مزوّدي Goose، بمتغيّر مفتاح خاص بها، بدلاً من احتلال فتحة openai. تجاوز البيئة هو الأنسب لـ CI والتبديل السريع. كلاهما ينتهي عند نفس نقطة النهاية؛ اختر واحداً وتجنّب تكديسهما.

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

اختيار نموذج لوكيل مستقل.

سير العمل العملي هو إبقاء مجموعة مهامك ثابتة وتدوير GOOSE_MODEL عبر مرشحين أو ثلاثة لبضع جلسات لكل واحد. بما أن كل مرشّح يتوجّه عبر نفس المفتاح، فإن عرض الاستخدام لكل مفتاح يسعّر كل تجربة دون أي محاسبة من جانبك.

• يعمل Goose في فترات دون إشراف: خطّط، عدِّل، شغِّل، اقرأ المخرجات، كرِّر. موثوقية استدعاء الأدوات تهم أكثر من الفصاحة الخام، وهذا سبب كون claude-sonnet-4-6 وclaude-opus-4-7 هما الافتراضيان اللذان يتقارب إليهما الناس للحلقة الرئيسية.
• معرّفات مضبوطة للبرمجة مثل kimi-k2.7-code تستحق الاختبار لجلسات ثقيلة بإعادة الهيكلة؛ عبر بوابة، ذلك الاختبار هو مجرد تغيير واحد في GOOSE_MODEL، لا هجرة مزوّد.
• الجلسات الطويلة تُراكم السياق. نموذج بنافذة 200 ألف حقيقية، مُعرَّفة بصدق عبر context_limit في المسار التصريحي، يتيح لـ Goose حمل سجل جلسة أكثر قبل التلخيص.
• للاستخدام في نصوص برمجية أو CI، معرّف من الفئة المتوسطة (gpt-5.4، qwen3.7-max) يتجاوز غالباً العتبة للمهام محددة النطاق جيداً بجزء من إنفاق النماذج الحديثة؛ قِس على مهامك الخاصة قبل الترقية افتراضياً.

ادفع حسب الاستخدام · أقل من السعر الرسمي

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

أنماط الفشل الخاصة بـ Goose.

/v1 ملحق بـ OPENAI_HOST. متغيّر المضيف يأخذ المضيف العاري؛ المسار يعيش في OPENAI_BASE_PATH، الذي يفترض افتراضياً بالفعل v1/chat/completions. https://api.apisrouter.com/v1 كمضيف ينتج طلبات /v1/v1/... وأخطاء 404. هذا هو الخطأ الأكثر شيوعاً على الإطلاق، تحديداً لأن كل أداة أخرى تريد لاحقة /v1. اصطلاح URL الكامل في ملفات المزوّد المخصص. base_url التصريحي هو عنوان URL الكامل للطلب بما فيه /v1/chat/completions، الاصطلاح المعاكس لـ OPENAI_HOST. نسخ مضيف عارٍ إلى ملف مزوّد مخصص يكسره تماماً كما يكسر نسخ URL كامل في OPENAI_HOST. المفاتيح في config.yaml لا تُصادق. يقرأ Goose الأسرار من keychain أو البيئة، ويتجاهل قيم المفاتيح الموضوعة في config.yaml. إذا استمر 401 بعد تعديل الملف، فهذا هو السبب؛ صدّر المتغيّر أو أعد تشغيل goose configure وأدخل المفتاح عند الطلب. جلسات سطح المكتب لا ترى تصديرات shell. لا يرث تطبيق سطح المكتب شيئاً من ملف تعريف طرفيتك. أعِدّ المزوّد عبر واجهة إعدادات سطح المكتب، أو أطلقه من shell تم فيه ضبط المتغيرات. مصادر إعداد مكدَّسة. تصدير OPENAI_HOST قديم يمكن أن يتجاوز ما ضبطته للتو في config.yaml، لأن البيئة تتغلّب على الملف. عندما يبدو التوجيه خاطئاً، اطبع المتغيرات ذات الصلة في نفس shell الذي يُطلق Goose قبل إلقاء اللوم على أي من الطبقتين.

من يوجّه Goose عبر بوابة.

• المهندسون الذين يشغّلون Goose كأداة يومية ويريدون Claude وGPT وKimi وQwen قابلة للوصول خلف مفتاح واحد بدلاً من مجموعة بيانات اعتماد لكل بائع.
• الفرق التي تضع Goose في CI أو مهام مجدولة. مسار البيئة فقط يعني أن المُشغِّل يحتاج بالضبط متغيرَي توجيه وسرّاً واحداً، سهل الحقن وسهل التدوير.
• المطورون الذين يقارنون نماذج الوكيل على مهام حقيقية. كل مرشّح هو مجرد قيمة GOOSE_MODEL واحدة مقابل نفس نقطة النهاية، مُسعَّرة تلقائياً عبر الاستخدام لكل مفتاح.
• فرق المنصات التي تريد إنفاق الوكيل مرئياً لكل مفتاح ولكل نموذج على سطح فوترة واحد، بدلاً من تسوية عدة لوحات بائعين.
• المطورون الذين لا يملكون وصولاً إلى فوترة بائع معيّن. الوصول القائم على تعبئة الرصيد بدون شرط بطاقة يزيل الاعتماد على التسجيل لكل مزوّد.

تحقق من نقطة النهاية وصحّح أخطاء الجلسة الأولى.

تأكد من أن البوابة تخدم المعرّف في GOOSE_MODEL قبل بدء جلسة؛ قائمة /v1/models هي التهجئة الرسمية، بما في ذلك لواحق الإصدار. أخطاء الجلسة الأولى متسقة. 404 يعني أن المضيف والمسار تركّبا بشكل خاطئ، غالباً /v1 في OPENAI_HOST. 401 يعني أن المفتاح ليس حيث ينظر Goose: غير مُصدَّر في shell الذي أطلقه، ولا في keychain، أو يجلس عديم الفائدة داخل config.yaml. خطأ نموذج غير موجود من البوابة هو خطأ إملائي في المعرّف في GOOSE_MODEL. إذا بدأت الجلسة لكن استدعاءات الأدوات تتصرف بغرابة، تحقق من أنك على نموذج يدعم فعلياً استخدام الأدوات؛ المعرّفات في الجدول أعلاه تفعل جميعها. بمجرد تشغيل الحلقة، تعرض لوحة APIsRouter النموذج لكل طلب، وعدد tokens، والإنفاق. الوكيل المستقل هو حِمل العمل الذي يهم فيه هذا أكثر: الجلسات طويلة، وأدوار استدعاء الأدوات كثيرة، وعرض الاستخدام هو كيف ترى ما كلّفته فعلياً أمسية من Goose.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

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