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

weigangwin

0人浏览 · 2026-07-04 10:40:31

weigangwin · 2026-07-04 10:40:31 发布

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”的理由，而是告诉我们：它更像基础设施，不像浏览器里随手打开的聊天页。