第 30 章 · Deep Research

一次“帮我把这个国家摸透”的调研

那个做跨境的卖家，这次盯上了一个新市场：他想把主力品类推到德国站，但心里全是问号——这个品类在德国现在谁在卖、卖多少钱、评价里最集中的抱怨是什么，还有绕不开的合规门槛：EPR 包装法注册、WEEE 电子废弃物登记、CE 认证到底要不要，缺一样货就可能被平台下架甚至罚款。

这不是一句“帮我搜一下”能了结的。搜一次德国 EPR，你会看到它牵出 LUCID 注册号；顺着 LUCID 查下去，又冒出“包装材料要按重量申报”的新细节；再一比对竞品的德国站 listing，发现有人因为没标能效等级被投诉……每查到一点，就冒出新的要查的东西。真人做这种调研，是一边查一边记、一边记一边发现还差什么，来回滚好几轮，最后攒出一份有理有据、每句话都说得清出处的报告。

让 Agent 来干这件事，就是这两年最热的应用形态——Deep Research（深度研究）。你给它一个开放问题，它花几分钟到几十分钟，自主地搜索、阅读、核对，最后产出一份带引用的详实报告。它要的不是“答得快”，而是“答得深、答得可信”。好消息是：把它拆开看，零件全是前面几章讲过的东西。

Deep Research 是 Research-Synthesis 的工程化

先给它定个位。Deep Research 本质上就是第 22 章 Research-Synthesis（研究—综合） 模式的工程化落地——先分头把资料研究透，再综合成一份成品。只不过一次性的“研究一轮就写”远远不够深，真正能打的 Deep Research 在这个骨架上加了四样关键能力，缺一样都会露馅。

接下来两节，我们把这四样——迭代式深入、来源管理与引用、交叉验证、规划与反思——一个个讲清楚。它们不是新概念，几乎每一样都能在前面的章节里找到根，Deep Research 做的是把它们拧成一股绳。

迭代式深入与规划反思

迭代式深入（iterative deepening）是 Deep Research 区别于普通搜索的第一条分水岭。普通检索是“问一句、答一句”；Deep Research 是搜索 → 从结果里发现新线索 → 带着新线索再搜索，一轮扣一轮，像滚雪球一样把研究越做越深。查德国合规就是典型：第一轮问“德国站销售要哪些资质”，拿到 EPR/WEEE/CE 三个关键词；第二轮分头深挖 EPR，发现要在 LUCID 平台注册并拿注册号；第三轮又顺着 LUCID 查到申报口径……每一轮的产出，都是下一轮的输入。这正是第 3 章 ReAct 循环在“研究”这件事上的放大版。

但光会滚雪球还不够，得有人在开头指方向、在中途踩刹车，这就要靠规划与反思这对搭档：

  • 规划（planning，第 13 章）：拿到开放问题，先别急着搜。先把它拆成几个可独立推进的子问题——“竞品全景”“价格带”“合规清单”“物流时效”。有了这份清单，研究才不是漫无目的地乱撞，而是照着计划一块块填。
  • 反思（reflection，第 14 章）：每滚完一轮，停下来问一句“对着最初的问题，我现在还缺什么？”。缺合规里的包装申报细节？那就把它变成下一轮的新子问题。反思是决定“继续滚还是收尾”的裁判——没有它，Agent 要么早早收工留一堆窟窿，要么无止境地查下去停不下来。

规划开头、迭代滚动、反思收尾，这三者合起来才是“深度”二字的来处。

来源管理与交叉验证

如果说迭代和反思决定了研究的“深度”，那下面这两样决定的是研究的“可信”——一份不能溯源的报告，和一段编得像模像样的胡话，没有本质区别。

来源管理与引用（citation）是 Deep Research 的立身之本。Agent 每采信一条信息，都要同时记下它从哪儿来：URL、标题、抓取时间、原文片段。最终报告里的每个关键结论后面，都能挂上一个可点开核对的出处。这件事的意义怎么强调都不过分——能溯源，“研究”才成其为研究；不能溯源，再流畅也只是“瞎编”。对卖家来说尤其致命：一句“德国 EPR 注册费约 X 欧元”如果没有官方来源背书，他敢信、敢据此报价吗？

交叉验证（cross-validation）是给重要结论上的第二道保险。单一来源可能过时、可能片面、甚至可能就是错的。所以对那些会影响决策的关键结论，Deep Research 不满足于“查到一处就写下”，而是用多个独立来源互相核对——两三个来源都指向同一个数字，才敢采信；彼此打架，就在报告里如实标注分歧、给出各自出处，把判断权交还给用户。这背后的思路和第 21 章 Debate（辩论） 一脉相承：让不同来源“对质”，比只听一家之言更接近真相。合规信息最该这么核——平台帮助页、官方监管机构、第三方服务商三方对上了，这条结论才算立住。

用 pi 实现：全书模式的集大成

四样能力讲完，落到代码上你会发现，Deep Research 几乎把全书的积木都用上了。下面这段概念示意，就是我们贯穿项目的 Research Agent 长大成熟后的样子：

// 概念示意：Deep Research = 规划 + 并行研究 + 迭代 + 综合
async function deepResearch(question) {
  const plan = await planner.decompose(question);        // 第 13 章：规划，拆成子问题
  let findings = [];

  for (let round = 0; round < MAX_ROUNDS; round++) {
    // 并行研究各子问题，每个 researcher 独立上下文（第 22 章）
    const results = await Promise.all(
      plan.openQuestions.map((q) =>
        researcher.run(q, { tools: [webSearch, fetch], cite: true }) // 第 4 章：工具 + 引用
      )
    );
    findings.push(...results);

    // 反思：对着原问题还缺什么？发现新线索就继续（第 14 章）
    const gap = await critic.findGaps(question, findings);
    if (!gap.hasMore) break;
    plan.openQuestions = gap.newQuestions;   // 新线索变成下一轮的子问题（迭代式深入）
  }

  // 综合成带引用的报告，关键结论走交叉验证（第 20、21 章）
  return synthesizer.writeReport(question, findings, { crossCheck: true });
}

你能在这短短一段里数出至少五章的内容：规划（第 13 章）、工具调用与引用（第 4 章）、并行多 Agent（第 22 章）、反思(第 14 章)、综合与交叉验证（第 20、21 章）。Deep Research 不是一个新范式，而是本书前几部分模式的一次总演练、一次集大成。

落到 pi 这套真实能力上，搭它需要的地基都齐了：

  • 工具与检索：Agent 靠工具够到外部世界。pi 用 registerTool 定义工具（第 4 章）；web_fetch 这类抓网页的能力 pi 已经迁到社区扩展 pi-web-access，搜索检索则可以接 MCP（第 5 章）或自己写工具接入某家搜索 API。
  • 会话与持久化：几十分钟的调研必须能中断、能续上。pi 的会话结构化持久化在 ~/.pi/agent/sessions/，还带会话树（可 fork、可导航），中途出错不至于从头再来。
  • 扩展挂反思与引用：来源管理、去重、进度上报这些逻辑，适合写成扩展，订阅 afterToolCall 之类的生命周期事件，工具一返回就把出处记进一张来源表。
  • 多 Agent 编排：并行跑多个 researcher，可以用实验性的 pi-orchestrator（API 可能变，重点是理解这个“一个主控派多个研究员”的模式，而非绑定某个 API）。

深度与成本的权衡

Deep Research 有个绕不开的代价：又烧钱又耗时。多轮迭代 × 多个并行 Agent × 每个都拖着长上下文，token 和时间是乘起来涨的。一次认真的市场调研跑下来，花掉几美元、耗上十几分钟都不稀奇。所以要把它推上生产，这三件事必须做：

  • 设轮次与预算上限（第 26 章）：给迭代次数封顶，给累计花费封顶，任一触顶就强制收尾。这是防止它无限研究下去、一夜烧空账户的硬刹车，绝不能省。
  • 分层模型（第 34 章）：不是每一步都得用最贵的模型。检索、初筛、判断某个网页相不相关，交给便宜快速的模型批量干；只有最后的综合、交叉验证、关键判断，才动用贵而强的模型。省下来的是实打实的钱。
  • 给用户进度反馈：一个要跑十几分钟的任务，界面上不能一片死寂。要让用户看到“正在调研德国竞品价格带…已核对 3 个来源…”，既是体验，也是信任——用户看得见它在认真干活，才愿意等。pi-app 的顶栏就实时显示上下文占用与花费，天然适合当这种进度窗口。

一句话：深度不是免费的，Deep Research 的工程难点，一大半在如何用最少的钱把研究做到够深。

动手看看

先别急着搭整套。找一个你真正关心的开放问题——比如“我这个品类进某国站要哪些合规资质”——用 pi 手动跑几轮：第一轮让它搜个大概，看它回来的结果里有哪些你没想到的新线索，再把这些线索喂回去让它接着查。亲手滚两三轮雪球，你会对“迭代式深入”有远比读文字更直观的体感。

再去读 pi 的会话文件（~/.pi/agent/sessions/ 下），看看一次多轮调研在磁盘上是怎么结构化存下来的——哪些是 Thought、哪些是工具调用、结果怎么回填。对照第 22 章 Research-Synthesis 的骨架，你会发现 Deep Research 的“魂”其实一直都在，只是被多轮迭代和引用管理撑大了。想再进一步，可以翻翻社区扩展 pi-web-access，看它把抓网页这件事封装成了怎样的工具。

实战中的几个坑

坑一：查着查着跑题了。

  • 现象：滚了几轮之后，Agent 钻进一个细枝末节，离最初的问题越来越远。
  • 原因：只顾着追新线索，反思环节没有拿“原始问题”当锚点。
  • 对策：每轮反思都把最初的问题重新喂给 critic，让它判断新线索“是否服务于原问题”，偏了就砍掉。

坑二：报告花哨，结论无出处。

  • 现象：报告写得头头是道，但关键数字、关键结论后面没有引用，没法核。
  • 原因：来源管理没做硬，引用是“可选项”而非“必填项”。
  • 对策：在综合环节强制约束——每条结论必须携带至少一个来源，缺来源的结论要么补查要么删掉。

坑三：被单一来源带偏。

  • 现象：一个过时或错误的网页，成了报告里某个重要结论的唯一依据。
  • 原因：省掉了交叉验证，“查到一处就写下”。
  • 对策：对影响决策的关键结论强制多来源核对；来源打架时如实标注分歧，别替用户下定论。

坑四：没封顶，烧钱停不下来。

  • 现象：一次调研跑了半小时、花掉十几美元还没结束。
  • 原因：没设轮次/预算上限，或反思总判断“还能更深”。
  • 对策：轮次和预算双硬刹车（第 26 章）；便宜模型做检索、贵模型只做综合（第 34 章）。

对比：其他框架

Deep Research 是把规划、并行研究、迭代、综合、引用串起来的应用形态，不是某个框架的一等特性。各家能到什么程度，取决于它对多 Agent 编排、检索（RAG）和结构化输出预置了多少：

框架Deep Research 怎么做特点
LangGraph把 Research-Synthesis 显式画成状态图：规划节点、并行研究节点、反思判断的条件边、综合节点循环与分支控制最精确，检索工具要自己接
CrewAI用“一个主管带一队研究员”的角色+任务组织多轮调研心智直观，但迭代深入与引用严谨度要自己在任务里补
PydanticAI强项在用类型约束最终报告结构化、可溯源（每条结论必须带来源）报告规整、可校验，多轮编排本身要自行搭
Agno电池全含：内置 Knowledge（RAG）、搜索工具与 Team 协作快速搭出有检索有记忆的调研助手，深度迭代与交叉验证仍需自己设计
pi提供工具、扩展、会话与实验性 orchestrator 作基础，检索接 MCP 或自定义工具（web_fetch 走 pi-web-access）在这之上把全书模式亲手组装成 Deep Research

一句话点本质：Deep Research 没有“一键”实现，都是若干模式的组装——框架的差别只在替你预置了哪几块（编排、RAG、结构化输出），以及组装时你还要自己写多少。

小结

  1. Deep Research 是第 22 章 Research-Synthesis 模式的工程化落地：先分头研究、再综合成带引用的报告，本质是本书前几部分模式的集大成。
  2. 它的“深度”来自两对能力——迭代式深入（iterative deepening）（搜索→发现新线索→再搜索，滚雪球）配上规划（planning）开头定方向、反思（reflection）中途查缺口。
  3. 它的“可信”来自另两样——来源管理与引用（citation）让报告可溯源，是“研究”区别于“瞎编”的关键；交叉验证（cross-validation）用多来源核对重要结论，思路与第 21 章 Debate 相通。
  4. 生产化必须控住成本与时间：轮次/预算双上限（第 26 章）、分层模型（第 34 章，便宜模型检索初筛、贵模型综合判断）、以及看得见的进度反馈。
  5. 用 pi 落地时，地基是工具与检索（pi-web-access / MCP）、结构化会话、扩展挂引用与反思、实验性 orchestrator 编排多 Agent——没有现成的“Deep Research 按钮”，靠你把这些积木拼起来。

Deep Research 把 Agent“读和想”的能力推到了极致——它能查遍全网、核对再三，却始终隔着一层屏幕。下一章我们越过这层屏幕，看 Agent 的另一种能力边界：直接操作电脑（Computer Use）。