第 1 章:为什么需要 Deep Research

能讲清 Deep Research 和普通 RAG / Agentic RAG 的本质区别,判断一个问题该不该上 Deep Research,并用可运行代码搭出一个会「自己多步搜索、边想边查」的研究型 Agent 雏形

📊 学习时长:60-75 分钟 🎯 完成后能力:能讲清 Deep Research 和普通 RAG / Agentic RAG 的本质区别,判断一个问题该不该上 Deep Research,并用可运行代码搭出一个会「自己多步搜索、边想边查」的研究型 Agent 雏形 🔗 关联面试题:5 道(覆盖 5 个角度,见 Part 3)

这一章你会学到什么

✓ 零基础也能跟着做:用几十行代码跑通一个会「边想边查」的研究型 Agent,并一步步给它加上工具、思维链、失败重试
✓ 彻底搞懂 6 个核心概念:Deep Research、工具调用、多步推理、ReAct、思维链、引用溯源,每个都先白话、再术语、配图
✓ 想清一个关键判断:同样是「问答」,什么问题普通 RAG 一次检索就够,什么问题非得让 Agent 自己「做一轮调研」
✓ 划清三条技术路线的边界:普通 RAG vs Agentic RAG vs Deep Research,以及主流系统(OpenAI / Gemini / 开源)各走了哪条
✓ 提前看清这条路最大的坑:「多步 = 错误会累积放大」,以及工程上从哪几层兜住它(后面几章会逐一展开)
✓ 建立全书心智模型:调研 = 规划 → 多步检索 → 交叉验证 → 综合成带引用的报告,这条线决定了后面所有章节的顺序

本章按三段式组织,不同基础的读者各取所需:

段落给谁看内容占比

🚀 Part 1 · 主线实战 零基础,想先跑起来真实场景 + 6 个核心概念 + 可跑的 mini-agent ~50%

🎯 Part 2 · 面试深度 想讲透、备战面试三条路线边界 + 何时该上 + 主流系统拆解 + 多步脆弱性 + 业内行话 ~40%

🏆 Part 3 · 验收串题 检验学到位没关联面试题 + 自检清单 ~10%

段落	给谁看	内容	占比
🚀 Part 1 · 主线实战	零基础,想先跑起来	真实场景 + 6 个核心概念 + 可跑的 mini-agent	~50%
🎯 Part 2 · 面试深度	想讲透、备战面试	三条路线边界 + 何时该上 + 主流系统拆解 + 多步脆弱性 + 业内行话	~40%
🏆 Part 3 · 验收串题	检验学到位没	关联面试题 + 自检清单	~10%

🚀 Part 1 · 主线实战 ｜ ~50% 这部分零基础也能跟着做。只要一个 DeepSeek API key,几十行代码就能让你亲眼看到一个 Agent 怎么「自己决定查几次、什么时候收手」。

先讲个真实场景(这是本章的「为什么」)

我们给一个开发团队做过一个「技术选型调研助手」。工程师每天要回答的,不是「pgvector 最新版本号是多少」这种一查就有的问题,而是这种:

「我这个中小规模、还想少花点运维精力的 RAG 项目,向量库到底该选 Milvus、Qdrant 还是 pgvector?」

第一版我们老老实实走普通 RAG:把问题丢进向量库,检索几篇博客和文档,拼一段回答。结果出来的东西工程师根本不敢照着做,要么只夸了其中一个、要么拿的是两年前的旧对比、要么把「嵌入式 / 单机 / 分布式」这几种完全不同的部署形态混为一谈。

复盘下来,根因很清楚:这个问题的答案,根本不在任何一篇文档里。 它需要:先意识到要分别了解三者、分别去查各自最新的能力与适用规模、判断信息够不够、不够再补一轮、最后结合「我这个项目的真实约束(规模中小、想低运维)」把三边对齐着比较、还要标清楚每个结论的出处。这是一连串带判断的动作,不是一次「查 → 拼」。

那一版上线后,带队的架构师原话是:「它像个只会查一次的实习生,而我要的是一个会自己做技术调研的架构师。」

这句话,就是 Deep Research 和普通 RAG 的分水岭。

普通 RAG 是「查一次就回答」;Deep Research 是「像调研员一样,自己规划、反复查、交叉验证,最后写出有依据的报告」。一张图先看个全貌:

这一整章,我们就先把这个「会做调研的 Agent」最小化地跑起来,再回头讲清它背后的每个概念、以及它和市面上各种「RAG plus」到底差在哪。

6 个核心概念(先白话,再术语)

做 Deep Research 绕不开这 6 个词。我们先用大白话过一遍,建立直觉,后面写代码和讲面试时就不会卡。

概念 1:什么是 Deep Research?

Deep Research,就是让大模型像一个调研员那样工作:接到一个复杂问题,自己拆解、自己反复查资料、自己判断信息够不够,最后写出一份有出处的调研报告,而不是一问一答。

它和普通问答最大的区别,是中间那段「自主的、多轮的过程」。普通问答是「输入 → 输出」一锤子买卖;Deep Research 是「输入 → 想 → 查 → 看结果 → 再想 → 再查 → … → 综合输出」的一个循环。

学术上,它通常被定义为一种能自主完成复杂信息检索与调研任务的 AI 系统,把四种能力捏在一起:

大模型的推理与生成能力:拆解问题、判断、写报告
Agent 的规划与执行能力:决定下一步干什么
工具使用能力:真的去搜索、打开网页、算数
长程记忆能力:把几十轮查到的东西管理好、不丢不乱

概念 2:什么是「工具调用」(Tool Use / Function Calling)?

工具调用,就是让大模型不只是「动嘴」,还能「动手」,去调用搜索引擎、打开网页、跑一段计算。

但要注意:模型本身并不能联网,也不会真的执行代码。它能做的只是「说出我想调用哪个工具、参数是什么」,比如输出一句结构化的指令 search("Qdrant 部署运维成本")。真正去执行的是你写的程序:程序解析这句指令、调真实的搜索 API、把返回结果再「喂」回给模型。模型看到结果,再决定下一步。

这个「模型提议 → 程序执行 → 结果回喂」的闭环,是所有 Agent 的地基。理解它,你就理解了为什么 Agent 既强大又脆弱(后面会讲)。

概念 3:什么是「多步推理」?

多步推理,就是模型把一个大问题拆成好几步,每一步看完结果再决定下一步,而不是一口气把答案编出来。

回到向量库选型那个问题,一个像样的多步推理链是这样的:

第 1 步:拆解,这题要分别了解 Milvus、Qdrant、pgvector 三者
第 2 步:查 Milvus 的定位与适用规模 → 看到结果
第 3 步:查 Qdrant、pgvector,同样查一遍 → 看到结果
第 4 步:判断信息够了 → 结合「中小规模 + 低运维」这个约束,对齐三边、综合给结论

关键在于:每一步都依赖上一步的结果。模型查完 Milvus 发现它偏大规模、运维重,才知道接下来要重点对比另两个轻量方案。这种「走一步看一步」的能力,正是普通 RAG 没有的。

概念 4:什么是 ReAct?

ReAct(Reasoning + Acting),是最基础也最常用的一种 Agent 框架。核心一句话:把「想」(Reasoning)和「做」(Acting)交织起来,想一步、做一个动作、看观察结果、再想下一步,如此循环。

它的循环长这样:

Thought(想):现在我缺什么信息?
Action(做):调用一个工具,比如 search(...)
Observation(看):拿到工具返回的结果
回到 Thought,直到「信息够了」才输出最终答案

本章后面那个 mini-agent,就是一个最朴素的 ReAct。

概念 5:什么是「思维链展示」(Chain-of-Thought)?

思维链,就是让模型把「它怎么想的」也一并输出出来,而不只是给个最终答案。

在 Deep Research 里,这一步特别重要:调研类问题用户往往不只要结论,还要看推理过程是否靠谱。工程上常用一个约定的标签(比如 <think>…</think>)把模型的思考过程框起来,前端可以选择展示或折叠:

注意区分:思维链是「展示推理」,多步推理是「真的分多步去执行」。两者常一起出现,但不是一回事,一个是给人看的过程,一个是真实的执行结构。

概念 6:什么是「引用溯源」?

引用溯源,就是答案里的每个关键结论,都标清楚来自哪份资料、哪一段。

这是调研型场景的硬要求。架构师拿到一句「pgvector 不适合十亿级向量」,第一反应是「哪儿说的?是哪个版本、什么规模下的结论?」。没有出处的结论,在严肃的技术决策里等于没有,谁也不敢拿它去拍板。

引用溯源也是对抗幻觉的最后一道防线:逼模型「有据才说」,说不清出处的就别下结论。

顺便:一份调研报告到底长什么样

前面一直说「产出一份带引用的调研报告」,到底长啥样?和普通问答的「一句话」摆一起对比,就一目了然了:

看出区别了吗?调研报告的价值不在「更长」,而在 分点论证、每个结论带出处、还敢标注「这块我没查到可靠来源」。这正是架构师敢拿去拍板的东西,也是这套教程后面所有章节,要一起把它搭出来的最终产物。

🛠️ 跟着做:几十行跑通一个会「多步搜索」的 mini-agent

概念过完,我们立刻动手。下面这段代码就是一个最朴素的 ReAct 循环:模型每一步要么决定「再查一个候选」,要么决定「给最终建议」。搜索工具我们先用一个本地词典 stub,让你不接真实搜索引擎也能零成本跑通(真实系统这里换成搜索 API,后面会讲)。

新建 mini_agent.py:

# pip install openai
import os, re
from openai import OpenAI

client = OpenAI(api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com")

# 玩具「搜索」工具:真实系统接搜索引擎,这里用本地词典,零成本跑通
KB = {
    "milvus": "Milvus:为十亿级向量设计的分布式向量库,功能全;但组件多(etcd/对象存储等)、运维偏重,适合大规模、有专人运维的团队。",
    "qdrant": "Qdrant:Rust 实现,单机性能好、元数据过滤强、单二进制/容器即可部署,适合中小到中等规模、想低运维的团队。",
    "pgvector": "pgvector:PostgreSQL 扩展,复用现有 PG、能和业务数据同库做事务与 join,适合中小规模;超大规模性能吃力。",
}

def web_search(query):                          # 真实系统:这里调搜索引擎 API
    for k, v in KB.items():
        if k in query.lower():                  # 玩具版:命中关键词就返回对应资料
            return v
    return "没有找到相关资料。"

SYS = """你是技术选型调研助手。每步只输出一个动作,二选一:
- 还缺资料:  Action: search("候选名")
- 资料够了:  Final: <结合"中小规模、想低运维"给出选型建议与理由>
一次只查一个候选,缺信息就先 search,别一口气编结论。"""

def run(question, max_steps=6):
    msgs = [{"role": "system", "content": SYS}, {"role": "user", "content": question}]
    for step in range(1, max_steps + 1):
        out = client.chat.completions.create(           # 让模型决定:继续查 or 给建议
            model="deepseek-chat", messages=msgs
        ).choices[0].message.content
        print(f"\n[第 {step} 步] 模型 → {out.strip()}")
        m = re.search(r'search\("(.+?)"\)', out)        # 模型要搜索吗?
        if not m:                                       # 没要搜 = 给最终建议了 → 收手
            print("\n✅ 选型建议:", out.split("Final:")[-1].strip())
            return
        obs = web_search(m.group(1))                    # 执行工具(关键:程序来做)
        print("   🔎 工具返回:", obs)
        msgs += [                                        # 把动作和观察都接回上下文,进入下一轮
            {"role": "assistant", "content": out},
            {"role": "user", "content": f"Observation: {obs}"},
        ]
    print("\n⚠️ 到达最大步数仍未收敛")

run("中小规模、想少花运维精力的 RAG 项目,向量库选 Milvus、Qdrant 还是 pgvector?")

运行

export DEEPSEEK_API_KEY=你的key
python mini_agent.py

你应该看到(模型自主决定逐个查完三个候选才给建议;LLM 输出每次措辞略有不同,但「先逐个查、再综合」这个行为是稳定的):

[第 1 步] 模型 → Action: search("Milvus")
   🔎 工具返回: Milvus:为十亿级向量设计的分布式向量库…运维偏重…
[第 2 步] 模型 → Action: search("Qdrant")
   🔎 工具返回: Qdrant:Rust 实现,单机性能好…想低运维的团队。
[第 3 步] 模型 → Action: search("pgvector")
   🔎 工具返回: pgvector:PostgreSQL 扩展…适合中小规模…
[第 4 步] 模型 → Final: 你这个中小规模 + 想低运维的场景,优先考虑 pgvector(已有 PG 就直接复用)或 Qdrant(低运维、过滤强);Milvus 偏大规模、运维重,先不必上…

✅ 选型建议: 中小规模 + 低运维优先 pgvector / Qdrant;Milvus 适合更大规模再上…

🐛 跑不通看这里

KeyError: 'DEEPSEEK_API_KEY'?没设环境变量,先 export DEEPSEEK_API_KEY=... 再跑。

ModuleNotFoundError: openai?pip install openai 即可,DeepSeek 用的是 OpenAI 兼容接口。

模型一步就给结论、没搜索?把 SYS 里「一次只查一个候选、别一口气编结论」再强调一遍;小模型有时会偷懒。把 model 换成更强的模型也能缓解。

死循环、到第 6 步还没收手?正常防御,max_steps 就是兜底;真实系统一定要有这个上限(见 Part 2「多步脆弱性」)。

📌 说清楚:这是教学最小实现。为了让你零成本看懂机制,这里做了三处简化:① web_search 是本地词典 stub(真实系统接搜索 API);② 用正则 search\("..."\) 解析动作(真实系统用 function calling 的结构化输出,更健壮);③ 把观察直接堆进消息列表(真实长任务要做上下文管理,见第 2 章)。机制是真的,工程化是后面章节的事。

这一段你已经看到了最关键的现象:模型自己决定了「先查谁、再查谁、什么时候够了」。这就是 Agent,而不是一次性问答。

🛠️ 动手实验一:换个简单问题,看它「少查一次」

把最后一行改成:

run("pgvector 适合超大规模十亿级向量吗?")

你会看到它只搜了一次就回答,因为这个问题一步就够。同一个 Agent,会根据问题难度自己决定查几次,这正是 Deep Research 的精髓:算力花在该花的地方。

🛠️ 动手实验二:再加一个工具(从「搜索」到「搜索 + 打开文档」)

真实调研里,搜索只给你标题和摘要,还得「点进去看」官方文档的细节。我们给 Agent 再加一个 visit 工具,让它能「打开」一份资料看详情:

PAGES = {  # 玩具「文档正文」库
    "qdrant": "Qdrant 文档:支持 payload 过滤、量化压缩;单容器可起,水平扩展需自建集群。",
    "pgvector": "pgvector 文档:HNSW / IVFFlat 索引;受 Postgres 单机资源约束,千万级以上需谨慎评估。",
}
def visit(query):
    for k, v in PAGES.items():
        if k in query.lower(): return v
    return "页面无相关内容。"

# 在 SYS 里多给一个动作:Action: visit("候选名"),搜索拿线索,visit 拿细节
# 在 run() 的循环里多解析一个 visit(...) 分支,命中就调 visit()

跑起来你会观察到一个更像「调研」的行为:模型先 search 拿到定位、判断不够细,再 visit 拿文档细节、最后才综合。这就是从「查一次」走向「做一轮调研」的第一步。(完整的工具集设计,search / visit / 计算器等,是第 3 章的主题。)

🧭 你刚才做的,等于真实系统的什么?

你的 web_search() / visit() = 真实系统里接的搜索 / 文档访问工具(第 3 章细讲工具集与统一工具网关);

你的 ReAct 循环 = Agent 的执行框架(第 2 章会讲它在长任务里的硬伤,以及 IterResearch 怎么救);

你让模型「自己决定查几次、什么时候收手」= Deep Research 的多步推理内核;

你那个 max_steps 上限 = 真实系统的容错与提前终止(Part 2 会讲为什么它是必需品)。

你手搓的是它最朴素的样子。真实工业级系统在这之上,还要解决长程上下文怎么不爆、工具怎么容错、模型怎么训练得更会用工具,这些正是后面各章要一步步展开的。

🎯 Part 2 · 面试深度 ｜ ~40% 这部分把面试高频的几个判断题讲透:Deep Research 和各种「RAG plus」到底差在哪、什么时候该上、主流系统怎么做的、以及它最大的工程风险。

2.1 三条路线的边界:普通 RAG vs Agentic RAG vs Deep Research

面试官最爱问的就是「这几个有啥区别」。很多人答得含糊,其实一张图就能说清:区别在于「检索」这个动作,被放在了什么位置。

维度	普通 RAG	Agentic RAG	Deep Research
检索的地位	固定流程里的一步:查一次	Agent 可以决定要不要查、查几次	检索只是调研循环里的一个工具,还有 visit / 计算 / 反思
规划	无	有限(围绕检索)	完整:拆解任务、动态调整策略
典型轮数	1	1~3	几轮到几十轮
产出	一段回答	一段回答(更准)	结构化调研报告 + 引用
代价	快、便宜	中等	慢、贵(多次模型调用)

一句话总线:普通 RAG 是「查一次再答」;Agentic RAG 是「让模型自己决定查几次」;Deep Research 是「把检索当成一个工具,跑一整轮带规划和反思的调研」。 三者不是谁取代谁,而是复杂度递增,对应的成本也递增。

业内行话:别把这三个词当成「越靠后越高级、要无脑选最高级的」。面试时能讲出「它们是一条成本-能力的光谱,我会按问题复杂度选最低够用的那档」,比堆名词成熟得多。绝大多数线上问答,普通 RAG 就够了,把简单问题也丢给 Deep Research,是最常见的过度设计。

2.2 一个绕不开的判断:什么时候该上 Deep Research?

Deep Research 强,但慢且贵,一个问题动辄几十次模型调用,延迟从几百毫秒变成几十秒,成本翻几十倍。所以「该不该上」是个真问题。判断标准其实很朴素:

核心就一句:这个问题能不能靠「一次检索」答好?

能 → 普通 RAG。比如「pgvector 怎么装」「Qdrant 默认端口是多少」,答案就在某一段文档里。
不能,但加一两轮检索能搞定 → Agentic RAG。比如「Qdrant 和它的云托管版功能差在哪,两个都查一下」。
必须跨多个对象 / 多跳推理 / 结合自身约束再综合 → 才轮到 Deep Research。比如开篇那个三选一选型、或「梳理近一年开源向量库的能力演进格局」。

讲师私货:面试被问「你怎么控制 Deep Research 的成本」,别只说「我加了缓存」。真正显水平的是讲清「分级路由」:用一个轻量判断(规则 / 小模型 / 一次便宜的 LLM 调用)先判断问题复杂度,简单的走普通 RAG、复杂的才进 Deep Research 全流程。把贵的算力只花在真正需要的问题上,这套「先分诊、再调度」的思路,在 RAG 项目的文档解析里也用过(见 RAG 系列第 3 章「分类器前置 + 动态调度」),是通用的工程审美。

2.3 Deep Research 的能力边界:能做什么、不能做什么

面试官常追问「它的局限是什么」,这是在看你有没有真用过、有没有踩过坑。诚实地划清边界:

能做(它的主场):

信息检索与综合:多轮迭代搜索、多源聚合、交叉验证
复杂推理:多跳(A→B→C→结论)、比较、条件推理、数值分析
动态规划:根据中间结果调整策略、识别信息缺口、探索新路径
生成结构化调研报告 + 引用溯源

不能 / 不应该做(它的边界):

不是知识库:它不存事实,每次都要实时检索,所以它慢
不保证 100% 准确:受限于信息源质量和推理能力,该有人工复核就得有
不适合时效性极强的任务:搜索引擎索引有延迟,「今早刚发布的版本」它未必查得到
不适合需要专业工具 / 私有数据的任务:除非你把那些工具、数据接进去(而这恰恰是工业级落地最难、也最值钱的部分)

业内行话:能把「不能做」讲清楚,比把「能做」吹一遍更值钱。面试官听到「它不是知识库、不保证准确、所以我在选型这种要拍板的场景里一定加人工复核和引用溯源」,会立刻判断你是真在生产环境里用过的人。

2.4 主流系统都怎么做的(建立坐标系)

不用记细节,但要知道这个领域的「坐标系」,面试聊起来不至于一问三不知:

闭源产品:OpenAI 的 Deep Research、Google Gemini 的 Deep Research,都是「给个问题,自己查十几分钟,产出一篇带引用的长报告」的形态,代表了产品化的天花板。
开源 / 学术:一批围绕「Agent 执行框架 + 工具 + 长程记忆 + 训练方法」的工作(ReAct、IterResearch、ReSum、Search-R1 等),是我们这套教程的技术底座,后面章节会逐个拆。

记住一个判断:这些系统拉开差距的地方,从来不是「能不能调用搜索」,而是「长任务里上下文怎么不崩、模型怎么被训练得更会用工具」。 前者是本章的 mini-agent 就能做的;后者(尤其是训练)才是工业级的护城河。

2.5 这条路最大的坑:多步 = 错误会累积放大

多步是 Deep Research 的力量,也是它最脆弱的地方。一句话:步数越多,错误越会沿着链路累积、放大。

具体三种典型崩法:

某一步搜歪了:某一步搜到一篇过时 / 不相关的旧对比,模型却信了,后面所有推理都建在错的地基上。
上下文被污染:每一步的文档正文都堆进上下文,几十轮后上下文又长又乱,模型注意力被稀释,越查越迷(这就是下一章 ReAct 的核心硬伤)。
不收手 / 乱收手:要么死循环查不停(烧钱),要么没查够就硬给结论(瞎编)。

工程上从四层兜:

工具层:容错(搜索失败要重试 / 降级)、重复检测(别反复搜同一个词)
上下文层:别无脑堆,用「演进报告 / 动态摘要」把状态控制在常量大小(第 2 章主角)
控制层:max_steps 上限 + 提前终止判断(信息够了就收手)
训练层:让模型本身就「更会用工具、更知道何时收手」,这要靠 SFT + 强化学习,是后面训练章节的主题

业内行话:面试问「你那个调研 Agent 怎么保证不跑偏」,能把这四层串起来讲(工具容错 / 上下文控常量 / 控制层兜底 / 训练层治本),而不是只说「我加了重试」,面试官立刻知道你真趟过长任务的坑。这条「问题在哪、从哪几层治」的结构化回答,是这一章最值钱的面试资产。

2.6 这 8 章怎么排(全书心智模型)

把开头那条心智模型「规划 → 多步检索 → 交叉验证 → 综合成带引用的报告」展开,就是这套教程的章节顺序。理解了这张图,你就知道每一章在解决整条链路的哪一环:

第 1–4 章(看懂 + 跑通推理):为什么做 → 执行框架(ReAct → IterResearch)→ 工具集设计 → 长程记忆管理。这几章推理 demo 都能在你本机跑起来。
第 5–6 章(把模型训得会做调研):数据构造 → 多阶段训练(CPT / SFT / GRPO)。讲透每一步的思路与原理,帮你建立完整认知。
第 7–8 章(上线 + 评估):工程化上线(推理优化 / 并发 / 成本)→ 评估闭环(怎么定义「好」、怎么自动打分、怎么形成迭代飞轮)。

你不必一口气全读完:想先跑通一个调研 Agent,读完第 1–4 章就够动手了;想顺着「数据 → 训练 → 上线 → 评估」走完整条链路,再往后读。

🧭 这一章到这儿:Deep Research 是什么、和普通 RAG 差在哪、什么时候该上、最小实现长什么样,这条线已经走通,推理 demo 你也能在本机跑起来了。从下一章开始,我们顺着「执行框架 → 工具 → 记忆 → 数据 → 训练 → 上线 → 评估」一步步把它做扎实。

🏆 Part 3 · 验收串题 ｜ ~10% 学到这一步,做几道题验证一下。这些都是大厂高频考点,点进去是题库里的完整解析。

关联面试题(5 道,覆盖 5 个角度)

【ReAct 工作流】 以 ReAct(Reasoning + Acting)框架为例,详细解释它的工作流:Thought / Action / Observation 怎么交织?
- 中等 →
【工具调用实现】 在 AI Agent 系统中,如何设计和实现可供 Agent 调用的外部工具(搜索、计算等)?模型到底怎么「调用」一个工具?
- 中等 →
【Function Calling 对比】 Function Calling 与 Toolformer 在实现大模型工具调用上有什么区别?
- 较难 →
【框架取舍】 ReAct 与 Plan-and-Execute 两种推理框架,在处理长任务时各有什么取舍?什么场景选哪个?
- 较难 →
【多步可靠性】 Agent 执行长周期任务时,如何实现可靠的中断恢复和状态持久化、降低多步跑偏的风险?
- 较难 →

自检清单

能用一句话讲清普通 RAG / Agentic RAG / Deep Research 三者的区别
能在本机跑通 mini-agent,并解释「为什么它对这个问题查了三次、对那个问题只查一次」
能讲清「工具调用」里「模型只提议、程序去执行」这个闭环
能说出判断「该不该上 Deep Research」的标准,以及成本怎么控(分级路由)
能讲清 Deep Research 的 4 个能力边界(不是知识库 / 不保证准确 / 不适合强时效 / 不适合私有工具数据)
能把「多步为什么脆弱」+「从哪四层兜」串成一段结构化回答

学完这一章,你已经能搭出一个会多步搜索的调研 Agent 雏形,也能在面试里把「为什么要 Deep Research、它和 RAG 差在哪」讲明白。下一章,我们正式进入执行框架,看 ReAct 在长任务里为什么会「上下文爆炸」,以及 IterResearch 怎么用「演进报告」把它救回来。