GPT Researcher API 配置

先说结论:五行 .env 搞定

gpt-researcher 文档记录在案的自定义端点路径就是环境变量。OPENAI_BASE_URL 填 https://api.kkaiapi.com/v1,OPENAI_API_KEY 填你的网关密钥,三个模型槽位各自带 openai: 供应商前缀赋值。这个前缀告诉 gpt-researcher 用哪个客户端,冒号后面的字符串原样传给端点,所以端点提供的任何 ID 都有效,Claude 和 Gemini 的 ID 也不例外。 这是 docs.gptr.dev 上记录的自定义 OpenAI 兼容端点配置,对 pip 包、网页应用、多智能体流程都一样生效,因为它们解析的是同一份配置。

OPENAI_BASE_URL=https://api.kkaiapi.com/v1
OPENAI_API_KEY=sk-你的kkaiapi密钥
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-5
STRATEGIC_LLM=openai:gpt-5.5

gpt-researcher 怎么把 token 花在三个槽位上

gpt-researcher(GitHub 上的 assafelovic,约 2.8 万星标)把一个问题变成一份带引用的研究报告:规划研究问题,通过检索器展开网络搜索,抓取并总结来源,再写一份长文报告。框架把这条流水线拆到三个可配置的模型槽位,而不是一个模型。 FAST_LLM 负责高频量大、风险低的工作,主要是总结抓取到的网页。SMART_LLM 负责重活,包括最终报告的写作。STRATEGIC_LLM 负责规划:生成研究问题、决定研究路线。开箱默认这三个槽位都是 OpenAI 模型,这也是为什么单单一个 OPENAI_BASE_URL 覆盖就这么有效:三个槽位都用 OpenAI 形状的客户端,一个 base URL 就能挪动整条流水线。 因为每个槽位都带自己的 provider:model 字符串,槽位之间不需要共用厂商。一次跑可以用快速的 Claude 模型做总结,用更强的 Claude 或 GPT 模型写报告,用推理档模型做规划,全部经同一个端点和 Key。用单一厂商 Key 做这种混搭需要三个账号;经网关只是 .env 里三行配置。

完整配置:.env 加 Python API

在工作目录创建 .env 文件(或者在 shell 里导出这些变量),照常跑 gpt-researcher;pip 包和网页应用读的是同一份环境。Python API 完全不需要端点相关的代码,这正是重点:路由是配置,不管端点是 OpenAI 的还是网关的,研究代码保持不变。 两个相邻的设置值得注意。网络检索走一个独立的检索器,默认是 Tavily,有自己的 Key(TAVILY_API_KEY);这个凭证和 LLM 端点无关,要跑真实的网络研究仍然需要它。Embedding 默认是 openai:text-embedding-3-small,意味着 Embedding 调用跟着同一套 OpenAI 形状的客户端配置走;kkaiapi 目前不提供 Embedding 模型,所以 OPENAI_BASE_URL 指向网关之后,把 EMBEDDING 显式设置到一个真正提供该模型的供应商(比如继续用 OpenAI 官方的 Embedding,或者本地方案),不要假设网关会顺带接住这部分。

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="2026 年小型模块化反应堆的发展现状",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # 路由完全来自 .env

给每个槽位选模型

上游默认值编码了正确的形状:量大的活用小模型,写作用强模型,规划用推理模型,所以保持这个形状去升级各个槽位,而不是把它们拍扁成一个模型。经一个端点,两个写作模型之间的 A/B 只是每次跑改一行 .env,按 Key 的用量日志告诉你每种报告配置实际花了多少钱。

• FAST_LLM 触发最频繁:每个抓取到的来源都要总结一遍。一个快速 ID(claude-haiku-4-5-20251001、deepseek-v4-flash)能防止一份来源很多的报告被总结成本主导,这里的质量损失是有界的,因为摘要是喂给写作模型看的,不是直接给读者看的
• SMART_LLM 写用户真正会读的报告。长输出、持续的结构、引用纪律,claude-sonnet-5 或 gpt-5.5 该在这里花钱,砍质量的后果会立刻显现
• STRATEGIC_LLM 在跑之前就定了方向。研究问题定得不好,写作模型再强也救不回一份报告,一个推理能力强的模型放在这里调用次数不多,但杠杆很高
• 把完整文件或大段新闻窗口喂进去这类长上下文负载,值得在 SMART 槽位测试 gemini-3.1-pro-preview,尤其是 detailed_report 这种跑法,写作模型要在大段累积的摘要上下文里工作

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

gpt-researcher 专属的翻车点

丢掉供应商前缀。槽位格式是 provider:model,前缀决定用哪个客户端。把 SMART_LLM 设成 claude-sonnet-5 而不带 openai: 前缀,不会经你的 base URL 路由一个 Claude ID,而是让 gpt-researcher 试图把这个字符串解析成别的供应商。每个走自定义端点的模型都要保留 openai: 前缀,因为这里的 "openai" 指的是协议,不是厂商。 Embedding 悄悄跟着覆盖走。默认 EMBEDDING 是 OpenAI 形状的模型,所以 OPENAI_BASE_URL 一旦指向网关,Embedding 请求也会打过去,但 kkaiapi 不提供 Embedding 模型,如果不显式设置 EMBEDDING 指向真正支持它的供应商,研究会在处理来源阶段失败,而不是在第一次聊天调用时失败,容易误导人去排查错误的槽位。显式设置 EMBEDDING,这个症状就会消失。 把检索器的失败怪到端点头上。TAVILY_API_KEY 缺失或用尽会打断搜索阶段,产生的空来源错误表面上很像 LLM 故障。检索器是独立服务、独立 Key,分开排查。 跑之间残留的环境。.env 文件从工作目录读取。从一个目录跑网页应用、从另一个目录跑 Python API,意味着两份不同的配置,"网页应用里能跑、脚本里不行" 几乎都是这个原因。 token 限额设置和模型能力是分开的。gpt-researcher 自带每个槽位的 token 限额(FAST_TOKEN_LIMIT、SMART_TOKEN_LIMIT 等),默认值偏保守。把 SMART_LLM 指向一个长上下文模型本身不会自动抬高这些限额,想要更长的生成结果需要有意调整它们。

验证接入与排查首次报告

先列出网关的模型;每个槽位里 openai: 后面的字符串必须和提供的某个 ID 精确匹配,版本后缀也算。 首次跑的失败很规律。401 意味着运行进程实际看到的环境里没有 OPENAI_API_KEY;.env 文件从工作目录加载,所以从文件所在的位置跑,或者全局导出这些变量。模型不存在的报错点名是哪个槽位打错了字。在处理来源阶段而不是规划阶段失败,指向 Embedding 或检索器,不是聊天槽位:动 LLM 配置之前先查 EMBEDDING 和 TAVILY_API_KEY。 一次完整的研究跑是三个槽位上一连串几十次请求,跑完之后 kkaiapi 控制台的按请求视图是最快看清 FAST/SMART/STRATEGIC 三档实际 token 和花费拆分的方式,也能揪出某个槽位花得比它该有的份额多。

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

常见问题