gpt-researcher：把网页和本地资料变成带引用的长报告

它解决的是调研流程，不是问答

普通 LLM 只能回答你问的问题，而且训练数据有截止日期，容易在时事话题上胡编。gpt-researcher 把任务拆成多个子问题，每个子问题派一个执行 agent 去网上找资料，最后汇总成一篇带引用的报告。它的目标用户是那些需要写综述、做竞品分析、查行业动态的人，而不是只想聊两句的普通用户。README 里明确提到，手动研究一个客观结论可能要花几周，而 LLM 又受限于 token 长度和过时信息，这个项目就是为了填补这个空档。它不解决事实正确性问题，只是把来源摆出来让你自己判断。

planner 和 execution 的分工机制

架构核心是两类 agent。planner 根据你的查询生成一系列研究问题，这些问题合起来构成对任务的客观视角。execution agent 逐个去抓取信息，每个资源都做摘要并记录来源。最后 publisher 把所有摘要过滤、聚合，生成最终报告。README 里的步骤写得很清楚：先创建任务专属 agent，再生成问题，然后用爬虫 agent 收集信息，最后汇总。这个流程借鉴了 Plan-and-Solve 论文的思路，把复杂任务分解成可并行的小块。并行化是提速的关键，但代价是多个 agent 同时调用 API，成本会线性上升。

安装和启动：两条路，一条快一条慢

最快的方式是 pip 安装。运行 pip install gpt-researcher，然后在 Python 里导入 GPTResearcher 类，传入 query，调用 conduct_research() 和 write_report() 两个异步方法。示例代码里 query 是 "why is Nvidia stock going up?"，但任何问题都行。源码方式要克隆仓库，安装 Python 3.11 以上版本，设置 OPENAI_API_KEY 和 TAVILY_API_KEY 两个环境变量，然后 pip install -r requirements.txt，最后用 python -m uvicorn main:app --reload 启动服务，访问 localhost:8000。注意 TAVILY_API_KEY 是必填的，没有它默认的网页搜索就失效。如果你用本地模型或 OpenAI 兼容 API，可以设置 OPENAI_BASE_URL 来替换默认端点。

MCP 集成：把外部数据源拉进研究

除了网页搜索，gpt-researcher 支持 MCP（Model Context Protocol）客户端。你可以在环境变量里设置 RETRIEVER=tavily,mcp 来同时启用网页和 MCP 数据源。示例代码展示了如何接入 GitHub 仓库，通过 npx 启动 @modelcontextprotocol/server-github，并传入 GITHUB_TOKEN。这意味着你可以让代理去查数据库、读代码仓库、调自定义 API，而不只是搜网页。这是一个很实用的扩展，但配置复杂度也上来了。你需要自己维护 MCP 服务器的启动命令和环境变量，出错时调试起来比单纯调搜索 API 麻烦得多。

报告生成和图像：超过两千词，还能配图

报告长度能超过两千词，这是靠聚合多个来源的摘要实现的，单个 LLM 的 token 限制被绕开了。默认会聚合超过 20 个来源，目的是减少单一来源的偏见。另外，项目支持用 Google Gemini 的 Nano Banana 模型生成内联图像，自动嵌入报告里。在 .env 文件里设置 IMAGE_GENERATION_ENABLED 之类的变量（README 被截断，具体键名需要查文档）就能开启。这个功能是锦上添花，但依赖 Google 的 API，如果你不想用 Gemini，就得关掉它。报告可以导出成 PDF 和 Word，前端有轻量版和 NextJS 生产版两种，部署方式灵活。

局限：外部依赖和成本是硬伤

最明显的限制是它必须联网工作。没有 Tavily API key 就跑不起来，没有 OpenAI 或兼容的 LLM 接口也跑不起来。虽然支持 OPENAI_BASE_URL 指向本地模型，但本地模型的质量和速度会直接影响报告效果。另一个问题是确定性。README 提到它借鉴了 RAG 和 Plan-and-Solve 来减少幻觉，但并行 agent 的抓取顺序和摘要结果不可能完全可复现，同一 query 跑两次可能得到不同报告。如果你需要严格可复现的调研结果，这个工具不合适。还有成本问题，每个子问题都调用一次 LLM，加上搜索 API 的费用，跑一篇长报告可能花不少钱，README 没有给出任何成本估算。

替代方案：直接调 LLM 和传统搜索

最直接的替代是你自己写脚本，用 LangChain 或纯 Python 调 LLM，配合 Tavily 或 SerpAPI 做搜索，自己拼报告。这样做你能完全控制每一步，但开发时间多得多。另一个方向是用普通搜索引擎加手动整理，虽然慢，但你能保证每个来源都亲自看过。gpt-researcher 的价值在于把这两者的中间层自动化了。如果你不想用 Tavily，项目可能支持其他 retriever（README 提到了 RETRIEVER 环境变量，但具体选项被截断），你需要查文档确认。选它还是选自己搭，取决于你更在意开发速度还是可控性。

维护和许可证：Apache-2.0 下的活跃项目

项目采用 Apache-2.0 许可证，这对商用和修改都很友好，你不需要开源自己的改动，但要注意保留版权声明。从最近发布记录看，v3.6.1 在 2026 年 8 月发布，v3.6.0 在 7 月，v3.5.1 在 6 月，更新频率大约每月一次，说明维护活跃。升级成本方面，新版本可能改配置项或 API 签名，比如 v3.6.0 标记为 Major fixes，你升级前要读 changelog。文档站 docs.gptr.dev 有完整的 API 参考和配置指南，这是你排查问题的主要依据。项目还提供 Docker 镜像和 Colab 笔记本，方便快速试用，但生产环境部署还是得自己处理依赖和密钥管理。

编辑结论

gpt-researcher 适合需要快速生成带引用长报告的研究人员、分析师和开发者，尤其是那些愿意配置 Tavily 和 OpenAI API 密钥、能接受外部服务依赖的人。不适合追求零外部依赖、完全离线运行，或者只需要简单问答而不需要结构化报告的场景。在采用前，先确认你的 LLM 提供商支持 OpenAI 兼容接口，检查 Tavily 的免费额度是否够用，并阅读 docs.gptr.dev 上的 retriever 配置说明，因为默认的搜索源和爬虫行为会直接影响报告质量。如果你只需要单轮问答，直接调用 LLM 更省事；如果你需要可复现的批量研究，gpt-researcher 的并行 agent 架构值得一试，但你必须自己处理 API 成本和速率限制。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes