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

إجابة سريعة: كتلة .env من خمسة أسطر.

مسار نقطة النهاية المخصصة الموثَّق لـ gpt-researcher هو متغيّرات البيئة. اضبط OPENAI_BASE_URL على https://api.apisrouter.com/v1، اضبط OPENAI_API_KEY على مفتاح بوابتك، وعيِّن فتحات النموذج الثلاث ببادئة مزوّد openai:. البادئة تخبر gpt-researcher أي عميل يستخدم؛ السلسلة بعد النقطتين تُمرَّر إلى نقطة النهاية، لذا أي معرّف تخدمه البوابة صالح، بما في ذلك معرّفات Claude وGemini. هذا هو الإعداد الموثَّق في docs.gptr.dev لنقاط النهاية المخصصة المتوافقة مع OpenAI، ويعمل بشكل متطابق لحزمة pip، وتطبيق الويب، وتدفقات العمل متعددة الوكلاء، لأن جميعها تُحلِّل نفس الإعداد.

OPENAI_BASE_URL=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-4-6
STRATEGIC_LLM=openai:gpt-5.5

كيف يُنفِق gpt-researcher tokens عبر ثلاث فتحات.

gpt-researcher (assafelovic على GitHub، بنحو 28 ألف نجمة) يُحوِّل استعلاماً إلى تقرير مُوثَّق بالمصادر: يُخطِّط لأسئلة بحث، يتفرّع في عمليات بحث ويب عبر مُسترجِع، يجمع ويُلخِّص المصادر، ثم يكتب تقريراً طويلاً. يُقسِّم الإطار ذلك الأنبوب عبر ثلاث فتحات نموذج قابلة للإعداد بدلاً من واحدة. FAST_LLM يتولى العمل عالي الحجم منخفض المخاطر، بشكل رئيسي تلخيص الصفحات المجموعة. SMART_LLM يقوم بالكتابة الثقيلة، بما في ذلك التقرير النهائي. STRATEGIC_LLM يتولى التخطيط: توليد أسئلة البحث وتقرير النهج. افتراضياً، هذه تفترض نماذج OpenAI (gpt-4o-mini وgpt-4.1 وo4-mini على التوالي وقت الكتابة)، وهذا بالضبط سبب فعالية تجاوز OPENAI_BASE_URL الواحد: الفتحات الثلاث كلها تستخدم العميل بشكل OpenAI، لذا base URL واحد يُحرِّك الأنبوب بأكمله. بما أن كل فتحة تأخذ سلسلة provider:model خاصة بها، لا تحتاج الفتحات لمشاركة بائع. يمكن لتشغيل واحد أن يُلخِّص بنموذج Claude سريع، يكتب بنموذج Claude أو GPT أقوى، ويُخطِّط بنموذج من فئة الاستدلال، كل ذلك عبر نفس نقطة النهاية والمفتاح. على مفتاح بائع واحد، هذا المزيج يتطلب ثلاثة حسابات؛ خلف بوابة هو ثلاثة أسطر في .env.

الإعداد الكامل: .env بالإضافة إلى Python API.

أنشئ ملف .env في مجلد عملك (أو صدّر المتغيّرات في shell) وشغّل gpt-researcher كالمعتاد؛ حزمة pip وتطبيق الويب كلاهما يقرأ نفس البيئة. واجهة Python API لا تحتاج كوداً خاصاً بنقطة النهاية على الإطلاق، وهذا هو المغزى: التوجيه هو إعداد، وكود البحث يبقى متطابقاً سواء كانت نقطة النهاية لـ OpenAI أو لبوابة. إعدادان مجاوران يهمان. الاسترجاع الشبكي يعمل عبر مُسترجِع، Tavily افتراضياً، بمفتاحه الخاص (TAVILY_API_KEY)؛ بيان الاعتماد ذلك مستقل عن نقطة نهاية LLM ولا يزال مطلوباً للبحث الشبكي الحي. والتضمينات افتراضياً openai:text-embedding-3-small، ما يعني أن استدعاءات التضمين تتبع نفس إعداد العميل بشكل OpenAI؛ إذا كانت نقطة النهاية خلف OPENAI_BASE_URL لا تخدم نموذج التضمين ذلك، اضبط EMBEDDING على مزوّد يفعل (التوثيق يستخدم بادئة custom: لنقاط نهاية تضمين متوافقة مع OpenAI، وخيارات محلية مثل Ollama مدعومة أيضاً).

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="State of small modular reactors in 2026",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # routing comes entirely from .env

اختيار نماذج لكل فتحة.

الافتراضات الأصلية تُشفِّر الشكل الصحيح، نموذج صغير للحجم، نموذج قوي للكتابة، نموذج استدلال للتخطيط، لذا أبقِ ذلك الشكل ورقِّ الفتحات بدلاً من تسطيحها إلى نموذج واحد. خلف نقطة نهاية واحدة، مقارنة A/B بين كاتبَين هي تغيير سطر واحد في .env لكل تشغيل، وسجل الاستخدام لكل مفتاح يخبرك بما كلّفه كل إعداد تقرير فعلياً.

• FAST_LLM يُطلَق الأكثر: كل مصدر مجموع يُلخَّص. معرّف سريع (claude-haiku-4-5-20251001، deepseek-v4-flash) يمنع تقريراً كثير المصادر من أن تُهيمن عليه تكلفة التلخيص، وفقدان الجودة هنا محدود لأن الملخصات تُغذِّي الكاتب لا القارئ.
• SMART_LLM يكتب التقرير الذي يقرأه المستخدم فعلياً. مُخرَج طويل، هيكل مستدام، انضباط استشهاد: هنا يكسب claude-sonnet-4-6 أو gpt-5.5 الإنفاق، وحيث يظهر خفض الجودة فوراً.
• STRATEGIC_LLM يُشكِّل التشغيل قبل بدايته. أسئلة بحث سيئة تُنتِج تقريراً سيئاً بغض النظر عن جودة الكاتب؛ نموذج قوي بالاستدلال هنا استدعاءات قليلة لكن رافعة عالية.
• معرّفات السياق الطويل مثل gemini-3.1-pro-preview تستحق الاختبار في فتحة SMART لتشغيلات detailed_report، حيث يعمل الكاتب عبر سياق كبير مُتراكِم من الملخصات.

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

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

أنماط الفشل الخاصة بـ gpt-researcher.

إسقاط بادئة المزوّد. صيغة الفتحة هي provider:model، والبادئة تختار العميل. ضبط SMART_LLM=claude-sonnet-4-6 بدون openai: لا يُوجِّه معرّف Claude عبر base URL الخاص بك؛ بل يجعل gpt-researcher يحاول تفسير السلسلة كمزوّد مختلف. كل نموذج نقطة نهاية مخصصة يجب أن يحتفظ ببادئة openai:، لأن "openai" هنا تُسمِّي البروتوكول، لا البائع. التضمينات تتبع التجاوز بصمت. EMBEDDING الافتراضي هو نموذج بشكل OpenAI، لذا بمجرد أن يُشير OPENAI_BASE_URL إلى بوابة، تذهب طلبات التضمين إليها أيضاً. إذا كانت البوابة لا تخدم معرّف التضمين ذلك، تفشل تشغيلات البحث أثناء معالجة المصادر بدلاً من أول استدعاء دردشة، ما يُضلِّل الناس لتصحيح الفتحة الخاطئة. اضبط EMBEDDING صراحة وتختفي العَرَض. لوم نقطة النهاية على فشل المُسترجِع. TAVILY_API_KEY مفقود أو مُستنفَد يكسر مرحلة البحث، والأخطاء الناتجة عن مصادر فارغة تبدو سطحياً كفشل LLM. المُسترجِع خدمة منفصلة بمفتاح منفصل؛ تحقّق منه بشكل منفصل. بيئة قديمة بين التشغيلات. يُقرَأ ملف .env من مجلد العمل. تشغيل تطبيق الويب من مجلد وواجهة Python من مجلد آخر يعني إعدادين مختلفين، و"يعمل في التطبيق لكن ليس في نصي البرمجي" غالباً هذا بالضبط. إعدادات حد tokens منفصلة عن قدرة النموذج. يحمل gpt-researcher حدود tokens خاصة به لكل فتحة (FAST_TOKEN_LIMIT، SMART_TOKEN_LIMIT، وإعدادات ذات صلة) بافتراضات محافظة. توجيه SMART_LLM إلى نموذج بسياق طويل لا يرفع تلك الحدود بذاته؛ اضبطها عمداً إذا أردت مُخرَجات أطول.

من يوجّه gpt-researcher عبر بوابة.

• الفرق التي تُولِّد تقارير متكررة (مسوحات سوق، مراجعات أدبيات، ملخصات تنافسية) حيث رؤية التكلفة لكل تشغيل عبر فتحات النموذج الثلاث تهم أكثر من علاقة بائع واحد.
• الباحثون الذين يقارنون نماذج الكتابة. تثبيت FAST وSTRATEGIC مع تبديل SMART بين معرّفات Claude وGPT وDeepSeek هو ثلاثة تعديلات .env، لا ثلاثة حسابات بائع.
• البناؤون الذين يُضمِّنون gpt-researcher في منتجات، حيث مفتاح بوابة واحد لكل بيئة يستبدل حزمة من أسرار البائعين في خط أنابيب النشر.
• المستخدمون الذين يريدون Claude أو Gemini يكتبان التقرير مع إبقاء إعداد gpt-researcher الافتراضي بشكل OpenAI دون مساس.
• المطورون الذين لا يملكون وصولاً إلى فوترة بائع معيّن. الوصول القائم على تعبئة الرصيد بدون شرط بطاقة يزيل الاعتماد على التسجيل لكل مزوّد.

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

اسرد نماذج البوابة أولاً؛ السلسلة بعد openai: في كل فتحة يجب أن تطابق معرّفاً مخدوماً تماماً، بما في ذلك لواحق الإصدار. أخطاء أول تشغيل تُصنَّف بوضوح. 401 يعني أن OPENAI_API_KEY غائب عن البيئة التي تراها العملية فعلياً؛ ملفات .env تُحمَّل من مجلد العمل، لذا شغّل من حيث يعيش الملف أو صدّر المتغيّرات عالمياً. خطأ model-not-found يُسمّي الفتحة ذات الخطأ الإملائي. فشل أثناء معالجة المصادر بدلاً من وقت التخطيط يشير إلى التضمينات أو المُسترجِع، لا فتحات الدردشة: تحقّق من EMBEDDING وTAVILY_API_KEY قبل لمس إعداد LLM. تشغيل بحث كامل هو اندفاع من عشرات الطلبات عبر الفتحات الثلاث، لذا بمجرد اكتماله، عرض كل طلب في لوحة APIsRouter هو أسرع طريقة لرؤية تقسيم FAST/SMART/STRATEGIC في tokens وإنفاق حقيقيَّين، والتقاط فتحة تستهلك أكثر مما يستحقه دورها.

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

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