Agent 开发：Deep Search 和 Deep Research 有什么区别？
前几天有个朋友问我，Deep Search 和 Deep Research 到底有什么区别。
他看到不少人讨论这两个词，也在大厂招聘里看到 DeepSearch Agent 相关岗位。对英文不太敏感的人，第一眼很容易把它们当成同一个东西：一个是深度搜索，一个是深度研究，听起来只是换了最后一个单词。
有这个疑问很正常。现在的产品命名本来就没有完全统一。OpenAI、Google 更常使用 Deep Research，Grok 用过 DeepSearch，有些团队还会把 Agentic Search、Research Agent、Search Agent 混在一起说。同一种能力，在产品页面、招聘描述和论文里可能有不同名字；同一个名字，落到不同产品里，能做的事情也未必一样。
所以只翻译单词不太够。要看它们接到任务以后分别做了什么，最后又交付了什么。
它们为什么看起来很像
Deep Search 和 Deep Research 都建立在搜索之上，也都比传统搜索多走了几步。
传统搜索接到一个查询以后，主要工作是从索引里召回网页，再按相关性、质量和时效性排序。用户面对的是一页链接，需要自己打开、阅读和比较。带联网能力的大模型往前走了一步：模型调用搜索工具，读取若干结果，然后直接组织成回答。
Deep Search 和 Deep Research 又继续往前走。它们不会满足于一次查询返回的前几条结果。模型可以拆分问题，生成多组搜索词，打开网页，发现缺口，再换一个方向继续查。遇到相互冲突的信息，它还可能寻找原始来源或补充证据。
从外面看，两者都在反复搜索、阅读网页、整理资料，也都可能给出引用。运行时间同样比普通问答长。这些共同点足以让大多数用户觉得它们是一回事。
区别要到任务进行到后半段才会明显。Deep Search 更关心资料有没有找到，Deep Research 还要继续处理研究问题本身。
Deep Search 主要解决怎么把资料找出来
普通搜索通常由人控制搜索过程。人先输入一个关键词，看到结果不理想，再补充限定词，或者换一种问法。搜索引擎负责每一轮召回，人负责决定下一轮查什么。
Deep Search 把这部分判断交给 Agent。它会根据问题制定搜索方向，并在阅读结果以后继续调整查询。
比如用户想了解某个新发布的 Agent 框架能不能用于生产环境。一次搜索很可能只得到官网介绍、发布新闻和几篇转述文章。Deep Search 会继续追问：
- 官方文档里有没有稳定性说明；
- 仓库最近的 issue 集中在哪些问题；
- 是否支持持久化、重试、权限控制和可观测性；
- 版本更新是否破坏兼容性；
- 有没有团队公开过真实使用经验。
这些问题不一定由用户逐条写出来。Agent 可以根据已经找到的材料决定后续搜索方向。官网写得很完整，它可能转去查 GitHub issue；一篇评测没有说明测试版本，它会继续找实验配置；几篇文章引用同一个数字，它会回溯数字最早来自哪里。
Deep Search 的价值集中在搜索过程。它减少了人反复修改关键词、打开页面和过滤低质量结果的工作。最后交付的内容可以是一段回答、一组事实、一个来源列表，也可以是一份比较详细的摘要。形式并不固定，关键是信息经过了多轮查找和筛选。
这种系统至少要处理查询拆分、搜索词改写、网页读取、结果去重、来源判断和交叉核验。搜索轮次增加以后，成本和延迟也会跟着上升，因此它还需要知道什么时候继续查，什么时候现有信息已经够用。
Deep Research 要完成一项研究任务
Deep Research 接到的通常是开放程度更高的问题。用户想要的也不只是一组资料，而是一份可以拿去阅读、讨论或者辅助决策的研究结果。
仍然以上面的 Agent 框架为例。如果任务变成“评估这个框架是否适合公司的长期任务系统”，研究过程就不能停在功能和资料汇总上。系统需要先弄清楚公司的任务类型、运行时长、数据敏感程度、现有技术栈和容错要求。缺少这些条件，“适合生产环境”只是一个空泛判断。
接下来，它要把问题拆成几个可以调查的部分，决定先查哪些资料，以及什么证据能够支持结论。搜索官网、代码仓库和用户案例只是其中一段。材料回来以后，系统还要比较来源，处理相互矛盾的信息，区分产品承诺与已经落地的能力，并说明哪些问题暂时没有足够证据。
最终交付物也会更接近报告。报告里需要有研究范围、主要发现、判断依据、引用来源和已知限制。结论与证据之间要能对应，读者最好可以沿着引用回到原始材料，而不是只看到一段语气笃定的总结。
OpenAI 在 Deep Research API 的说明中，把这类任务描述为需要推理、规划和综合真实世界信息的复杂研究流程。Google 的 Gemini Deep Research Agent 也把协作规划单独做成一个阶段：Agent 可以先返回研究计划，用户修改或批准以后再开始执行。这里的规划并非界面上的装饰，它决定系统接下来找什么、找多深，以及怎样组织结果。
因此，Deep Research 的工作范围更长。它要理解研究目标，必要时澄清问题，形成计划，调用搜索和其他数据工具，管理中间证据，完成分析，再把结果写成带引用的报告。
Deep Search 经常是 Deep Research 的一部分
两者的关系并不复杂。Deep Research 要获得外部资料，通常会使用 Deep Search 这类多轮搜索能力。搜索负责把分散在网页、文件、数据库和其他系统里的材料带回来，研究流程负责决定这些材料能不能回答问题，以及如何形成结论。
但不能因为 Deep Research 会搜索，就把所有联网问答都叫作深度研究。模型调用一次搜索接口，读取几条结果并生成答案，仍然更接近带搜索能力的问答。即使搜索了很多网页，如果系统没有明确研究目标，没有管理证据，也没有把发现组织成可检查的研究结果，它完成的主要还是搜索任务。
反过来，Deep Research 使用的数据源也不只来自公开网络。OpenAI 的实现可以接入 Web Search、File Search 和符合搜索、读取接口的 MCP 服务，也能调用 Code Interpreter 分析数据。Google 的实现支持搜索、网址上下文、代码执行、文件输入和外部工具。企业里的研究 Agent 还可能查询内部知识库、数据库、财报或业务系统。
搜索决定材料从哪里来，研究决定材料回来以后怎么用。这也是 Deep Research 比单纯增加搜索次数更难的地方。网页找得再多，如果来源质量差、事实没有对应引用、相互冲突的材料被强行揉在一起，最后那份报告仍然乏善可陈。
几个方面放在一起看
产品名称会变化，但可以通过任务表现判断它更接近哪一种能力。
| 观察角度 | Deep Search | Deep Research |
|---|---|---|
| 用户通常想得到什么 | 更完整、更可靠的信息 | 对一个开放问题的系统研究 |
| 系统主要做什么 | 拆分查询，多轮搜索，阅读和核验来源 | 澄清目标，制定计划，搜索取证，分析并形成报告 |
| 中间结果 | 搜索词、网页、事实和来源 | 子问题、研究计划、证据、判断和未解决问题 |
| 最终输出 | 回答、资料摘要或来源集合 | 结构化、带引用的研究报告 |
| 什么时候停止 | 已经找到足够回答问题的信息 | 研究范围得到覆盖，主要判断有证据支持 |
| 常见耗时 | 数十秒到数分钟 | 数分钟到数十分钟，复杂任务可能更久 |
有的 Deep Search 产品已经能生成长报告，有的 Deep Research 产品只在内部跑一个主 Agent。
好的判断方法是看系统有没有留下研究结构。它是否先确认任务范围，是否形成可以修改的计划，是否保存主张与来源的对应关系，是否主动暴露证据缺口，是否能说明结论受哪些条件限制。这些能力出现得越完整，系统越接近我们所说的 Deep Research。
RAG
RAG 经常和这两个概念一起出现，因为它们都需要外部知识。区别在于，传统 RAG 的检索流程通常比较固定：根据用户问题从已有知识库取回相关片段，然后让模型基于这些片段回答。
这种方式很适合企业文档问答。知识范围相对确定，文档已经进入索引，系统主要解决“应该取回哪些片段”。它可以做得很复杂，包括混合检索、重排序和上下文压缩，但任务路径通常不会因为中间发现而大幅改变。
Agentic RAG 开始让模型参与检索决策。模型可以选择知识库，改写查询，判断结果是否相关，资料不足时再次检索。走到这一步，它和 Deep Search 已经有明显交集。
Deep Research 会把这些检索能力放进更长的任务里。知识库检索、网络搜索、浏览器阅读和数据库查询都可以成为研究过程的一部分。系统关心的不只是某个片段与问题是否相似，还要判断证据是否充分、来源是否可信，以及几组材料放在一起能够支持什么结论。
所以 RAG、Deep Search 和 Deep Research 不需要被看成三个互相替代的产品。RAG 提供知识检索，Deep Search 让搜索过程可以自主迭代，Deep Research 再把检索、分析和报告组织成一项完整任务。真实系统经常同时使用它们。
大厂开始招这类人
回到朋友最初看到的招聘信息。岗位名称里出现 DeepSearch Agent，并不意味着工作内容只是接一个搜索 API。
搜索 Agent 开始自主运行，就会碰到一连串工程问题。用户的问题可能含糊，系统要先理解意图；一个复杂问题会生成很多查询，系统要控制搜索宽度和深度；网页内容有广告、重复转载和过期信息，系统要判断来源质量；多轮工具调用会形成很长的执行序列，前面选错方向，后面会越走越偏。
对结果评测也是困难的。只看最终文字是否流畅，容易放过错误引用和遗漏。团队还要检查事实是否准确、引用能否支持原句、来源质量如何、搜索过程是否浪费、任务用了多少 token 和时间。招聘要求里出现 RAG、搜索算法、Agent 架构、工具调用、Reasoning、强化学习和评测，并不突兀，它们分别对应这条长链路上的不同问题。
从产品侧看，搜索正在从“给用户一页结果”变成“替用户完成一段信息工作”。用户少点开几十个网页，系统就要多承担几十次判断。模型能力提高以后，真正拉开体验差距的会是搜索路径、工具质量、证据管理和评测体系。
回到最初的问题
如果只记一个简单区别，可以这样理解：Deep Search 负责把需要的资料找得更深、更全，也更可靠；Deep Research 使用这些资料完成一项有目标、有过程、有证据的研究任务。
它们关系很近。许多 Deep Research 系统内部都有 Deep Search，许多 Deep Search 产品也在逐渐补上规划、分析和报告能力。