GPT Researcher LLM 环境验证指南：用 create_chat_completion 快速检测你的模型配置-育师

GPT Researcher LLM 环境验证指南：用 create_chat_completion 快速检测你的模型配置

【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcher

导读

在运行 GPT Researcher 之前，确保 LLM 相关的环境变量配置正确是最关键的一步——无论是 OpenAI、Anthropic、Ollama 还是 Azure OpenAI，任何一处密钥缺失或模型名拼写错误都会让后续的检索、规划与报告生成流程全部失败。本文以仓库文档 testing-your-llm.md 提供的官方验证脚本为核心，结合 llm.py 与 config.py 的源码实现，带你理解create_chat_completion的调用机制、Config的配置加载优先级以及多种 Provider 的配置写法。读完本文，你将能独立完成任意受支持 LLM Provider 的连通性验证与故障排查。

一、验证脚本：三分钟确认 LLM 配置可用

官方文档给出的验证思路非常简洁：实例化Config读取配置，再通过create_chat_completion发一条最简单的消息，看能否收到正常回复。完整脚本如下（与 tests/test-your-llm.py 中的示例一致）：

from gpt_researcher.config.config import Config from gpt_researcher.utils.llm import create_chat_completion import asyncio from dotenv import load_dotenv load_dotenv() async def main(): cfg = Config() try: report = await create_chat_completion( model=cfg.smart_llm_model, messages = [{"role": "user", "content": "sup?"}], temperature=0.35, llm_provider=cfg.smart_llm_provider, stream=True, max_tokens=cfg.smart_token_limit, llm_kwargs=cfg.llm_kwargs ) except Exception as e: print(f"Error in calling LLM: {e}") # Run the async function asyncio.run(main())

脚本的运行前提是：在项目根目录存放.env文件（load_dotenv()负责加载），且.env中至少配置了SMART_LLM对应的 Provider 密钥。将脚本保存为test_llm.py后直接执行：

python test_llm.py

成功时控制台会流式打印模型的回复内容；失败时则输出Error in calling LLM: ...，这正是你排查配置问题的起点。

脚本中每个参数的作用

参数	取值来源	作用
`model`	`cfg.smart_llm_model`	使用的模型名，由`SMART_LLM`环境变量解析而来
`messages`	硬编码	发送给模型的对话消息，这里只有一条 user 消息
`temperature`	0.35	采样温度，0.35 偏向确定性与一致性输出
`llm_provider`	`cfg.smart_llm_provider`	Provider 名称，同样由`SMART_LLM`解析而来
`stream`	`True`	开启流式输出，便于实时观察
`max_tokens`	`cfg.smart_token_limit`	输出 token 上限
`llm_kwargs`	`cfg.llm_kwargs`	透传给 LLM Provider 的附加参数（如 Ollama 的`num_ctx`）

二、Config 如何解析你的 LLM 配置

脚本中Config()是一切配置的入口。从 config.py 的源码可以看到，Config的初始化会依次完成配置加载、属性设置与 LLM 相关属性解析。

2.1 三层配置优先级

load_config的加载顺序（config.py）决定了「环境变量 > 外部 JSON 配置文件 > 默认值」的优先级：

通过CONFIG_PATH环境变量或Config(config_path=...)构造参数指定外部 JSON 配置文件；
未指定时直接使用 default.py 中定义的DEFAULT_CONFIG；
加载配置后，_set_attributes（config.py）会遍历每个配置键，若同名环境变量存在则优先使用环境变量值，并按 base.py 中声明的类型注解自动做类型转换（如bool、int、list、dict）。

因此你既可以在.env中写SMART_LLM=openai:gpt-5.4，也可以写一个 JSON 配置文件再通过python gpt_researcher/main.py --config_path my_config.json（或对应的 Python API 入口）加载，两种方式最终都会生效。

2.2 FAST_LLM / SMART_LLM / STRATEGIC_LLM 的格式

GPT Researcher 将模型划分为三档，分别对应不同的任务阶段（详见 llms.md）：

FAST_LLM：快速操作，如生成摘要；
SMART_LLM：智能操作，如生成研究报告与推理；
STRATEGIC_LLM：战略操作，如生成研究计划。

它们的取值格式统一为provider:model，例如openai:gpt-5.4-mini。_set_llm_attributes（config.py）会调用parse_llm（config.py）以冒号分割并校验 Provider 是否在支持列表内——如果写成gpt-5.4（缺少 Provider 前缀），会直接抛出提示信息："Set SMART_LLM or FAST_LLM = '<llm_provider>:<llm_model>'"，这是最常见的配置错误之一。

默认值定义在 default.py：FAST_LLM=openai:gpt-5.4-mini、SMART_LLM=openai:gpt-5.4、STRATEGIC_LLM=openai:gpt-5.4，对应的 token 上限分别为 6000 / 12000 / 8000。

三、create_chat_completion 的底层调用链

create_chat_completion定义在 llm.py，它是 GPT Researcher 中所有 LLM 调用的统一入口。理解它的内部逻辑，能帮助你更快定位验证失败的原因。

3.1 参数校验与 Provider 关键字组装

函数入口处做了两层防护（llm.py）：

model不能为None，否则抛出ValueError；
max_tokens超过 200,000 时抛出ValueError，提示检查FAST_TOKEN_LIMIT/SMART_TOKEN_LIMIT/STRATEGIC_TOKEN_LIMIT环境变量是否有拼写错误——这是针对「现代长输出模型需要提高 token 上限」这一趋势的安全护栏（config.md 给出了按模型家族建议的SMART_TOKEN_LIMIT取值表）。

随后函数组装provider_kwargs：llm_kwargs参数优先，其次读取LLM_KWARGS环境变量（JSON 格式解析）；同时根据模型类型做两个特殊处理：

命中SUPPORT_REASONING_EFFORT_MODELS列表的模型（如gpt-5.4系列、o3-mini等），会注入reasoning_effort参数；
命中NO_SUPPORT_TEMPERATURE_MODELS列表的模型（如o1、gpt-5系列、claude-sonnet-4-5等），会把temperature置为None，因为这类模型由服务端强制执行默认温度（列表定义见 base.py）。

3.2 Provider 分发与自动重试

组装完成后，get_llm(llm_provider, **provider_kwargs)会走 base.py 的GenericLLMProvider.from_provider，按 Provider 名称实例化对应的 LangChain 聊天模型。值得注意的细节：

OpenAI 兼容类 Provider（如dashscope、deepseek、vllm_openai、openrouter等）都基于ChatOpenAI实现，只是 API 地址与密钥来源不同；
Ollama 支持通过OLLAMA_BASE_URL指定本地地址，缺省为http://localhost:11434；
若某个 Provider 所需的langchain-*包未安装，_check_pkg（base.py）会自动尝试pip install并重新导入。

真正发起请求时，create_chat_completion内置了最多 10 次的指数退避重试（llm.py）：每次失败后按min(2 ** (attempt - 1), 8)秒等待再重试，空响应同样会被视为失败并重试；全部尝试耗尽后才抛出RuntimeError。这意味着单次密钥错误不会立刻导致整个流程崩溃，但也意味着如果你看到重试日志，说明 Provider 侧确实存在问题。

3.3 流式与非流式两种返回路径

get_chat_response（base.py）根据stream参数分两条路径：

非流式：self.llm.ainvoke(messages)一次性获取完整输出；
流式：stream_response使用astream逐块累积，遇到换行符按段落输出。验证脚本中stream=True时，无 websocket 的情况下，输出会以绿色文字直接打印到控制台。

无论哪种路径，Provider 都会捕获usage_metadata与response_metadata，为成本统计与 token 用量追踪提供真实数据。

四、针对不同 Provider 的验证环境变量

验证脚本默认使用SMART_LLM解析出的 Provider，因此只要把.env换成目标 Provider 的配置即可完成对应验证。以下是官方文档 llms.md 中各类 Provider 的配置样例（受支持 Provider 全集可查看 base.py 中的_SUPPORTED_PROVIDERS）。

4.1 OpenAI（默认推荐）

OPENAI_API_KEY=[Your Key] FAST_LLM=openai:gpt-5.4-mini SMART_LLM=openai:gpt-5.4 STRATEGIC_LLM=openai:gpt-5.4 EMBEDDING=openai:text-embedding-3-small

4.2 Anthropic

Anthropic 不提供自有 embedding 模型，因此嵌入部分需沿用 OpenAI 或其他 Provider：

ANTHROPIC_API_KEY=[Your Key] FAST_LLM=anthropic:claude-2.1 SMART_LLM=anthropic:claude-3-opus-20240229 STRATEGIC_LLM=anthropic:claude-3-opus-20240229

4.3 Ollama（本地模型）

OLLAMA_BASE_URL=http://localhost:11434 FAST_LLM=ollama:llama3 SMART_LLM=ollama:llama3 STRATEGIC_LLM=ollama:llama3 EMBEDDING=ollama:nomic-embed-text

4.4 Azure OpenAI

注意 Azure 的 deployment 名称必须与模型名保持一致，且需部署text-embedding-3-large嵌入模型：

AZURE_OPENAI_API_KEY=[Your Key] AZURE_OPENAI_ENDPOINT=https://{your-endpoint}.openai.azure.com/ OPENAI_API_VERSION=2024-05-01-preview FAST_LLM=azure_openai:gpt-4o-mini SMART_LLM=azure_openai:gpt-4o STRATEGIC_LLM=azure_openai:o1-preview EMBEDDING=azure_openai:text-embedding-3-large

4.5 自定义 OpenAI 兼容服务

通过OPENAI_BASE_URL指向任意 OpenAI 兼容端点（如 llama.cpp Server、vLLM），即可把自托管模型接入验证流程：

OPENAI_BASE_URL=http://localhost:1234/v1 OPENAI_API_KEY=dummy_key FAST_LLM=openai:your_fast_llm SMART_LLM=openai:your_smart_llm STRATEGIC_LLM=openai:your_strategic_llm

4.6 其他常用 Provider

# DeepSeek DEEPSEEK_API_KEY=[Your Key] FAST_LLM=deepseek:deepseek-chat SMART_LLM=deepseek:deepseek-chat STRATEGIC_LLM=deepseek:deepseek-chat # Dashscope（阿里云百炼） DASHSCOPE_API_KEY=[Your Key] FAST_LLM=dashscope:qwen3-32b SMART_LLM=dashscope:qwen-turbo-2025-04-28 STRATEGIC_LLM=dashscope:qwen-plus-latest EMBEDDING=dashscope:text-embedding-v3 # OpenRouter OPENROUTER_API_KEY=[Your key] OPENAI_BASE_URL=https://openrouter.ai/api/v1 FAST_LLM=openrouter:google/gemini-2.0-flash-lite-001 SMART_LLM=openrouter:google/gemini-2.0-flash-001 STRATEGIC_LLM=openrouter:google/gemini-2.5-pro-exp-03-25

各 Provider 完整配置可继续查阅 llms.md；更多可调参数（TEMPERATURE、SUMMARY_TOKEN_LIMIT、LLM_KWARGS等）的说明见 config.md。

五、常见验证失败场景与排查思路

结合源码实现，验证脚本的报错通常可以归为以下几类：

Unsupported xxx或Set SMART_LLM or FAST_LLM = ...：SMART_LLM缺少provider:前缀，或 Provider 名不在_SUPPORTED_PROVIDERS中（见 config.py）。检查.env中的写法，例如应为anthropic:claude-3-opus-20240229而非claude-3-opus-20240229。
Invalid reasoning effort：REASONING_EFFORT取值仅限low/medium/high（config.py）。
max_tokens=... exceeds the largest output limit：token 上限配置异常（如超过 200,000 或环境变量拼写错误），检查SMART_TOKEN_LIMIT等相关变量（llm.py）。
持续重试后Failed to get response from xxx API：多为密钥无效、网络不可达或模型名不被服务端识别。此时先确认.env中 API Key 无误，再尝试把stream改为False以便观察完整异常栈。
缺少依赖包：若日志出现Installing langchain-xxx...，说明对应 Provider 的 LangChain 集成包缺失，_check_pkg会尝试自动安装；若自动安装失败，可手动执行pip install -U <package>。

测试用例 test_llm_max_tokens.py 还验证了这样一个行为：create_chat_completion允许传入 64,000 / 128,000 这样的高 token 上限（面向 Claude 4.x、GPT-5 等长输出模型），但对 1,000,000 这类荒谬值会直接拒绝且不会触发 Provider 调用。这提醒我们：现代长输出模型需要主动提高 token 上限，否则研究报告会被截断（config.md 给出了按模型家族的建议值表，如 GPT-5 家族建议SMART_TOKEN_LIMIT=32000）。

六、进阶：一次验证多档模型并带上成本统计

验证脚本只测了SMART_LLM。如果你希望同时确认FAST_LLM、SMART_LLM与STRATEGIC_LLM三档模型全部可用，可以基于create_chat_completion的cost_callback参数（llm.py）编写如下扩展脚本：

import asyncio from dotenv import load_dotenv from gpt_researcher.config.config import Config from gpt_researcher.utils.llm import create_chat_completion load_dotenv() def cost_callback(costs): print(f"Cost so far: {costs}") async def check_one(tag, provider, model, token_limit): print(f"--- Checking {tag}: {provider}/{model} ---") try: response = await create_chat_completion( model=model, messages=[{"role": "user", "content": "Reply with OK"}], temperature=0.2, llm_provider=provider, stream=False, max_tokens=token_limit, cost_callback=cost_callback, ) print(f"SUCCESS: {response[:80]}...") except Exception as e: print(f"FAILED: {e}") async def main(): cfg = Config() await check_one("FAST", cfg.fast_llm_provider, cfg.fast_llm_model, cfg.fast_token_limit) await check_one("SMART", cfg.smart_llm_provider, cfg.smart_llm_model, cfg.smart_token_limit) await check_one("STRATEGIC", cfg.strategic_llm_provider, cfg.strategic_llm_model, cfg.strategic_token_limit) asyncio.run(main())

该脚本能一次性暴露「某档模型密钥缺失 / 模型名错误」的问题，并借助cost_callback验证成本统计链路是否正常工作——这也是 GPT Researcher 在生产环境做多 Provider 切换前最实用的体检方式。

总结

testing-your-llm.md提供的验证脚本虽短，却完整覆盖了 GPT Researcher 的 LLM 调用核心链路：Config负责把环境变量解析为provider:model与 token 上限，create_chat_completion负责参数校验、Provider 实例化、流式输出与失败重试。掌握这篇文章中的参数语义与排查方法，你就能在更换任何 LLM Provider（从 OpenAI、Anthropic 到本地 Ollama、自托管 vLLM）时，用同一段脚本快速确认配置正确，为后续的检索与报告生成流程扫清障碍。

【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcher

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考