百炼上的「查资料」能力现在有三层：知识库检索（RAG）、联网搜索、深度研究。三层的输入输出看起来都像「给一个问题，回一段内容」，但解决的问题完全不同。
qwen-deep-research 属于第三层。它不查你的私有知识库，也不只是把搜索结果拼成摘要。它会先反问、再规划、再研究、最后成文，交付物是一份带章节结构的报告。
这篇文章的实测由 Agent 完成。我给它的初始指令只有一句「研究一下 2026 年 AI 语音助手在客服场景的落地情况」，它反过来问我两个问题：关注哪些行业、更关心效果还是成本。澄清之后它跑了 8 分 22 秒，回报 6909 字和 35 处引用编号。
三层能力的分工
| 能力 | 数据来源 | 输出 | 适合什么 |
|---|---|---|---|
| 知识库检索 RAG | 你上传的文档 | 相关片段或带引用的回答 | 查内部制度、产品手册、客服话术 |
| 联网搜索 | 公开网页 | 搜索结果或摘要 | 查最新价格、新闻、政策 |
| 深度研究 | 公开网页 + 多步推理 | 一份结构化报告 | 行业扫盲、竞品初稿、方案底稿 |
三层的差别不在「谁更聪明」，在「交付物的形态」。RAG 给你证据片段，搜索给你线索，深度研究给你一份可以往下改的稿子。
两阶段协议
深度研究的调用形态和普通 chat 模型不同，它要求两阶段：
- 第一步只发问题，模型返回澄清式反问
- 第二步带上原始问题、反问、澄清回答，模型才进入研究
这个设计的价值在实测里很明显。我给的第一句话是「研究一下 2026 年 AI 语音助手在客服场景的落地情况」，模型反问了两个问题：关注哪些行业、关心效果还是成本。澄清之后，报告才有了明确的边界，而不是写成一篇泛泛的综述。
实测数据
| 指标 | 数值 |
|---|---|
| 第一步首字 | 约 2.8 秒 |
| 第二步总耗时 | 502.1 秒（8 分 22 秒） |
| 报告长度 | 6909 字符 |
| 章节 | 4 个二级章节 |
| 引用编号 | 35 处 |
| 参考文献列表 | 无 |
| 输出 token | 8085 |
| 成本 | 约 1.32 元 |
报告质量：哪段能用，哪段不能
能用的部分：成本结构拆解。报告把 AI 语音客服分成基础外呼、标准售后、高端实时 Agent 三档，每档给出每分钟总成本、通信费、模型费、平台费的占比。这个结构可以直接拿去和供应商报价对照。
不能直接用的部分：市场规模、渗透率、单价这类第三方数字。它们只有引用编号，没有来源链接，文末也没有参考文献列表。编号只表示「模型认为这里有来源」，不构成可核验的引用。
这一点对所有 Deep Research 产品都适用。用之前先看一眼文末有没有参考文献，比看报告写得多漂亮更重要。
接口边界
第一，只支持 DashScope 原生协议。bl text chat 走 OpenAI 兼容模式，会返回 404。
第二，只部署在华北 2（北京），Key 要用北京区的。
第三，单次 8 分钟量级，不适合在线低延迟场景。要接进产品，得用异步任务的方式，让用户先拿到「正在研究」的状态，再回来看结果。
第四，输出里会混入 <think> 标签，需要清洗。
成本结构
输入 54 元/百万 token，输出 163 元/百万 token。实测一次 1.32 元，其中输出占 99.6%。
这个成本结构说明一件事：深度研究的钱主要花在「写」上，不在「读」上。所以控制成本的关键是控制输出长度，比如选 model_summary_report，或者在提示里限定章节数量。
放在产品里的三种形态
形态一：后台批处理。 晚上跑一批行业报告，第二天早上给团队看。对延迟不敏感，对成本敏感。
形态二：异步任务。 用户提交问题，产品返回「正在研究」，8 分钟后通知结果。适合咨询、投研类产品。
形态三：人工协作。 用深度研究出底稿，人再核数字、补来源、改判断。这是目前最稳的用法，也是实测后最推荐的用法。
不适合的形态：实时问答、需要逐条引用来源的正式报告、对事实准确性要求极高的场景。
和 RAG 怎么配合
一个常见的组合是：先用深度研究扫一遍公开信息，形成行业底稿；再把底稿拆成问题，用 RAG 去查内部资料；最后人工合并。
深度研究负责「广度」，RAG 负责「深度」和「私有事实」。两者不冲突，前提是别把深度研究输出的数字直接当内部事实用。把两者接进同一条流程，才是企业侧比较稳的用法。流程里人仍然是最后一关，负责核数字和签字。
