简介清华团队出品的DeepSeekDeepResearch入门演示PDF面向科研人员、数据工程师及希望用大模型简化数据工作的读者。资料围绕“让科研像聊天一样简单”展开收录多智能体从数据采集、清洗、分析到可视化的完整链条支持社交媒体、数据库、接口数据采集可输出统计图、热力图、网络关系图、词云等并重点给出基于提示词的爬虫任务、Python脚本自动化、春运数据表格化等实测案例逐一对比DeepSeek R1、OpenAI o3mini、Claude 3.5 sonnet、Kimi k1.5在响应速度、结果完整度、调试难度上的差异还附有各模型优劣势与排错观察方便读者按需选型。资料也点出低延迟、轻量级、多模态与医疗法律等垂直领域优化等模型特征帮助理解不同应用场景的选型逻辑。整份资料为单个PDF文件大小约5.66MB不依赖环境即可快速阅读。目前已有374人学习适合零基础起步或想评估大模型科研辅助能力的读者参考。1. 凌晨一点你还要亲手去啃四十篇文献吗DeepSeek 和 DeepResearch 给出了一个新解法凌晨一点你手里攥着四十多篇论文屏幕上是导师发来的“明天中午交个目录”。过去这套从头读到尾的调研姿势最近开始被 DeepSeek 和 DeepResearch 的组合改写了。某高校团队发布的第四弹方案把 DeepSeek 的推理能力装进 DeepResearch 这个专门跑完整调研流程的智能体框架里你像聊天一样说一句“帮我梳理这个方向的争议点”它自己拆解问题、生成检索词、逐篇读再带着引用和数据把综述骨架递回来。它不负责替你写定稿它负责把“从问题到提纲”这段最耗时的人肉搜索变成自然对话。适用的人很明确要读文献的博士生、做技术预研的工程师、给课题找开题思路的导师。接下来我会把这个组合的工作流拆开再给出一套用 DeepSeek 接口自建最小闭环的可复现做法。2. DeepResearch 的“灵魂”不是检索是把检索变成一个可对话的三层工作流很多人第一次用 DeepSeek 加 DeepResearch最直观的感受是“它居然会自己搜”。但真正让它和普通聊天机器人拉开差距的是它内部把一次调研拆成了三个层次先规划再执行最后综合。这三层不是简单的先后关系而是每完成一步就把结果写回对话上下文让下一层基于已有证据继续推进。这也是“像聊天一样简单”背后真正的工程成本所在。2.1 规划层聊天时 DeepSeek 如何把模糊需求翻译成科研计划用户丢过来的一句话往往非常模糊。比如“帮我看看大模型做代码生成现在到什么程度了”这句话里既没有时间范围也没有强调是工程落地还是学术评测更没有说明要的是综述、对比还是方案建议。如果直接拿这句话去检索搜回来的内容大概率是科普稿和新闻稿而不是科研需要的文献材料。DeepResearch 的规划层做的事就是先把这句话变成一份可执行的研究计划。常见做法是让模型生成一组子问题例如“现有代码生成模型在哪些任务上评测”“Agent 场景下的评测基准有哪些”“当前公认的短板和争议点是什么”。每个子问题再对应一组检索词。这个过程看起来只是多问了几句但它决定了后面所有检索的质量上限。这个环节我会单独用推理模式比较强的模型来跑。原因在于拆解问题需要模型做多步推理把一个大问题逐步分解成证据可获取的小问题。如果让普通对话模型直接拆往往只会拆出“什么是代码生成”“代码生成的发展历史”这类泛泛而谈的目录七个子问题里有五个都搜不到具体证据。拆解质量差的另一个表现是检索词冗余几个词搜出来的结果高度重叠等于白白浪费了搜索预算。规划层的产出物一般是一份结构化的任务清单里面包含子问题、每个子问题的检索词、以及“什么样算回答完毕”的判断标准。这个清单会作为后续每一轮的参考框架所以 DeepResearch 在实现上不会让它只出现一次而是会在每轮对话结束时重新把已确认的信息压缩进上下文。你中途追问一句“重点看看多智能体协作”规划层也会把这个问题追加进任务清单而不是让它在对话里漂着。2.2 执行层多轮检索和阅读的循环到底循环了什么执行层是 DeepResearch 最耗时、也最容易出问题的一层。它循环的核心动作有四个生成检索词、执行检索、筛选阅读、抽取要点。这四个动作会反复执行直到规划层定义的所有子问题都拿到了足够的证据。先看检索词生成。这个环节的工程细节远超大多数人想象。直接拿原始问句去搜是最省事但最无效的做法。一个好的执行层会为每一个子问题生成多组变体包括中英文不同表述、上位概念、下位概念、反方视角。比如研究“大模型代码生成的评测基准”至少会拆出“code generation benchmark”“代码生成评测”“Agent 代码生成评测”“HumanEval MBPP SWE-bench 对比”这几组。这样做的目的是覆盖不同来源的写作习惯避免只依赖某一类网站的词汇习惯。检索完成之后紧接着是筛选。实际检索结果里往往有大量重复的新闻稿、官方博客、以及互相转载的技术帖子。执行层要做两件事按域名和标题去重以及按来源类型做优先级排序。我一般会在一开始就把某些只转载不原创的站点拉进忽略名单不然一轮五个检索词搜下来模型会把同一篇文章读五遍还当成五个独立来源写进综述。阅读文章时工程上的做法是先读标题、摘要、发布时间和正文前两段再根据子问题决定要不要读全文。很多自建工作流图省事把整篇文章全文塞给模型结果 token 消耗翻了几倍回答质量却没提升。因为科研调研真正需要的是“和当前子问题直接相关”的片段而不是整篇文章。DeepResearch 在执行层会把一篇文章按段落切开单独评估每段相关度只把命中的片段送进后续综合阶段。这样既省钱也减少无关信息对最后报告的干扰。执行层最后一步是状态更新。每完成一次检索和阅读模型要把新拿到的信息归纳成结构化笔记并判断当前子问题是否已经“有足够的证据回答”。如果不够就再生成一轮新的检索词继续。这个判断是整个循环能不能停下来的关键。判断标准设得太松报告会缺内容设得太紧模型会在同一个子问题上反复检索既烧时间又烧预算。2.3 综合层把几十个片段改造成有可信度的报告最后一个综合层处理的是“如何把零散笔记变成一份能交出去的报告”。这一步不只是把几十个片段接在一起它要面对三个具体问题证据冲突、引用粒度、以及未解答问题的交代。证据冲突几乎是必然出现的。不同来源对同一个指标可能给出不同数据有的是因为统计口径不同有的是因为来源本身已经过时。综合层需要判断冲突的成因而不是简单地把两个说法都写进去。我自己的习惯是让模型优先采用来源日期更新、且实验条件描述更完整的那一条同时在报告里标注“该指标在不同评测中存在口径差异”。这个处理方式比强行选一边更像真人写综述。引用粒度决定了报告能不能被核验。靠谱的引用不会只写“据某论文显示”而是能精确到具体的 URL、标题、发布时间和关键数字。DeepResearch 的做法是给每个检索结果分配一个引用编号综合时引用编号而不直接引用文本最后再统一替换成可点击的来源列表。这样做的好处是模型在生成阶段看不到原始 URL也就没有机会编造看似合理的链接地址。综合层还要明确地把“没查到的内容”写出来。科研调研和写文案不同能明确说出来“这个问题目前没有找到公开权威资料”比硬凑一段话要可信得多。我通常会在提示模板里要求模型把未解答问题单独放在报告末尾而不是混进正文里试图掩饰。这一步看似简单但非常影响读者对整份报告的信任度。3. 用 DeepSeek 接口自建一个最小版 DeepResearch从提示模板到可跑代码前面聊的是 DeepResearch 的架构逻辑这一章直接落到可以抄的层面。你可以选择直接使用别人搭建好的 DeepResearch 产品也可以按下面这套思路用 DeepSeek 的接口自己搭一个最小闭环。自建的好处是每个环节都可控检索词怎么生成、引用怎么挂、什么时候停下来都由你自己说了算。3.1 选型盘一盘直接用产品还是自建工作流先给一个直观对比方便你决定走哪条路。考虑维度直接用现成的 DeepResearch 产品用 DeepSeek 接口自建工作流上手速度注册后马上能用几乎零门槛需要写代码、接搜索服务通常要半天到一天可控程度黑匣子内部提示和检索策略基本不可调每个环节都可以改甚至替换模型引用可信度取决于产品实现不同产品差异很大自己控制引用生成逻辑可以做到严格可核验成本通常是按次或按月订阅按 token 和搜索次数计费规模可控但需要自己监控适合人群只要结果、不想折腾技术细节需要定制调研流程、接入私有数据、或者做科研的人我个人的建议是如果你只是临时要一份调研资料直接用现成产品如果你准备把调研助手用进日常科研流程甚至想让它对接内部文档自建才是长期的解法。自建的前期成本主要在接入搜索服务上面。目前主流搜索服务商基本都提供标准的 REST 接口申请一个 API Key 就能用适配成本并不高。3.2 先用一个提示模板把“聊天”约束成“研究”自建工作流时系统提示词比任何参数都重要。下图是我整理的一份基础提示模板适合作为第一版跑通你是一个科研调研助手。你的目标是把用户的模糊问题转化成一次严谨的小规模文献调研。 工作方式 1. 先不要回答用户问题而是把问题拆成 3~6 个可检索的子问题。 2. 每个子问题给出 3~5 组检索词检索词要覆盖中英文、同义词、反方视角。 3. 检索回来后只保留与子问题直接相关的片段并为每个片段记录来源编号。 4. 综合时只能引用检索结果中真实出现的来源禁止根据记忆补充引用。 5. 如果某个子问题没有找到充分材料明确写“未找到公开权威资料”不要硬填。 6. 最终报告分为研究结论、证据细节、未解决问题三个部分。这份模板解决的核心问题是把“聊天”里的随意性压缩到最低。第一句话就把模型定位成调研助手而不是聊天伙伴第二条强制生成同义词变体避免检索词过窄第四条直接堵死了幻觉引用的来源。实际使用时我会根据任务性质调整最后一句话。如果调研目标是“方案选型”第三部分会改成“候选方案对比与适用条件”如果目标是“开题报告”第三部分则是“研究空白与可切入角度”。模板的作用在于约束行为边界具体内容跟着任务走。3.3 最小可跑的 Python 闭环三阶段代码骨架这一节给出一个能跑起来的完整骨架总共三个核心函数。你可以把它保存成一个 Python 文件设置好环境变量后直接运行。# research_mini.py —— 最小可用的 DeepSeek 调研助手骨架 import os import json import requests第一步封装 DeepSeek 的通用调用接口def call_llm(messages, toolsNone, modeldeepseek-chat, temperature0.2, max_tokens4096): # 环境变量里读取密钥不要把密钥直接写死在代码里 url https://api.deepseek.com/chat/completions headers {Authorization: fBearer {os.getenv(DEEPSEEK_API_KEY)}} payload { model: model, # deepseek-chat 响应快复杂推理可换 deepseek-reasoner messages: messages, temperature: temperature, # 调研任务建议 0.1~0.3越低越稳定 max_tokens: max_tokens, } if tools: payload[tools] tools # 需要工具调用时传入函数声明列表 resp requests.post(url, headersheaders, jsonpayload, timeout180) resp.raise_for_status() return resp.json()[choices][0][message]这个函数是后续一切调用的基础。参数上我单独说明两点temperature 在调研任务里一定要调低因为科研调研需要的是稳定、可复现的输出不是天马行空的发挥max_tokens 设置 4096 是为了给后续长报告预留空间如果设太小报告后半段很容易被截断。第二步封装一个统一的搜索函数。不同搜索服务商的接口差异很大我这里按最常见的形式做一个适配层def web_search(query, limit8): # 搜索服务商普遍提供 REST 接口这里统一转成三个核心字段 headers {Authorization: fBearer {os.getenv(SEARCH_API_KEY)}} resp requests.post( os.getenv(SEARCH_API_URL), headersheaders, json{q: query, num: limit}, timeout60, ) resp.raise_for_status() raw resp.json().get(docs, []) return [ {title: d.get(title, ), snippet: d.get(snippet, ), url: d.get(url, )} for d in raw ]这里有一个实际工程里的血泪经验搜索结果字段名几乎每个服务商都不一样。有的叫 title有的叫 name有的叫 headline。你拿到手第一件事不是写业务逻辑而是先写一个字段映射层把所有来源统一成 title、snippet、url 三个字段。后面所有环节都只跟这三个字段打交道换搜索服务商时只改这一处。第三步把三个阶段串成完整流程def research(question): # 阶段一让模型输出子问题和检索词 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question}, ] plan_msg call_llm(messages, temperature0.3) plan_text plan_msg.get(content, ) # 从计划里提取检索关键词这里按文本行做简单解析 queries [] for line in plan_text.splitlines(): if 检索词 in line: query line.split(检索词)[-1].strip() queries.append(query) # 阶段二逐个检索把结果抽成结构化笔记 notes [] for q in queries[:5]: # 硬限制最多执行 5 个查询防止预算失控 docs web_search(q) note_msg call_llm([ {role: system, content: 你是笔记整理器。只提取与调研直接相关的信息。 为每个来源标注序号、标题和 URL禁止补写内容。}, {role: user, content: json.dumps(docs, ensure_asciiFalse)}, ], temperature0.1) notes.append(note_msg.get(content, )) # 阶段三综合笔记生成报告 report_msg call_llm([ {role: system, content: 你是综述写作者。基于笔记内容写一份调研报告。 报告分三部分结论、证据细节、未解决问题。 每个关键论点后必须标注来源序号。}, {role: user, content: \n\n.join(notes)}, ], temperature0.3) return report_msg.get(content, ) if __name__ __main__: output research(调研大模型在代码生成方向的主流评测基准重点看 Agent 场景) print(output)这套代码的骨架逻辑并不复杂但它已经具备了一个 DeepResearch 最小闭环的四个关键点规划拆解、约束检索、阶段笔记、综合报告。你运行一次就能看到它和普通聊天的明显区别。需要说明的是这套骨架做了两个简化。第一是没做全文阅读只读了搜索结果里的摘要片段真实调研中摘要往往不够第二是引用序号没有严格和来源 URL 绑定后面版本需要把 notes 里的序号映射回原始 URL这块我会在下一章展开。3.4 跑通之后先按这三个硬指标验收代码跑通不等于能用。我每次搭建完类似的工作流都会按下面三个硬指标做验收缺一个都要返工。验收指标通过标准不通过时怎么调可复核引用报告中每个关键数字和论点都能通过标注找到具体来源链接检查阶段二是否丢了 URL 字段记住要改综合阶段的提示模板问题覆盖度原始问题拆出的子问题全部有回答没有只写了一半把报告和规划阶段的子问题清单对照缺项就加大检索轮次过程可追溯能从对话记录里看到每一步搜索了什么、读了什么给每个子问题编号并在阶段笔记里保留对应编号这套验收标准不是凭空拍的。实际深挖过各类调研助手的朋友都知道很多 Demo 看起来惊艳但引用链接点进去是 404或者结论建立在单一来源上。这种产出在正式科研场景里是没法用的。所以验收的核心就是看它能不能通过“人肉复核”这一关。4. 参数怎么设、边界在哪里把 DeepResearch 用得又稳又省代码跑通只是第一步。真正进入日常使用后你需要面对的是参数选择、上下文管理、成本控制这几个实际问题。这一章我按自己的使用习惯把最关键的几个点列出来。4.1 四个必调参数模型选择、温度、输出上限、循环次数参数不是越多越好真正影响调研质量的通常就四个。参数推荐设置影响范围常见翻车方式模型选择规划用 deepseek-reasoner摘要和检索用 deepseek-chat规划质量决定调研方向摘要速度决定整体耗时全部用推理模型费用翻倍全部用普通模型规划太浅temperature规划 0.3检索整理 0.1综合 0.3数值越高输出越多样但越不稳定设成 0.7 以上同一份材料每次生成的内容都不一样max_tokens单轮至少 4096长报告拆分输出决定了单次生成能写多长设 1024报告末尾被切掉还没报错最大检索轮数5~10 轮控制总耗时和总费用不设上限模型陷入死循环预算烧完模型选择是第一个值得反复调的地方。DeepSeek 的接口里deepseek-reasoner 适合做需要多步推理的任务比如把模糊问题拆成子问题、判断证据之间是否冲突deepseek-chat 则适合做高吞吐的整理任务比如把检索结果压成笔记。混用两个模型效果比单用任何一个都好成本也最合理。max_tokens 这个参数很容易被忽略。调研报告动辄几千字如果上限设低了模型会在中间截断而且不会提示你“被截断了”。我自己第一次跑的时候就踩过这个坑报告写到一半戛然而止后半段一个论点都没有。后来养成的习惯是不在单次调用里硬憋完整报告而是让模型按子问题分段输出最后再合并。最大检索轮数的意义在于兜底。检索阶段是有可能陷入循环的模型发现证据不足生成新检索词又发现新的不足再生成下一组。如果不设上限这个循环可以永远跑下去。我会在提示模板里明确写“最多执行 n 轮检索如果仍未找到足够证据直接记录为未解答问题”从行为层面对模型做硬约束。4.2 上下文管理为什么聊着聊着就跑偏了聊天式交互最大的陷阱就是对话越长模型越容易忘记最初的问题。你可能在调研中途问了一句“顺便看看这个指标的原始定义”等到报告生成时模型已经把这个顺便当成了主线前面花大量篇幅调研的子问题反而不写了。追根到底这是上下文管理没做好。通用的滑动窗口机制会不断丢弃旧内容而调研任务恰恰需要保留完整的问题框架。我的做法是每次进入下一阶段之前把当前结构写成一个固定的摘要块放回消息列表的合适位置。摘要块保留的内容包括原始问题、当前计划、已完成子问题、待办子问题、以及最近一次的需求变更。调研任务状态 原始问题大模型代码生成评测基准重点 Agent 场景 当前计划已拆出 5 个子问题第 3 个子问题正在检索 已完成评测基准汇总、Agent 任务类型分类 变更记录用户新增要求“补充多智能体协作场景” 下一步检索 multi-agent code generation benchmark这个摘要块的文字不需要多精美但它起了锚点作用。后面无论模型聊到哪里系统提示里始终有这个块它就能追回主线。我把这个块当作工具调用的系统状态来用而不是靠对话记忆。这一点的价值等你实际跑过超过十轮的长任务后会有非常直接的体会。4.3 成本与合规边界提前划好避免翻车成本控制是自建方案绕不开的话题。问题不是 API 单次调用有多贵而是检索循环会把它放大多少倍。一次完整调研可能要做十几次模型调用、几十次搜索。如果没设上限一次调研花掉几十块钱也不奇怪。我常用的成本控制手段有三层。第一层在提示层要求模型只输出与子问题相关的笔记不要整篇复述文章内容能省下大量 token第二层在代码层比如本篇文章里的工作流示例设置了最多执行 5 个查询搜索调用数量和最大轮数都有硬上限第三层在预算层给一轮调研预设一个 token 消耗阈值达到阈值就停止检索把当前结果汇总成阶段性报告。另一个容易被忽略的是数据合规。科研场景里经常涉及未发表论文、内部技术报告、甚至用户隐私数据。直接把全文丢给云端 API在大多数机构里都过不了合规审核。我一般的习惯是先做脱敏再调用只把标题、摘要、和经过脱敏的关键段落发给模型如果条件允许尽量部署私有化模型来处理敏感数据。这个边界宁可事前划得严一点也不能事后出了问题再去补救。5. 避坑手册聊天式科研跑稳后这 5 个坑最磨人5.1 检索词太窄整份报告像只有一个人在世界现象跑完一份调研报告内容高度同质化所有结论都来自同一类来源甚至同一个域名的不同页面。 原因模型直接把用户原话作为检索词没有做同义扩展和视角扩展。比如用户说“代码生成模型”它就只搜“代码生成模型”搜出来的全是同一篇文章被转载了无数次的版本。 解决在系统提示模板里加一条硬约束——每个子问题必须给出中英文、上位词、下位词、反方视角至少四组检索词。反方视角尤其重要比如研究“大模型的代码生成能力”一定要补一个“限制与失败案例”方向的检索词否则报告一边倒。5.2 引用格式完美点开链接却不存在现象报告里每个论点都挂了引用格式规范标题也有模有样但用手点进去要么 404要么跳转到完全不相关页面。 原因这是典型的幻觉引用。当模型没有拿到具体来源信息时它会根据文章风格推测一个像样的标题和链接。这个问题不是靠提示词“不要编造”就能解决的因为模型在生成阶段确实“以为”自己说的是真的。 解决让模型在综合阶段只使用来源编号而不是直接生成 URL。也就是把“引用 https://xxx”改成“引用 [来源 3]”最后统一由代码模块把编号映射回真实检索结果里的 URL。这样模型根本没有机会输出它想象的链接。5.3 中途补了一句需求报告写成两套论点现象你调研到一半想起一个细节顺手说“再加一个对比维度”。结果最终报告前半部分按旧计划写后半部分按新需求写两边论点互相打架。 原因对话历史太长模型把新需求当成了补充而不是一次计划变更。旧任务框架还残留在上下文里新需求又加了进来两套结构同时生效。 解决把需求变更显式化。我自己的做法是在消息里单独发一条“任务变更”文本内容包括变更原因、影响到的子问题、以及需要重新规划的范围。变更后先回到规划层重新确认子问题列表再进入检索阶段不直接在当前流程里插入需求。5.4 长报告后半段烂尾引用也跟着断掉现象报告生成到一半直接停止或者后面几段明显变短连结论都没有就被截断了。 原因max_tokens 设太小或者一次让模型输出太长的内容。调研报告通常要去到一个很完整的结构半途截断往往发生在模型还没到结论区就被 token 上限拦住。 解决从两个方向入手。一是按子问题分段生成每段控制在 800 到 1200 字以内最后让模型基于分段摘要生成总报告。二是在代码层增加截断检测如果返回结果的 finish_reason 是 length就自动缩减后续输出规模而不是直接当作成功返回。5.5 循环失控预算直接烧穿现象一次简单的调研请求最终产生了上百次工具调用账单出来一看超过预期。模型反复搜索同一个子问题生成检索词、搜索、发现证据不足、再生成新检索词陷入死循环。 原因没有给检索循环设置硬性退出条件。规划层定义的“足够证据”标准不够明确模型每次都觉得“还差一点”就继续搜下去了。 解决两条措施并行。一是在代码里设置最大检索轮数比如 5 轮到点强制进入综合阶段。二是在提示模板末尾加退出条件“如果你的笔记中存在相互矛盾但可并存的证据也能算作完成不必继续检索。”这句话能让模型明白证据可以多元不必追求找到一个统一答案。6. 别让报告停留在“满篇话”把调研结果变成下一步问题清单再进入下一轮跑通整套流程之后我想分享一个对我自己帮助很大的进阶习惯不强求一次调研得到终极答案而是让每次调研的产出成为下一轮调研的起点。具体操作上我会在每轮调研结束后使用 DeepSeek 接口把报告里“未解决问题”的部分扩展成三个有形问题并明确验证方式。比如报告结论里出现“评测指标 A 在不同实现下结果差异明显”我就会让模型生成差异的具体来源是什么有没有可用的复现实验步骤如果复现最小数据集和运行环境是什么这三个问题会存成一份清单配额完成后直接作为下一轮对话的输入。这样做的好处非常明显。每一份报告到最后都不只是文本文档而是一张不断生长的调研地图。你甚至可以把清单直接整理成可勾选的任务列表把其中能自动化回答的问题交给工具把需要人工判断的问题留给自己。有一个小技巧是在下一轮对话时把“上一轮问题的验证结果”放在消息最前面让 DeepSeek 基于验证结果修正调研方向而不是又回到最初那个模糊问题重来一遍。持续性使用这套工作流的另一层体验是你会慢慢发现它的性能边界在哪里。我可以接受它偶尔漏查一篇我需要的那篇论文也可以接受它刚开始没有给我想要的对比视角但不能接受它只能输出一段好读但不可核验的话。我把“引用可核验、回答可追溯、未解答问题老实说明”当成底线只要满足这三条其余缺陷都是可以修的。到现在我已经把顺手做的任务清单养成了一个固定习惯。每次开一个新的调研课题我先丢给这套工作流跑一轮拿到带着引用和问题清单的草稿再基于草稿手动深挖。这样既没有放弃人的判断力也把最耗时的“找素材、排结构”环节省了下来。如果你现在正在被文献综述或者技术选型调研烦恼不妨从最小闭环开始跑一次让它帮你把“从头读到尾”变成“聊着聊着就聊完了”。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 14:37:51 · 阅读 1.2k DeepSeek+DeepResearch：用对话式AI工作流搞定文献调研与综述写作
简介清华团队出品的DeepSeekDeepResearch入门演示PDF面向科研人员、数据工程师及希望用大模型简化数据工作的读者。资料围绕“让科研像聊天一样简单”展开收录多智能体从数据采集、清洗、分析到可视化的完整链条支持社交媒体、数据库、接口数据采集可输出统计图、热力图、网络关系图、词云等并重点给出基于提示词的爬虫任务、Python脚本自动化、春运数据表格化等实测案例逐一对比DeepSeek R1、OpenAI o3mini、Claude 3.5 sonnet、Kimi k1.5在响应速度、结果完整度、调试难度上的差异还附有各模型优劣势与排错观察方便读者按需选型。资料也点出低延迟、轻量级、多模态与医疗法律等垂直领域优化等模型特征帮助理解不同应用场景的选型逻辑。整份资料为单个PDF文件大小约5.66MB不依赖环境即可快速阅读。目前已有374人学习适合零基础起步或想评估大模型科研辅助能力的读者参考。1. 凌晨一点你还要亲手去啃四十篇文献吗DeepSeek 和 DeepResearch 给出了一个新解法凌晨一点你手里攥着四十多篇论文屏幕上是导师发来的“明天中午交个目录”。过去这套从头读到尾的调研姿势最近开始被 DeepSeek 和 DeepResearch 的组合改写了。某高校团队发布的第四弹方案把 DeepSeek 的推理能力装进 DeepResearch 这个专门跑完整调研流程的智能体框架里你像聊天一样说一句“帮我梳理这个方向的争议点”它自己拆解问题、生成检索词、逐篇读再带着引用和数据把综述骨架递回来。它不负责替你写定稿它负责把“从问题到提纲”这段最耗时的人肉搜索变成自然对话。适用的人很明确要读文献的博士生、做技术预研的工程师、给课题找开题思路的导师。接下来我会把这个组合的工作流拆开再给出一套用 DeepSeek 接口自建最小闭环的可复现做法。2. DeepResearch 的“灵魂”不是检索是把检索变成一个可对话的三层工作流很多人第一次用 DeepSeek 加 DeepResearch最直观的感受是“它居然会自己搜”。但真正让它和普通聊天机器人拉开差距的是它内部把一次调研拆成了三个层次先规划再执行最后综合。这三层不是简单的先后关系而是每完成一步就把结果写回对话上下文让下一层基于已有证据继续推进。这也是“像聊天一样简单”背后真正的工程成本所在。2.1 规划层聊天时 DeepSeek 如何把模糊需求翻译成科研计划用户丢过来的一句话往往非常模糊。比如“帮我看看大模型做代码生成现在到什么程度了”这句话里既没有时间范围也没有强调是工程落地还是学术评测更没有说明要的是综述、对比还是方案建议。如果直接拿这句话去检索搜回来的内容大概率是科普稿和新闻稿而不是科研需要的文献材料。DeepResearch 的规划层做的事就是先把这句话变成一份可执行的研究计划。常见做法是让模型生成一组子问题例如“现有代码生成模型在哪些任务上评测”“Agent 场景下的评测基准有哪些”“当前公认的短板和争议点是什么”。每个子问题再对应一组检索词。这个过程看起来只是多问了几句但它决定了后面所有检索的质量上限。这个环节我会单独用推理模式比较强的模型来跑。原因在于拆解问题需要模型做多步推理把一个大问题逐步分解成证据可获取的小问题。如果让普通对话模型直接拆往往只会拆出“什么是代码生成”“代码生成的发展历史”这类泛泛而谈的目录七个子问题里有五个都搜不到具体证据。拆解质量差的另一个表现是检索词冗余几个词搜出来的结果高度重叠等于白白浪费了搜索预算。规划层的产出物一般是一份结构化的任务清单里面包含子问题、每个子问题的检索词、以及“什么样算回答完毕”的判断标准。这个清单会作为后续每一轮的参考框架所以 DeepResearch 在实现上不会让它只出现一次而是会在每轮对话结束时重新把已确认的信息压缩进上下文。你中途追问一句“重点看看多智能体协作”规划层也会把这个问题追加进任务清单而不是让它在对话里漂着。2.2 执行层多轮检索和阅读的循环到底循环了什么执行层是 DeepResearch 最耗时、也最容易出问题的一层。它循环的核心动作有四个生成检索词、执行检索、筛选阅读、抽取要点。这四个动作会反复执行直到规划层定义的所有子问题都拿到了足够的证据。先看检索词生成。这个环节的工程细节远超大多数人想象。直接拿原始问句去搜是最省事但最无效的做法。一个好的执行层会为每一个子问题生成多组变体包括中英文不同表述、上位概念、下位概念、反方视角。比如研究“大模型代码生成的评测基准”至少会拆出“code generation benchmark”“代码生成评测”“Agent 代码生成评测”“HumanEval MBPP SWE-bench 对比”这几组。这样做的目的是覆盖不同来源的写作习惯避免只依赖某一类网站的词汇习惯。检索完成之后紧接着是筛选。实际检索结果里往往有大量重复的新闻稿、官方博客、以及互相转载的技术帖子。执行层要做两件事按域名和标题去重以及按来源类型做优先级排序。我一般会在一开始就把某些只转载不原创的站点拉进忽略名单不然一轮五个检索词搜下来模型会把同一篇文章读五遍还当成五个独立来源写进综述。阅读文章时工程上的做法是先读标题、摘要、发布时间和正文前两段再根据子问题决定要不要读全文。很多自建工作流图省事把整篇文章全文塞给模型结果 token 消耗翻了几倍回答质量却没提升。因为科研调研真正需要的是“和当前子问题直接相关”的片段而不是整篇文章。DeepResearch 在执行层会把一篇文章按段落切开单独评估每段相关度只把命中的片段送进后续综合阶段。这样既省钱也减少无关信息对最后报告的干扰。执行层最后一步是状态更新。每完成一次检索和阅读模型要把新拿到的信息归纳成结构化笔记并判断当前子问题是否已经“有足够的证据回答”。如果不够就再生成一轮新的检索词继续。这个判断是整个循环能不能停下来的关键。判断标准设得太松报告会缺内容设得太紧模型会在同一个子问题上反复检索既烧时间又烧预算。2.3 综合层把几十个片段改造成有可信度的报告最后一个综合层处理的是“如何把零散笔记变成一份能交出去的报告”。这一步不只是把几十个片段接在一起它要面对三个具体问题证据冲突、引用粒度、以及未解答问题的交代。证据冲突几乎是必然出现的。不同来源对同一个指标可能给出不同数据有的是因为统计口径不同有的是因为来源本身已经过时。综合层需要判断冲突的成因而不是简单地把两个说法都写进去。我自己的习惯是让模型优先采用来源日期更新、且实验条件描述更完整的那一条同时在报告里标注“该指标在不同评测中存在口径差异”。这个处理方式比强行选一边更像真人写综述。引用粒度决定了报告能不能被核验。靠谱的引用不会只写“据某论文显示”而是能精确到具体的 URL、标题、发布时间和关键数字。DeepResearch 的做法是给每个检索结果分配一个引用编号综合时引用编号而不直接引用文本最后再统一替换成可点击的来源列表。这样做的好处是模型在生成阶段看不到原始 URL也就没有机会编造看似合理的链接地址。综合层还要明确地把“没查到的内容”写出来。科研调研和写文案不同能明确说出来“这个问题目前没有找到公开权威资料”比硬凑一段话要可信得多。我通常会在提示模板里要求模型把未解答问题单独放在报告末尾而不是混进正文里试图掩饰。这一步看似简单但非常影响读者对整份报告的信任度。3. 用 DeepSeek 接口自建一个最小版 DeepResearch从提示模板到可跑代码前面聊的是 DeepResearch 的架构逻辑这一章直接落到可以抄的层面。你可以选择直接使用别人搭建好的 DeepResearch 产品也可以按下面这套思路用 DeepSeek 的接口自己搭一个最小闭环。自建的好处是每个环节都可控检索词怎么生成、引用怎么挂、什么时候停下来都由你自己说了算。3.1 选型盘一盘直接用产品还是自建工作流先给一个直观对比方便你决定走哪条路。考虑维度直接用现成的 DeepResearch 产品用 DeepSeek 接口自建工作流上手速度注册后马上能用几乎零门槛需要写代码、接搜索服务通常要半天到一天可控程度黑匣子内部提示和检索策略基本不可调每个环节都可以改甚至替换模型引用可信度取决于产品实现不同产品差异很大自己控制引用生成逻辑可以做到严格可核验成本通常是按次或按月订阅按 token 和搜索次数计费规模可控但需要自己监控适合人群只要结果、不想折腾技术细节需要定制调研流程、接入私有数据、或者做科研的人我个人的建议是如果你只是临时要一份调研资料直接用现成产品如果你准备把调研助手用进日常科研流程甚至想让它对接内部文档自建才是长期的解法。自建的前期成本主要在接入搜索服务上面。目前主流搜索服务商基本都提供标准的 REST 接口申请一个 API Key 就能用适配成本并不高。3.2 先用一个提示模板把“聊天”约束成“研究”自建工作流时系统提示词比任何参数都重要。下图是我整理的一份基础提示模板适合作为第一版跑通你是一个科研调研助手。你的目标是把用户的模糊问题转化成一次严谨的小规模文献调研。 工作方式 1. 先不要回答用户问题而是把问题拆成 3~6 个可检索的子问题。 2. 每个子问题给出 3~5 组检索词检索词要覆盖中英文、同义词、反方视角。 3. 检索回来后只保留与子问题直接相关的片段并为每个片段记录来源编号。 4. 综合时只能引用检索结果中真实出现的来源禁止根据记忆补充引用。 5. 如果某个子问题没有找到充分材料明确写“未找到公开权威资料”不要硬填。 6. 最终报告分为研究结论、证据细节、未解决问题三个部分。这份模板解决的核心问题是把“聊天”里的随意性压缩到最低。第一句话就把模型定位成调研助手而不是聊天伙伴第二条强制生成同义词变体避免检索词过窄第四条直接堵死了幻觉引用的来源。实际使用时我会根据任务性质调整最后一句话。如果调研目标是“方案选型”第三部分会改成“候选方案对比与适用条件”如果目标是“开题报告”第三部分则是“研究空白与可切入角度”。模板的作用在于约束行为边界具体内容跟着任务走。3.3 最小可跑的 Python 闭环三阶段代码骨架这一节给出一个能跑起来的完整骨架总共三个核心函数。你可以把它保存成一个 Python 文件设置好环境变量后直接运行。# research_mini.py —— 最小可用的 DeepSeek 调研助手骨架 import os import json import requests第一步封装 DeepSeek 的通用调用接口def call_llm(messages, toolsNone, modeldeepseek-chat, temperature0.2, max_tokens4096): # 环境变量里读取密钥不要把密钥直接写死在代码里 url https://api.deepseek.com/chat/completions headers {Authorization: fBearer {os.getenv(DEEPSEEK_API_KEY)}} payload { model: model, # deepseek-chat 响应快复杂推理可换 deepseek-reasoner messages: messages, temperature: temperature, # 调研任务建议 0.1~0.3越低越稳定 max_tokens: max_tokens, } if tools: payload[tools] tools # 需要工具调用时传入函数声明列表 resp requests.post(url, headersheaders, jsonpayload, timeout180) resp.raise_for_status() return resp.json()[choices][0][message]这个函数是后续一切调用的基础。参数上我单独说明两点temperature 在调研任务里一定要调低因为科研调研需要的是稳定、可复现的输出不是天马行空的发挥max_tokens 设置 4096 是为了给后续长报告预留空间如果设太小报告后半段很容易被截断。第二步封装一个统一的搜索函数。不同搜索服务商的接口差异很大我这里按最常见的形式做一个适配层def web_search(query, limit8): # 搜索服务商普遍提供 REST 接口这里统一转成三个核心字段 headers {Authorization: fBearer {os.getenv(SEARCH_API_KEY)}} resp requests.post( os.getenv(SEARCH_API_URL), headersheaders, json{q: query, num: limit}, timeout60, ) resp.raise_for_status() raw resp.json().get(docs, []) return [ {title: d.get(title, ), snippet: d.get(snippet, ), url: d.get(url, )} for d in raw ]这里有一个实际工程里的血泪经验搜索结果字段名几乎每个服务商都不一样。有的叫 title有的叫 name有的叫 headline。你拿到手第一件事不是写业务逻辑而是先写一个字段映射层把所有来源统一成 title、snippet、url 三个字段。后面所有环节都只跟这三个字段打交道换搜索服务商时只改这一处。第三步把三个阶段串成完整流程def research(question): # 阶段一让模型输出子问题和检索词 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question}, ] plan_msg call_llm(messages, temperature0.3) plan_text plan_msg.get(content, ) # 从计划里提取检索关键词这里按文本行做简单解析 queries [] for line in plan_text.splitlines(): if 检索词 in line: query line.split(检索词)[-1].strip() queries.append(query) # 阶段二逐个检索把结果抽成结构化笔记 notes [] for q in queries[:5]: # 硬限制最多执行 5 个查询防止预算失控 docs web_search(q) note_msg call_llm([ {role: system, content: 你是笔记整理器。只提取与调研直接相关的信息。 为每个来源标注序号、标题和 URL禁止补写内容。}, {role: user, content: json.dumps(docs, ensure_asciiFalse)}, ], temperature0.1) notes.append(note_msg.get(content, )) # 阶段三综合笔记生成报告 report_msg call_llm([ {role: system, content: 你是综述写作者。基于笔记内容写一份调研报告。 报告分三部分结论、证据细节、未解决问题。 每个关键论点后必须标注来源序号。}, {role: user, content: \n\n.join(notes)}, ], temperature0.3) return report_msg.get(content, ) if __name__ __main__: output research(调研大模型在代码生成方向的主流评测基准重点看 Agent 场景) print(output)这套代码的骨架逻辑并不复杂但它已经具备了一个 DeepResearch 最小闭环的四个关键点规划拆解、约束检索、阶段笔记、综合报告。你运行一次就能看到它和普通聊天的明显区别。需要说明的是这套骨架做了两个简化。第一是没做全文阅读只读了搜索结果里的摘要片段真实调研中摘要往往不够第二是引用序号没有严格和来源 URL 绑定后面版本需要把 notes 里的序号映射回原始 URL这块我会在下一章展开。3.4 跑通之后先按这三个硬指标验收代码跑通不等于能用。我每次搭建完类似的工作流都会按下面三个硬指标做验收缺一个都要返工。验收指标通过标准不通过时怎么调可复核引用报告中每个关键数字和论点都能通过标注找到具体来源链接检查阶段二是否丢了 URL 字段记住要改综合阶段的提示模板问题覆盖度原始问题拆出的子问题全部有回答没有只写了一半把报告和规划阶段的子问题清单对照缺项就加大检索轮次过程可追溯能从对话记录里看到每一步搜索了什么、读了什么给每个子问题编号并在阶段笔记里保留对应编号这套验收标准不是凭空拍的。实际深挖过各类调研助手的朋友都知道很多 Demo 看起来惊艳但引用链接点进去是 404或者结论建立在单一来源上。这种产出在正式科研场景里是没法用的。所以验收的核心就是看它能不能通过“人肉复核”这一关。4. 参数怎么设、边界在哪里把 DeepResearch 用得又稳又省代码跑通只是第一步。真正进入日常使用后你需要面对的是参数选择、上下文管理、成本控制这几个实际问题。这一章我按自己的使用习惯把最关键的几个点列出来。4.1 四个必调参数模型选择、温度、输出上限、循环次数参数不是越多越好真正影响调研质量的通常就四个。参数推荐设置影响范围常见翻车方式模型选择规划用 deepseek-reasoner摘要和检索用 deepseek-chat规划质量决定调研方向摘要速度决定整体耗时全部用推理模型费用翻倍全部用普通模型规划太浅temperature规划 0.3检索整理 0.1综合 0.3数值越高输出越多样但越不稳定设成 0.7 以上同一份材料每次生成的内容都不一样max_tokens单轮至少 4096长报告拆分输出决定了单次生成能写多长设 1024报告末尾被切掉还没报错最大检索轮数5~10 轮控制总耗时和总费用不设上限模型陷入死循环预算烧完模型选择是第一个值得反复调的地方。DeepSeek 的接口里deepseek-reasoner 适合做需要多步推理的任务比如把模糊问题拆成子问题、判断证据之间是否冲突deepseek-chat 则适合做高吞吐的整理任务比如把检索结果压成笔记。混用两个模型效果比单用任何一个都好成本也最合理。max_tokens 这个参数很容易被忽略。调研报告动辄几千字如果上限设低了模型会在中间截断而且不会提示你“被截断了”。我自己第一次跑的时候就踩过这个坑报告写到一半戛然而止后半段一个论点都没有。后来养成的习惯是不在单次调用里硬憋完整报告而是让模型按子问题分段输出最后再合并。最大检索轮数的意义在于兜底。检索阶段是有可能陷入循环的模型发现证据不足生成新检索词又发现新的不足再生成下一组。如果不设上限这个循环可以永远跑下去。我会在提示模板里明确写“最多执行 n 轮检索如果仍未找到足够证据直接记录为未解答问题”从行为层面对模型做硬约束。4.2 上下文管理为什么聊着聊着就跑偏了聊天式交互最大的陷阱就是对话越长模型越容易忘记最初的问题。你可能在调研中途问了一句“顺便看看这个指标的原始定义”等到报告生成时模型已经把这个顺便当成了主线前面花大量篇幅调研的子问题反而不写了。追根到底这是上下文管理没做好。通用的滑动窗口机制会不断丢弃旧内容而调研任务恰恰需要保留完整的问题框架。我的做法是每次进入下一阶段之前把当前结构写成一个固定的摘要块放回消息列表的合适位置。摘要块保留的内容包括原始问题、当前计划、已完成子问题、待办子问题、以及最近一次的需求变更。调研任务状态 原始问题大模型代码生成评测基准重点 Agent 场景 当前计划已拆出 5 个子问题第 3 个子问题正在检索 已完成评测基准汇总、Agent 任务类型分类 变更记录用户新增要求“补充多智能体协作场景” 下一步检索 multi-agent code generation benchmark这个摘要块的文字不需要多精美但它起了锚点作用。后面无论模型聊到哪里系统提示里始终有这个块它就能追回主线。我把这个块当作工具调用的系统状态来用而不是靠对话记忆。这一点的价值等你实际跑过超过十轮的长任务后会有非常直接的体会。4.3 成本与合规边界提前划好避免翻车成本控制是自建方案绕不开的话题。问题不是 API 单次调用有多贵而是检索循环会把它放大多少倍。一次完整调研可能要做十几次模型调用、几十次搜索。如果没设上限一次调研花掉几十块钱也不奇怪。我常用的成本控制手段有三层。第一层在提示层要求模型只输出与子问题相关的笔记不要整篇复述文章内容能省下大量 token第二层在代码层比如本篇文章里的工作流示例设置了最多执行 5 个查询搜索调用数量和最大轮数都有硬上限第三层在预算层给一轮调研预设一个 token 消耗阈值达到阈值就停止检索把当前结果汇总成阶段性报告。另一个容易被忽略的是数据合规。科研场景里经常涉及未发表论文、内部技术报告、甚至用户隐私数据。直接把全文丢给云端 API在大多数机构里都过不了合规审核。我一般的习惯是先做脱敏再调用只把标题、摘要、和经过脱敏的关键段落发给模型如果条件允许尽量部署私有化模型来处理敏感数据。这个边界宁可事前划得严一点也不能事后出了问题再去补救。5. 避坑手册聊天式科研跑稳后这 5 个坑最磨人5.1 检索词太窄整份报告像只有一个人在世界现象跑完一份调研报告内容高度同质化所有结论都来自同一类来源甚至同一个域名的不同页面。 原因模型直接把用户原话作为检索词没有做同义扩展和视角扩展。比如用户说“代码生成模型”它就只搜“代码生成模型”搜出来的全是同一篇文章被转载了无数次的版本。 解决在系统提示模板里加一条硬约束——每个子问题必须给出中英文、上位词、下位词、反方视角至少四组检索词。反方视角尤其重要比如研究“大模型的代码生成能力”一定要补一个“限制与失败案例”方向的检索词否则报告一边倒。5.2 引用格式完美点开链接却不存在现象报告里每个论点都挂了引用格式规范标题也有模有样但用手点进去要么 404要么跳转到完全不相关页面。 原因这是典型的幻觉引用。当模型没有拿到具体来源信息时它会根据文章风格推测一个像样的标题和链接。这个问题不是靠提示词“不要编造”就能解决的因为模型在生成阶段确实“以为”自己说的是真的。 解决让模型在综合阶段只使用来源编号而不是直接生成 URL。也就是把“引用 https://xxx”改成“引用 [来源 3]”最后统一由代码模块把编号映射回真实检索结果里的 URL。这样模型根本没有机会输出它想象的链接。5.3 中途补了一句需求报告写成两套论点现象你调研到一半想起一个细节顺手说“再加一个对比维度”。结果最终报告前半部分按旧计划写后半部分按新需求写两边论点互相打架。 原因对话历史太长模型把新需求当成了补充而不是一次计划变更。旧任务框架还残留在上下文里新需求又加了进来两套结构同时生效。 解决把需求变更显式化。我自己的做法是在消息里单独发一条“任务变更”文本内容包括变更原因、影响到的子问题、以及需要重新规划的范围。变更后先回到规划层重新确认子问题列表再进入检索阶段不直接在当前流程里插入需求。5.4 长报告后半段烂尾引用也跟着断掉现象报告生成到一半直接停止或者后面几段明显变短连结论都没有就被截断了。 原因max_tokens 设太小或者一次让模型输出太长的内容。调研报告通常要去到一个很完整的结构半途截断往往发生在模型还没到结论区就被 token 上限拦住。 解决从两个方向入手。一是按子问题分段生成每段控制在 800 到 1200 字以内最后让模型基于分段摘要生成总报告。二是在代码层增加截断检测如果返回结果的 finish_reason 是 length就自动缩减后续输出规模而不是直接当作成功返回。5.5 循环失控预算直接烧穿现象一次简单的调研请求最终产生了上百次工具调用账单出来一看超过预期。模型反复搜索同一个子问题生成检索词、搜索、发现证据不足、再生成新检索词陷入死循环。 原因没有给检索循环设置硬性退出条件。规划层定义的“足够证据”标准不够明确模型每次都觉得“还差一点”就继续搜下去了。 解决两条措施并行。一是在代码里设置最大检索轮数比如 5 轮到点强制进入综合阶段。二是在提示模板末尾加退出条件“如果你的笔记中存在相互矛盾但可并存的证据也能算作完成不必继续检索。”这句话能让模型明白证据可以多元不必追求找到一个统一答案。6. 别让报告停留在“满篇话”把调研结果变成下一步问题清单再进入下一轮跑通整套流程之后我想分享一个对我自己帮助很大的进阶习惯不强求一次调研得到终极答案而是让每次调研的产出成为下一轮调研的起点。具体操作上我会在每轮调研结束后使用 DeepSeek 接口把报告里“未解决问题”的部分扩展成三个有形问题并明确验证方式。比如报告结论里出现“评测指标 A 在不同实现下结果差异明显”我就会让模型生成差异的具体来源是什么有没有可用的复现实验步骤如果复现最小数据集和运行环境是什么这三个问题会存成一份清单配额完成后直接作为下一轮对话的输入。这样做的好处非常明显。每一份报告到最后都不只是文本文档而是一张不断生长的调研地图。你甚至可以把清单直接整理成可勾选的任务列表把其中能自动化回答的问题交给工具把需要人工判断的问题留给自己。有一个小技巧是在下一轮对话时把“上一轮问题的验证结果”放在消息最前面让 DeepSeek 基于验证结果修正调研方向而不是又回到最初那个模糊问题重来一遍。持续性使用这套工作流的另一层体验是你会慢慢发现它的性能边界在哪里。我可以接受它偶尔漏查一篇我需要的那篇论文也可以接受它刚开始没有给我想要的对比视角但不能接受它只能输出一段好读但不可核验的话。我把“引用可核验、回答可追溯、未解答问题老实说明”当成底线只要满足这三条其余缺陷都是可以修的。到现在我已经把顺手做的任务清单养成了一个固定习惯。每次开一个新的调研课题我先丢给这套工作流跑一轮拿到带着引用和问题清单的草稿再基于草稿手动深挖。这样既没有放弃人的判断力也把最耗时的“找素材、排结构”环节省了下来。如果你现在正在被文献综述或者技术选型调研烦恼不妨从最小闭环开始跑一次让它帮你把“从头读到尾”变成“聊着聊着就聊完了”。希望帮到你。本文还有配套的精品资源点击获取