第 22 章 · Research-Synthesis

一次“又广又深”的市场调研

那个跨境卖家想开拓新品类，给 Agent 派了个大活：“帮我调研一下 2026 年欧美市场值得做的三个新兴消费电子品类，每个品类要有市场规模、主要竞品、合规门槛、利润空间——最后给我一份能直接拿去开会的报告。”

这个任务同时要求广(三个品类、每个四五个维度)和深(每个维度都要查得够细、有数据有来源)。如果让单个 Agent 线性地做，它会很快陷进去：上下文塞满一堆搜索结果、抓不住重点、查到第二个品类时第一个的细节已经被后面的信息挤没了、也来不及深挖每一个维度。

这类“检索大量信息 → 提炼 → 综合成结论”的任务极其常见——市场调研、竞品分析、尽职调查，也正是本书贯穿项目 Research Agent 的核心。它需要一个专门的范式：Research-Synthesis(研究—综合)。

模式：分头研究，再汇总综合

Research-Synthesis 把任务拆成两个阶段。

阶段一：并行研究(发散，diverge)

  • 把大问题拆成若干子问题(sub-questions)——每个品类、每个维度一个。
  • 派多个 Agent 并行(parallel)去研究各自的子问题，每个 Agent 有自己独立的上下文，互不干扰、互不污染。
  • 每个 Agent 产出一份聚焦的子报告(sub-report)。

阶段二：综合(收敛，converge)

  • 一个综合 Agent(synthesis agent)收集所有子报告。
  • 去重、比对、提炼，整合成一份连贯的最终结论。

这个“发散—收敛”的结构，你在第 21 章(Debate)已经见过——它是多 Agent 系统里反复出现的黄金模式。区别在于分工的性质：Debate 是“多个 Agent 对同一个问题各抒己见再收敛”,Research-Synthesis 是“多个 Agent 对不同的子问题分头深挖再汇总”。一个是并列质疑，一个是分工协作。

为什么这样拆有效：上下文隔离

这个范式的核心价值，浓缩成一个词：上下文隔离(context isolation)。

  • 上下文隔离：每个研究 Agent 只装自己那份资料(只查“欧洲宠物电子的合规门槛”的 Agent，上下文里就只有这个话题的搜索结果)，不会被其他品类、其他维度的信息淹没——这是单 Agent 做不到的。单 Agent 的上下文是共享的，查得越多越乱；多 Agent 的上下文是隔离的，各自清爽。
  • 并行加速(parallelism):10 个子问题并行研究，比串行快一个数量级——你不用等第一个品类查完才开始第二个。
  • 各有深度(depth)：每个 Agent 只管一小块，能在自己的小领域深挖到底，而不必因为“还有一堆别的要查”而浅尝辄止。

一句话：用“多个专注的小上下文”，替代“一个塞爆的大上下文”。这也是多 Agent 最本质的价值之一——不是“人多力量大”，而是“分而治之、各守其境”。

用 pi 实现：贯穿项目的雏形

这正是我们的 Research Agent 要长成的样子。用前面所有的积木组合：

// 概念示意:Research-Synthesis 的两阶段
async function researchSynthesis(topic) {
  // 阶段一:拆解 + 并行研究(每个 Agent 独立上下文)
  const subQuestions = await plannerAgent.decompose(topic);   // 规划拆解(第 13 章)
  const subReports = await Promise.all(
    subQuestions.map((q) =>
      researchAgent.run(q, { tools: [webSearch, fetch] })     // 独立会话 + 工具(第 4 章)
    )
  );

  // 阶段二:综合成最终报告
  return synthesisAgent.combine(topic, subReports);
}

它几乎把全书前面的模式都用上了：规划(planning) 拆解子问题(第 13 章)、工具(tools) 做检索(第 4 章)、并行多 Agent 分头研究(Part 5)、综合 Agent 收敛(本章)。这就是为什么 Research Agent 适合作贯穿项目——它是所有模式的集大成者。

在 pi 里，researchAgent.run 的每次调用天然跑在独立会话里(第 12 章)，上下文隔离几乎是免费的；而 pi-orchestrator(实验性)负责把这些并行子任务组织起来。要注意 orchestrator 的 API 仍在演进，所以这里的重点是模式——即便手写 Promise.all 也能实现同样的隔离与并行。

拆解质量决定一切

Research-Synthesis 的效果，高度依赖第一步“拆解(decomposition)”拆得好不好——这一步几乎决定了成败，值得单独讲。

  • 拆得太粗：一个子问题还是“调研整个消费电子市场”，子 Agent 又回到了“上下文塞爆”的老问题，隔离等于白做。
  • 拆得太细：切成几十个高度重叠的小问题，子报告之间大量重复，综合阶段全是去重的苦工。
  • 有遗漏：某个重要维度(比如“物流与关税”)没拆出来，再好的并行研究也补不上——最终报告直接有盲区。

所以实践中，常常给拆解阶段也加一道“检查”：拆完后回头问一句“这些子问题合起来，能不能完整回答原问题？有没有遗漏的重要维度？有没有可以合并的重复项？”——这其实就是一个小型的反思(Reflection，第 14 章)。让规划 Agent 自审一遍再放行，往往比事后在综合阶段补救省得多。

动手看看

拿你自己关心的一个调研问题，先只做拆解这一步：让 Agent 把它拆成 5–8 个子问题，然后你逐条看——有没有重叠的？有没有明显该有却漏掉的维度？这一步的质量，你一眼就能判断，而它几乎决定了最终报告的上限。

再对照跑两版：一版让单个 Agent 线性调研全部内容，一版按子问题并行跑再综合。比较两份报告的深度和条理，你会直观地感到“上下文隔离”带来的差别——单 Agent 的报告往往前详后略、越查越飘，并行版则每块都扎实。

实战中的几个坑

坑一：拆解太粗，子 Agent 照样塞爆上下文。

  • 现象：子报告依然又长又杂、抓不住重点。
  • 原因：子问题的粒度太大，和原问题差不多。
  • 对策：把子问题拆到“一个 Agent 一轮就能查透”的粒度；拆完加一道反思检查粒度。

坑二：子问题重叠，综合阶段全在去重。

  • 现象：多份子报告讲的是同一件事，综合 Agent 大量精力花在剔重复。
  • 原因：拆解时没保证子问题互斥。
  • 对策：拆解提示里要求“子问题之间尽量不重叠、合起来尽量不遗漏”(即 MECE 原则)。

坑三：综合阶段变成“简单拼接”。

  • 现象：最终报告是几份子报告的堆砌，读起来割裂、没有全局结论。
  • 原因：综合 Agent 只做了汇总、没做提炼和比对。
  • 对策：给综合 Agent 明确指令——去重、交叉比对、提炼出跨子报告的洞察，而非罗列。

坑四：并行数量失控，一次拆出几十个子任务。

  • 现象：成本和 API 速率瞬间爆表，或触发限流。
  • 原因：没给并行度设上限。
  • 对策：限制并行子任务数(分批跑)，给每个子研究设步数/预算上限(第 26 章)。

对比：其他框架

Deep Research 类产品(各大厂的“深度研究”功能)本质都是 Research-Synthesis 的工程化(第 30 章会专门讲)。四家框架都能实现“拆解 → 并行研究 → 综合”这条主线，差别在编排并行子研究与汇总的便利性。

框架Research-Synthesis 怎么做特点
LangGraph把“拆解”“并行子研究”“综合”建成节点，天然支持 fan-out/fan-in 的并行分支与汇聚控制流最显式，适合需精确掌控每个子任务边界
CrewAI把“研究员”和“综合者”定义成不同角色，用 Crew 分派子任务再汇总最贴合“一个主管带一队研究员”，分工直观
PydanticAI用类型约束每个子研究的返回(带来源、置信度的结构化结果)无内建并行编排，但让综合阶段拿到干净可靠的输入
AgnoTeam 的 coordinate/route 模式分派子研究再由协调者综合，配内建 Knowledge(RAG)快速搭出有检索能力的调研助手
piorchestrator + 工具 + 并行组合，靠上下文隔离让每个子研究跑在独立小上下文本书贯穿项目 Research Agent 正是这么搭的

一句话点破：四家的差别只在“并行编排顺不顺手”，而这个范式真正的胜负手——拆解质量和上下文隔离——是模式层面的功夫，换任何框架都得你自己下。

小结

  1. Research-Synthesis(研究—综合)分两阶段：并行研究(发散)+ 综合(收敛)，是多 Agent 的黄金模式，专治“又广又深、单线做不动”的调研任务。
  2. 核心价值是上下文隔离——用多个专注的小上下文替代一个塞爆的大上下文，换来隔离、并行、有深度三重收益。
  3. 它是全书模式的集大成者：规划拆解、工具检索、并行多 Agent、综合收敛一齐上阵，也是贯穿项目 Research Agent 的核心。
  4. 效果高度依赖拆解质量：太粗则塞爆、太细则重复、遗漏则盲区，常给拆解加一道反思检查(遵循 MECE)。
  5. 综合不是拼接：综合 Agent 要去重、比对、提炼出跨子报告的洞察，并行度也要设上限以防成本失控。

Part 6 到此结束。前六个部分，我们从单 Agent 一路讲到高级多 Agent 推理。但这些还都是“能跑”——接下来 Part 7、Part 8 要解决“能上生产”：架构、可观测性、预算、安全。