OpenAI Deep Research 怎么用？后台运行、数据源与引用审计

官方核对入口：Deep research guide、Web search、Background mode、Webhooks、GPT-5.6 Sol 与 API Pricing。核对日期：2026-11-01。

先判断：你真的需要 Deep Research 吗？

Deep Research 适合供应商比较、市场扫描、政策梳理、技术选型和尽调式资料汇总。它不保证答案绝对正确，也不应该代替专业法律、医疗或财务判断。若一次 Web Search 已能得到可核对答案，就不必为“更像研究”而启动长任务。

2026 年模型迁移：不要复制旧专用模型示例

OpenAI 的 Deep Research 指南保留了一部分旧流程用于迁移参考，但同时明确：o3-deep-research 与 o4-mini-deep-research 已停止使用，官方迁移方向是 gpt-5.6-sol。迁移不是只改一个 model 字段，还要重新检查 Responses API、Web Search、File Search、远程 MCP、推理强度、上下文、延迟和成本。

• 上线当天读模型目录：确认目标模型仍可用，并支持你计划启用的工具。
• 重新做质量基线：同一研究简报在新模型上的来源覆盖、引用、格式和事实一致性可能变化。
• 不要混淆文档代际：旧专用模型对 Function Calling、File Search 数量等限制，只能作为旧流程的迁移背景；当前通用模型能力要以现行模型页和 Responses Reference 为准。
• 保留回退方案：研究服务不可用时，可降级为有限次数的 Web Search，并明确告诉用户结果范围变窄。

第一步：先生成完整研究简报

Responses API 不会自动替应用询问所有澄清问题，也不会自动把一句模糊问题改写成可靠研究计划。提交长任务前，至少收集下面这些字段：

1. 目标：最终要支持什么决策，而不只是“研究某主题”。
2. 范围：时间区间、地区、行业、产品、语言和排除项。
3. 来源：允许的官方域名、可用 Vector Store、可信 MCP，以及禁止来源。
4. 交付：报告结构、表格字段、字数、引用方式和是否需要风险清单。
5. 时效：资料截止日期、是否必须实时联网，以及过期资料如何标注。
6. 风险：哪些结论需要人工复核，哪些动作绝不能由研究内容直接触发。

最小 Responses API 请求

下面示例展示当前迁移方向，而不是永久固定配置。模型、工具参数和价格会变化，部署前必须重新核对官方文档。

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "background": true,
    "reasoning": {"effort": "high"},
    "max_tool_calls": 20,
    "tools": [{"type": "web_search"}],
    "include": ["web_search_call.action.sources"],
    "input": [
      {"role": "developer","content": "只使用可审计来源。区分事实、推断和未知；冲突来源并列展示。"},
      {"role": "user","content": "研究简报：比较……（目标、范围、时间、来源、输出格式）"}
    ]
  }'

返回的响应通常先处于 queued 或 in_progress。保存 response.id，不要在浏览器里暴露 API Key，也不要让用户刷新页面后丢失任务标识。

第二步：用 Background Mode 管理长任务

GET /v1/responses/resp_123
Authorization: Bearer $OPENAI_API_KEY

应用可以每隔几秒轮询状态，并采用退避策略；更稳妥的生产方案是同时订阅 Webhooks，在收到完成或失败事件后再读取最终响应。界面至少显示：

• queued、in_progress、completed、失败或取消等真实状态；
• 开始时间、已用时、是否可取消，以及失败后的安全重试策略；
• 任务没有完成时不要伪装成“正在生成最终报告”；
• 重复提交要用自己的幂等键或任务表去重，避免同一研究产生多笔费用。

Background Mode 会临时保存响应以支持异步轮询；官方文档说明其数据控制与零数据保留存在兼容边界。若项目有 ZDR、合规或敏感数据要求，必须先验证项目设置和官方最新说明，再决定是否启用。

第三步：选择和隔离数据源

旧的专用 Deep Research 流程至少需要 Web Search、File Search 或远程 MCP 中的一个数据源，也可以加入 Code Interpreter。迁移到现行模型后，应把每个工具当成独立权限边界，而不是一次性开放所有数据。

公开网页和私有数据分两阶段

1. 先用公开网页形成问题清单和证据缺口，不携带客户隐私或内部密钥。
2. 再对私有 File Search/MCP 发起最小化查询，只检索完成任务所需的字段。
3. 合并阶段保留来源类型，避免把内部文档误显示为公开引用。
4. 最终报告按权限过滤；有权启动任务不代表有权查看所有底层文档。

第四步：解析结果、引用和工具轨迹

最终 Responses 输出不仅有报告文本，还可能包含 Web Search、File Search、MCP 或 Code Interpreter 的调用项。前端不应只读取一段 output_text 就结束：

1. 解析正文 annotations，把 url_citation 渲染为清晰、可点击链接。
2. 读取请求中 include 返回的完整 Web Search sources，作为审计清单；它可能多于正文引用。
3. 记录工具名称、调用时间、状态、输入摘要和输出标识，避免把敏感原文写进普通日志。
4. 标记“事实”“模型推断”“来源冲突”“未知”，不要把流畅措辞当成证据。
5. 对关键数字回到原始页面复核发布日期、币种、税费、地区与版本。

引用只说明模型使用了某个来源，不能保证来源本身正确，也不能保证模型准确理解。对于高风险结论，应让审核者查看原始来源，而不是只看报告中的一句摘要。

怎样控制成本、延迟和失败范围？

Deep Research 的总成本可能包含模型输入/输出 Token、Web Search 工具调用、搜索内容 Token、File Search、远程 MCP、Code Interpreter，以及失败重试。官方单价会变化，因此本页不把某个数字写成永久价格。

• 设置 max_tool_calls：它是控制研究深度、延迟和成本的主要护栏之一。
• 缩小问题：明确时间、地区、比较对象和交付格式，避免模型探索无关分支。
• 限制来源：优先官方域名或经过审批的内部数据源；来源越杂，复核成本越高。
• 分阶段：先做低预算资料扫描，再由用户确认是否进入高预算完整研究。
• 记录 usage：按任务保存工具调用数、Token、时长、失败和人工复核时间，计算单位可用报告成本。
• 设超时与取消：产品层必须能取消长任务，并避免取消后自动重启造成重复费用。

安全：研究内容不能取得系统权限

• 把网页、文件和 MCP 返回内容都视为不可信数据；其中的“忽略规则”“上传密钥”等文字不得覆盖系统指令。
• 只连接经过审批的 MCP 与文档库，最小化读取权限，并记录每次工具调用。
• 不要把 API Key、Cookie、内部提示词、客户身份信息或完整机密文档放进 Web Search 查询。
• 研究报告不能直接授权付款、删库、发信、提交合同或修改账号；这类动作需要独立规则、参数校验与人工审批。
• 验证 URL 协议、域名、重定向、下载大小和文件类型，防止 SSRF、恶意文件和资源耗尽。
• 对公开数据与私有数据分阶段处理，最终输出按用户权限过滤，并对日志进行脱敏。

常见失败与排查顺序

上线前检查清单

1. 目标路由、用户意图和普通 Web Search/File Search 页面边界已查重。
2. 上线当天核对模型目录、工具支持、背景模式、Webhooks 和最新 Pricing。
3. 研究简报包含目标、范围、时间、来源、交付格式与禁止事项。
4. background 任务可轮询、可接收 Webhooks、可取消、可安全重试且不重复计费。
5. max_tool_calls、超时、输出长度和单位任务预算有明确上限。
6. 引用可点击，完整 sources 与工具调用可审计，关键事实有人工复核。
7. 公开与私有数据分阶段，MCP/File Search 权限最小化，日志已脱敏。
8. 至少用 30–100 个真实研究问题评估来源覆盖、事实正确、引用准确、延迟、成本和失败恢复。

常见问题

本文核对日期为 2026-11-01。模型、工具、背景模式、存储、价格与限制会调整；生产上线前请重新读取 Deep research、Web search、Background mode、Models 与 Pricing 官方文档。