用 GPT Researcher 前，先验证“资料来源合同”

用 GPT Researcher 前，先验证“资料来源合同”

GPT Researcher 不应该被当成一个更会写的搜索框。更准确的用法是把它看成研究流水线：从一个 query 出发，拆子问题，调用 retriever 找候选来源，抓取网页或文档，整理上下文，再写出带引用的长报告。

这条流水线有价值，但前提是“资料来源合同”能被看见。信任报告之前，我至少要知道：用了哪个 retriever，哪些 URL 进入了 context，哪些关键句子真的有 citation 支撑，抓取失败时系统怎么处理，本地文件和 MCP 工具有没有进入这次运行。

Doramagic 的 GPT Researcher 说明书有用的地方，正是它没有把项目写成泛泛的 AI research 助手，而是把 Python library、FastAPI backend、WebSocket、frontend、本地文档、retriever、scraper、MCP、多智能体工作流和安全边界放在同一张图里。2026-07-04 我复核的公开信息是：上游仓库为 assafelovic/gpt-researcher，Python 项目，Apache-2.0 协议，未归档，GitHub 约 28,058 stars、3,788 forks、198 open issues，最近一次观测 push 为 2026-06-28。Doramagic 项目页最后验证时间为 2026-07-02，并把它放在 MCP/tool integration 语境下；但说明书能看出来，它真正的执行面比 MCP 更宽。

执行面越宽，第一次试用越应该窄。

它到底做了什么

上游 README 对核心流程的描述很清楚：

• 根据研究问题创建 task-specific agent；
• 生成一组更客观的子问题；
• 通过 crawler / retriever 收集资料；
• 对资源做摘要和 source tracking；
• 过滤、聚合摘要，生成最终报告；
• 输出 Markdown、PDF 或 DOCX。

这些入口会直接影响采用风险：

• 本地安装要求 Python 3.11+；
• 默认 quickstart 需要 OPENAI_API_KEY 和 TAVILY_API_KEY；
• FastAPI app 通过 python -m uvicorn main:app --reload 在 localhost 启动；
• Python 包暴露 GPTResearcher，典型调用是 conduct_research() 和 write_report()；
• 前端包括 FastAPI 静态版本和 NextJS 版本；
• 本地文档研究支持 PDF、text、CSV、Excel、Markdown、PowerPoint、Word；
• MCP 可通过 RETRIEVER=tavily,mcp 和 MCP configs 接入；
• 多智能体版本使用 LangGraph / AG2；
• 报告可能超过 2,000 字，并聚合 20+ 来源。

这些能力本身不是问题。问题在于把它们混成一个“开始研究”按钮。Web 检索、本地文件读取、WebSocket 入口、MCP 工具调用、报告导出，是不同的信任边界。

第一次运行我会怎么验

第一次运行只做 web-only，不碰本地文档，也不启用 MCP。目标不是产出一份漂亮报告，而是验证 citation contract。

问题要窄，最好选一个你已经有基本判断、能抓出明显错误的题目。不要第一天就让它写行业总览。先选一个答案应该能被少数高质量页面支撑的问题。

生成报告前后，记录这些东西：

• 原始 query；
• report type 和输出格式；
• retriever 设置；
• model provider 和密钥边界；
• local documents 是否关闭；
• MCP 是否关闭；
• 进入 context 的 source URLs；
• 最终 report 文件或 URL；
• 抓取失败、空 context、降级重试等提示。

报告写完后，不按“读起来顺不顺”打分。抽查证据。

从报告里挑 5 个影响结论的关键句，逐条打开 citation。引用页面必须真的支撑那句话；如果 citation 指向的页面没有这个结论，这次运行失败。如果关键判断没有 citation，这次运行失败。如果 context 很薄甚至为空，但系统仍然写出很自信的报告，这次运行也失败。

这一步看起来慢，但它把“AI 写了一篇报告”变成了“研究流水线保留了证据”。

本地文档为什么要后置

本地文档研究很有用，但不适合放在第一轮验证里。只要 DOC_PATH 或 local file ingestion 进入运行，问题就从“研究质量”变成了“数据边界”。

启用本地文档前，我会先建一个 disposable folder，里面放两个无敏感文件：一个相关，一个不相关。期望结果不是“它用了相关文件”这么简单，而是：

• source list 能看出用了哪个文件；
• 不相关文件没有被硬塞进结论；
• 报告里没有泄露本地私有路径；
• 失败时能看见是文档解析失败、检索失败，还是写作阶段补出来的幻觉。

只有这一步过了，才考虑真实 corpus；而且服务进程应当只拿到最小必要的文件权限。

MCP 为什么也要后置

MCP 让 GPT Researcher 更有想象力，因为它可以接 GitHub 仓库、数据库、自定义 API 或其他专用数据源。但 MCP 也会放大权限面。

我不会在 web-only baseline 通过前启用 RETRIEVER=tavily,mcp。启用 MCP 后，需要单独记录 tool ledger：

• 连接了哪个 MCP server；
• 允许调用哪些 tool；
• server 是本地还是远端；
• 实际传了哪些参数；
• tool 返回的哪些数据进入 research context；
• tool 失败时，最终报告如何表达失败。

如果这些细节看不见，MCP 增加的是触达范围，不是可审计性。

真正值得检查的风险面

Doramagic 说明书里有几类风险适合直接转成操作检查。

第一，empty context 也可能生成流畅报告。说明书引用了 issue 证据：相关 context 缺失时，write_report 仍可能继续生成看起来完整的内容。也就是说，“报告生成成功”只是弱信号，必须检查 context 和 citation。

第二，backend / WebSocket 必须有网络边界。说明书记录了关于 unauthenticated source_urls 和 SSRF 风险的社区报告。如果 GPT Researcher backend 暴露给不可信客户端，认证、URL 校验、egress 限制和部署隔离不是锦上添花，而是基本边界。

第三，本地 PDF 处理要格外小心。说明书引用了 .pdf 条目、scraper 行为和本地文件读取相关 issue。它不代表每个部署都不可用，但代表 document ingestion 不能裸奔：要 allowlist、最小文件权限，并验证任意本地路径不可读。

这些不是“别用 GPT Researcher”的理由，而是告诉我们：它更像基础设施，不像浏览器里随手打开的聊天页。

什么时候适合用

它适合想要可复用研究流程、愿意审核来源质量、并能把 retrieval 和 report generation 分开看的团队。尤其适合需要 citation、PDF/DOCX 导出、本地文档、MCP 数据源和多智能体研究流的场景。

它不适合只想要快速答案、没法抽查 citation、或者准备把 backend 直接暴露给别人用但不做认证和 URL 控制的场景。它也不适合把“20+ sources”当成质量保证。来源多可以降低盲区，也可能放大重复页面、过时帖子和抓取噪声。

我的最小采用路径

如果今天要试 GPT Researcher，我会这样做：

1. 只跑一个 web-only query；
2. 记录 retriever、provider、source URLs 和输出文件；
3. 抽查 5 个关键结论是否被 citation 支撑；
4. 遇到 empty context 或 unsupported claim 直接判失败；
5. 用无敏感文件做一次 local document 测试；
6. baseline 通过后再启用 MCP，并记录 tool-call ledger；
7. 任何暴露的 backend 都必须放在认证、URL validation 和 egress controls 后面。

这条路径通过后，GPT Researcher 就不只是写作助手，而是一个可以检查证据的研究系统候选。如果这条路径不过，报告再顺也只是包装更好的风险。

来源：

• Doramagic 中文说明书：https://doramagic.ai/zh/projects/gpt-researcher/manual/
• Doramagic 项目页：https://doramagic.ai/zh/projects/gpt-researcher/
• 上游仓库：https://github.com/assafelovic/gpt-researcher

说明：本文是 Doramagic 的独立项目笔记，不代表 GPT Researcher 官方声明。