gpt-researcher را روی یک endpoint سفارشی سازگار با OpenAI اجرا کنید.

پاسخ سریع: یک بلوک پنج-خطی در .env.

مسیر endpoint سفارشی مستندشده gpt-researcher متغیرهای محیطی است. OPENAI_BASE_URL را روی https://api.apisrouter.com/v1 تنظیم کنید، OPENAI_API_KEY را روی کلید gateway خود تنظیم کنید، و سه اسلات مدل را با پیشوند provider برابر openai: اختصاص دهید. پیشوند به gpt-researcher می‌گوید کدام client استفاده کند؛ رشته بعد از دونقطه به endpoint فوروارد می‌شود، پس هر id ای که gateway سرویس دهد معتبر است، شامل id های Claude و Gemini. این پیکربندی مستندشده در docs.gptr.dev برای endpoint های سفارشی سازگار با OpenAI است، و برای بسته pip، اپ وب، و flow های چند-agent یکسان کار می‌کند، چون همه آن‌ها همان config را resolve می‌کنند.

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 token ها را در سرتاسر سه اسلات خرج می‌کند.

gpt-researcher (assafelovic در GitHub، حدود ۲۸ هزار ستاره) یک query را به یک گزارش پژوهش‌شده و استنادشده تبدیل می‌کند: سؤالات پژوهش را برنامه‌ریزی می‌کند، جست‌وجوهای وب را از طریق یک retriever شاخه می‌کند، منابع را scrape و خلاصه می‌کند، و سپس یک گزارش long-form می‌نویسد. framework آن pipeline را در سرتاسر سه اسلات مدل قابل‌پیکربندی به‌جای یکی تقسیم می‌کند. FAST_LLM کار حجم-بالا و کم-ریسک را مدیریت می‌کند، عمدتاً خلاصه‌سازی صفحات scrape‌شده. SMART_LLM نوشتن سنگین را انجام می‌دهد، شامل گزارش نهایی. STRATEGIC_LLM برنامه‌ریزی را مدیریت می‌کند: تولید سؤالات پژوهش و تصمیم درباره رویکرد. از جعبه، این‌ها به مدل‌های OpenAI پیش‌فرض می‌شوند (به‌ترتیب gpt-4o-mini، gpt-4.1، و o4-mini در زمان نگارش)، که دقیقاً به همین دلیل override تکی OPENAI_BASE_URL این‌قدر مؤثر است: هر سه اسلات از client به‌شکل OpenAI استفاده می‌کنند، پس یک base URL کل pipeline را جابه‌جا می‌کند. چون هر اسلات رشته provider:model خودش را می‌گیرد، اسلات‌ها نیازی به اشتراک‌گذاری vendor ندارند. یک اجرا می‌تواند با یک مدل سریع Claude خلاصه کند، با یک مدل قوی‌تر Claude یا GPT بنویسد، و با یک مدل reasoning-tier برنامه‌ریزی کند، همه از طریق همان endpoint و کلید. روی یک کلید تک-vendor آن ترکیب سه حساب می‌خواست؛ پشت یک gateway سه خط در .env است.

راه‌اندازی کامل: .env به‌علاوه API پایتون.

یک فایل .env در دایرکتوری کاری خود بسازید (یا متغیرها را در شل export کنید) و gpt-researcher را مثل همیشه اجرا کنید؛ بسته pip و اپ وب هر دو همان محیط را می‌خوانند. API پایتون اصلاً نیازی به کد مختص-endpoint ندارد، که نکته همین است: مسیردهی پیکربندی است، و کد پژوهش یکسان می‌ماند چه endpoint مال OpenAI باشد چه یک gateway. دو تنظیم مجاور اهمیت دارند. retrieval وب از طریق یک retriever اجرا می‌شود، پیش‌فرض Tavily، با کلید خودش (TAVILY_API_KEY)؛ آن credential مستقل از endpoint LLM است و همچنان برای پژوهش وب زنده لازم است. و embedding ها به openai:text-embedding-3-small پیش‌فرض می‌شوند، که یعنی فراخوانی‌های embedding از همان پیکربندی client به‌شکل OpenAI پیروی می‌کنند؛ اگر endpoint پشت OPENAI_BASE_URL آن مدل embedding را سرویس ندهد، EMBEDDING را به یک provider که آن را سرویس می‌دهد پیکربندی کنید (مستندات از پیشوند custom: برای endpoint های embedding سازگار با 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

انتخاب مدل‌ها به ازای هر اسلات.

پیش‌فرض‌های upstream شکل درست را کدگذاری می‌کنند، مدل کوچک برای حجم، مدل قوی برای نوشتن، مدل استدلال برای برنامه‌ریزی، پس آن شکل را نگه دارید و اسلات‌ها را ارتقا دهید به‌جای صاف‌کردن آن‌ها به یک مدل. پشت یک endpoint، یک A/B بین دو نویسنده یک تغییر .env یک‌خطی به ازای هر اجرا است، و usage log هر-کلید به شما می‌گوید هر پیکربندی گزارش واقعاً چقدر هزینه داشته.

• FAST_LLM بیشترین بار را دارد: هر منبع scrape‌شده خلاصه می‌شود. یک id سریع (claude-haiku-4-5-20251001، deepseek-v4-flash) یک گزارش بسیار-منبع را از سلطه هزینه خلاصه‌سازی باز می‌دارد، و افت کیفیت اینجا محدود است چون خلاصه‌ها به نویسنده تغذیه می‌کنند نه خواننده.
• SMART_LLM گزارشی را می‌نویسد که کاربر واقعاً می‌خواند. خروجی بلند، ساختار پایدار، انضباط استناد: اینجا جایی است که claude-sonnet-4-6 یا gpt-5.5 هزینه را کسب می‌کند، و جایی که کاهش کیفیت بلافاصله نشان داده می‌شود.
• STRATEGIC_LLM اجرا را قبل از شروعش شکل می‌دهد. سؤالات پژوهش بد یک گزارش بد تولید می‌کنند مهم نیست نویسنده چقدر خوب باشد؛ یک مدل قوی-در-استدلال اینجا چند فراخوانی اما اهرم بالا است.
• id های long-context مثل gemini-3.1-pro-preview ارزش تست در اسلات SMART را برای اجراهای detailed_report دارند، جایی که نویسنده در سرتاسر یک context انباشته بزرگ از خلاصه‌ها کار می‌کند.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

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

حالت‌های شکست مختص gpt-researcher.

حذف پیشوند provider. فرمت اسلات provider:model است، و پیشوند client را انتخاب می‌کند. تنظیم SMART_LLM=claude-sonnet-4-6 بدون openai: یک id از Claude را از طریق base URL شما مسیردهی نمی‌کند؛ باعث می‌شود gpt-researcher تلاش کند رشته را به‌عنوان یک provider متفاوت تفسیر کند. هر مدل endpoint-سفارشی باید پیشوند openai: را نگه دارد، چون "openai" اینجا نام پروتکل است، نه vendor. embedding ها بی‌صدا override را دنبال می‌کنند. EMBEDDING پیش‌فرض یک مدل به‌شکل OpenAI است، پس وقتی OPENAI_BASE_URL به یک gateway اشاره کند، درخواست‌های embedding هم آنجا می‌روند. اگر gateway آن id embedding را سرویس ندهد، اجراهای پژوهش در طول پردازش منبع شکست می‌خورند نه در اولین فراخوانی چت، که مردم را به دیباگ اسلات اشتباه گمراه می‌کند. EMBEDDING را صریح تنظیم کنید و علامت ناپدید می‌شود. مقصر‌دانستن endpoint برای شکست‌های retriever. یک TAVILY_API_KEY غایب یا اتمام‌یافته مرحله جست‌وجو را می‌شکند، و خطاهای empty-source نتیجه‌شده سطحی شبیه شکست‌های LLM به‌نظر می‌رسند. retriever یک سرویس جدا با یک کلید جدا است؛ آن را جداگانه چک کنید. محیط کهنه بین اجراها. فایل .env از دایرکتوری کاری خوانده می‌شود. اجرای اپ وب از یک دایرکتوری و API پایتون از دایرکتوری دیگر یعنی دو config متفاوت، و «در اپ کار می‌کند اما در اسکریپت من نه» تقریباً همیشه همین است. تنظیمات محدودیت-token جدا از قابلیت مدل هستند. gpt-researcher محدودیت‌های token هر-اسلات خودش (FAST_TOKEN_LIMIT، SMART_TOKEN_LIMIT، و تنظیمات مرتبط) را با پیش‌فرض‌های محافظه‌کارانه حمل می‌کند. اشاره‌دادن SMART_LLM به یک مدل long-context خودش‌به‌خود آن محدودیت‌ها را بالا نمی‌برد؛ اگر تولیدات طولانی‌تر می‌خواهید آن‌ها را عمداً تنظیم کنید.

چه کسانی gpt-researcher را از طریق یک gateway مسیردهی می‌کنند.

• تیم‌هایی که گزارش‌های تکرارشونده تولید می‌کنند (اسکن‌های بازار، مرورهای ادبیات، خلاصه‌های رقابتی) جایی که دید هزینه هر-اجرا در سرتاسر سه اسلات مدل بیشتر از یک رابطه تک-vendor اهمیت دارد.
• پژوهشگرانی که مدل‌های نویسنده را مقایسه می‌کنند. ثابت‌نگه‌داشتن FAST و STRATEGIC در حالی که SMART را بین id های Claude، GPT، و DeepSeek عوض می‌کنید سه ویرایش .env است، نه سه حساب vendor.
• سازندگانی که gpt-researcher را در محصولات embed می‌کنند، جایی که یک کلید gateway به ازای هر محیط یک بسته secret های vendor را در pipeline deploy جایگزین می‌کند.
• کاربرانی که می‌خواهند Claude یا Gemini نوشتن گزارش را انجام دهد در حالی که پیکربندی stock به‌شکل OpenAI در gpt-researcher دست‌نخورده می‌ماند.
• توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین گزارش را عیب‌یابی کنید.

اول مدل‌های gateway را فهرست کنید؛ رشته بعد از openai: در هر اسلات باید دقیقاً با یک id سرویس‌داده‌شده مطابقت داشته باشد، شامل پسوندهای نسخه. شکست‌های اجرای اول تمیز مرتب می‌شوند. یک ۴۰۱ یعنی OPENAI_API_KEY از محیطی که فرآیند واقعاً می‌بیند غایب است؛ فایل‌های .env از دایرکتوری کاری لود می‌شوند، پس از جایی که فایل زندگی می‌کند اجرا کنید یا متغیرها را به‌صورت سراسری export کنید. یک خطای model-not-found اسلاتی با غلط‌تایپی را نام می‌برد. یک شکست در طول پردازش منبع به‌جای زمان برنامه‌ریزی به embedding ها یا retriever اشاره دارد، نه اسلات‌های چت: قبل از لمس config LLM، EMBEDDING و TAVILY_API_KEY را چک کنید. یک اجرای پژوهش کامل یک burst از ده‌ها درخواست در سرتاسر هر سه اسلات است، پس وقتی کامل شود، نمای هر-درخواست کنسول APIsRouter سریع‌ترین راه دیدن تفکیک FAST/SMART/STRATEGIC در token و هزینه واقعی است، و گرفتن اسلاتی که بیشتر از نقشش مصرف می‌کند.

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

پرسش‌های پرتکرار